#
b97de13a |
| 30-Jan-2019 |
Marius Strobl <marius@FreeBSD.org> |
- Stop iflib(4) from leaking MSI messages on detachment by calling bus_teardown_intr(9) before pci_release_msi(9). - Ensure that iflib(4) and associated drivers pass correct RIDs to bus_release_r
- Stop iflib(4) from leaking MSI messages on detachment by calling bus_teardown_intr(9) before pci_release_msi(9). - Ensure that iflib(4) and associated drivers pass correct RIDs to bus_release_resource(9) by obtaining the RIDs via rman_get_rid(9) on the corresponding resources instead of using the RIDs initially passed to bus_alloc_resource_any(9) as the latter function may change those RIDs. Solely em(4) for the ioport resource (but not others) and bnxt(4) were using the correct RIDs by caching the ones returned by bus_alloc_resource_any(9). - Change the logic of iflib_msix_init() around to only map the MSI-X BAR if MSI-X is actually supported, i. e. pci_msix_count(9) returns > 0. Otherwise the "Unable to map MSIX table " message triggers for devices that simply don't support MSI-X and the user may think that something is wrong while in fact everything works as expected. - Put some (mostly redundant) debug messages emitted by iflib(4) and em(4) during attachment under bootverbose. The non-verbose output of em(4) seen during attachment now is close to the one prior to the conversion to iflib(4). - Replace various variants of spelling "MSI-X" (several in messages) with "MSI-X" as used in the PCI specifications. - Remove some trailing whitespace from messages emitted by iflib(4) and change them to consistently start with uppercase. - Remove some obsolete comments about releasing interrupts from drivers and correct a few others.
Reviewed by: erj, Jacob Keller, shurd Differential Revision: https://reviews.freebsd.org/D18980
show more ...
|
#
88148a07 |
| 22-Jan-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343202 through r343319.
|
#
8f82136a |
| 22-Jan-2019 |
Patrick Kelsey <pkelsey@FreeBSD.org> |
onvert vmx(4) to being an iflib driver.
Also, expose IFLIB_MAX_RX_SEGS to iflib drivers and add iflib_dma_alloc_align() to the iflib API.
Performance is generally better with the tunable/sysctl dev
onvert vmx(4) to being an iflib driver.
Also, expose IFLIB_MAX_RX_SEGS to iflib drivers and add iflib_dma_alloc_align() to the iflib API.
Performance is generally better with the tunable/sysctl dev.vmx.<index>.iflib.tx_abdicate=1.
Reviewed by: shurd MFC after: 1 week Relnotes: yes Sponsored by: RG Nets Differential Revision: https://reviews.freebsd.org/D18761
show more ...
|
Revision tags: release/12.0.0, release/11.2.0 |
|
#
d7c5a620 |
| 18-May-2018 |
Matt Macy <mmacy@FreeBSD.org> |
ifnet: Replace if_addr_lock rwlock with epoch + mutex
Run on LLNW canaries and tested by pho@
gallatin: Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5 based ConnectX 4-LX NIC, I
ifnet: Replace if_addr_lock rwlock with epoch + mutex
Run on LLNW canaries and tested by pho@
gallatin: Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5 based ConnectX 4-LX NIC, I see an almost 12% improvement in received packet rate, and a larger improvement in bytes delivered all the way to userspace.
When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1, I see, using nstat -I mce0 1 before the patch:
InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32 4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32 4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32 4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32 4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32 4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32 4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32
After the patch
InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51 5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51 5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51 5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51 5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52 5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52
Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch
Reviewed by: gallatin Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D15366
show more ...
|
#
ac2fffa4 |
| 21-Jan-2018 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
Revert r327828, r327949, r327953, r328016-r328026, r328041: Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation
Revert r327828, r327949, r327953, r328016-r328026, r328041: Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD. This is likely caused by the allocation size attributes which put extra pressure on the compiler.
Given that most of these checks are superfluous we have to choose better where to use mallocarray(9). We still have more uses of mallocarray(9) but hopefully this is enough to bring swap usage to a reasonable level.
Reported by: wosch PR: 225197
show more ...
|
#
26c1d774 |
| 13-Jan-2018 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
dev: make some use of mallocarray(9).
Focus on code where we are doing multiplications within malloc(9). None of these is likely to overflow, however the change is still useful as some static checke
dev: make some use of mallocarray(9).
Focus on code where we are doing multiplications within malloc(9). None of these is likely to overflow, however the change is still useful as some static checkers can benefit from the allocation attributes we use for mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good reason but I started doing the changes before r327796 and at that time it was convenient to make sure the sorrounding code could handle NULL values.
show more ...
|
#
1b108b19 |
| 28-Nov-2017 |
Bryan Venteicher <bryanv@FreeBSD.org> |
Correctly report the vmxnet3 link down media status
Reported by: lew@perftech.com MFC after: 1 week
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
d02c951f |
| 26-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r318658 through r318963.
|
#
ced98d78 |
| 25-May-2017 |
Andriy Gapon <avg@FreeBSD.org> |
fix vmxnet3 crash when LRO is enabled
The crash can occur when all of the following conditions are true: - a packet consists of multiple segements (requires LRO enabled) - there has been a failure t
fix vmxnet3 crash when LRO is enabled
The crash can occur when all of the following conditions are true: - a packet consists of multiple segements (requires LRO enabled) - there has been a failure to allocate an mbuf for the packet and the packet has to be dropped - a host (vmware) still owned at least one segment of the packet, so the driver had to wait for another interrupt to proceed to discarding the remaning segment(s)
Reviewed by: rstone MFC after: 2 weeks Sponsored by: Panzura Differential Revision: https://reviews.freebsd.org/D10874
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
d0cefbdc |
| 18-Jul-2016 |
Alexander Motin <mav@FreeBSD.org> |
Update if_hwassist when interface options are changed.
In particular for me this fixes checksum problem when if_bridge attached to the interface requests TXCSUM to be disabled, but effectively ignor
Update if_hwassist when interface options are changed.
In particular for me this fixes checksum problem when if_bridge attached to the interface requests TXCSUM to be disabled, but effectively ignored.
MFC after: 3 days Sponsored by: iXsystems, Inc.
show more ...
|
Revision tags: release/10.3.0 |
|
#
b626f5a7 |
| 04-Jan-2016 |
Glen Barber <gjb@FreeBSD.org> |
MFH r289384-r293170
Sponsored by: The FreeBSD Foundation
|
#
a5d8944a |
| 19-Nov-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Catch up with head (r291075).
|
#
19419093 |
| 16-Nov-2015 |
John Baldwin <jhb@FreeBSD.org> |
Only use a power of 2 for the number of receive and transmit queues. Using other values causes VMXNET3_CMD_ENABLE to fail. The Linux driver also enforces this restriction.
Reviewed by: bryanv MFC a
Only use a power of 2 for the number of receive and transmit queues. Using other values causes VMXNET3_CMD_ENABLE to fail. The Linux driver also enforces this restriction.
Reviewed by: bryanv MFC after: 1 week Sponsored by: Norse Differential Revision: https://reviews.freebsd.org/D4139
show more ...
|
Revision tags: release/10.2.0 |
|
#
98e0ffae |
| 27-May-2015 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge sync of head
|
#
d899be7d |
| 19-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head: r274132-r277384
Sponsored by: The FreeBSD Foundation
|
#
8f0ea33f |
| 13-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head revisions r273096-r277147
Sponsored by: The FreeBSD Foundation
|
#
da976f9d |
| 05-Dec-2014 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r275496
|
#
60c317af |
| 01-Dec-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r275262 through r275363.
|
#
c2529042 |
| 01-Dec-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Start process of removing the use of the deprecated "M_FLOWID" flag from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. In
Start process of removing the use of the deprecated "M_FLOWID" flag from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. Instead the "m_pkthdr.rsstype" field in the mbuf structure is now used to decide the meaning of the "m_pkthdr.flowid" field. To modify the "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX" macros as defined in the "sys/mbuf.h" header file.
This patch introduces new behaviour in the transmit direction. Previously network drivers checked if "M_FLOWID" was set in "m_flags" before using the "m_pkthdr.flowid" field. This check has now now been replaced by checking if "M_HASHTYPE_GET(m)" is different from "M_HASHTYPE_NONE". In the future more hashtypes will be added, for example hashtypes for hardware dedicated flows.
"M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is valid and has no particular type. This change removes the need for an "if" statement in TCP transmit code checking for the presence of a valid flowid value. The "if" statement mentioned above is now a direct variable assignment which is then later checked by the respective network drivers like before.
Additional notes: - The SCTP code changes will be committed as a separate patch. - Removal of the "M_FLOWID" flag will also be done separately. - The FreeBSD version has been bumped.
MFC after: 1 month Sponsored by: Mellanox Technologies
show more ...
|
#
9268022b |
| 19-Nov-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head@274682
|
Revision tags: release/10.1.0 |
|
#
1ce4b357 |
| 04-Oct-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r272516.
|
#
970388bf |
| 28-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r272185
|
#
0d286aa4 |
| 25-Sep-2014 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Provide vmxnet3_get_counter() to return counters that are not collected, but taken from hardware.
|
#
9fd573c3 |
| 22-Sep-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Improve transmit sending offload, TSO, algorithm in general.
The current TSO limitation feature only takes the total number of bytes in an mbuf chain into account and does not limit by the number of
Improve transmit sending offload, TSO, algorithm in general.
The current TSO limitation feature only takes the total number of bytes in an mbuf chain into account and does not limit by the number of mbufs in a chain. Some kinds of hardware is limited by two factors. One is the fragment length and the second is the fragment count. Both of these limits need to be taken into account when doing TSO. Else some kinds of hardware might have to drop completely valid mbuf chains because they cannot loaded into the given hardware's DMA engine. The new way of doing TSO limitation has been made backwards compatible as input from other FreeBSD developers and will use defaults for values not set.
Reviewed by: adrian, rmacklem Sponsored by: Mellanox Technologies MFC after: 1 week
show more ...
|
#
72f31000 |
| 13-Sep-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Revert r271504. A new patch to solve this issue will be made.
Suggested by: adrian @
|