aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/e1000
Commit message (Collapse)AuthorAgeFilesLines
* e1000: Increase FC pause/refresh time on PCH2 and newerKevin Bowling2026-02-131-2/+2
| | | | | | | | | | | | This corresponds to Linux f74dc880098b4a29f76d756b888fb31d81ad9a0c That commit does not provide any public background detail, but it's been in use for over 5 years and corresponds to previous chip bugs w.r.t. automatic generation of PAUSE frames. Reviewed by: kgalazka MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D54555
* igb: remove M_HASHTYPE when RSS is not enabledCheng Cui2026-02-061-1/+1
| | | | | | | manually cherry-pick efcc0423d80e Reviewed by: kbowling Differential Revision: https://reviews.freebsd.org/D55143
* em: remove M_HASHTYPE when RSS is not enabledCheng Cui2026-02-061-1/+1
| | | | | | | | | | | | | | | Summary: Since "73fe85e486d2 tcp: store flowid info in syncache", inp_flowid can be set if the incoming packet is not M_HASHTYPE_NONE. But this can introduce dummy and duplicated flowid when a virtual interface set M_HASHTYPE_OPAQUE. This change will let the upper layer know how to deal with software hash, with benefits like inp_flowid can be set correctly and m_pkthdr.flowid can be set correctly in output path. This fix is similar to "20285cad7a55" Reviewed by: kbowling Differential Revision: https://reviews.freebsd.org/D55137
* e1000: Fix setting the promiscuous modeZhenlei Huang2026-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | The variable reg_rctl stores the value read from reg E1000_RCTL. It may contain bits E1000_RCTL_VFE and E1000_RCTL_CFIEN which control VLAN hardware filter feature. The promiscuous mode implies all tagged or untagged packets should be accepted, so the VLAN hardware filter feature should be disabled when enabling the promiscuous mode. Calling em_if_vlan_filter_disable() did the task, but later writing the value of reg_rctl back to the reg E1000_RCTL may restore the feature. Move the calling of em_if_vlan_filter_disable() after writing the reg to fix that. PR: 292759 Reviewed by: kbowling Tested by: vova@zote.me Fixes: 2796f7cab107 e1000: Fix up HW vlan ops MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54973
* em(4): fix capability bounds needed to access checksum context.Ruslan Bukin2025-11-251-1/+1
| | | | | | | | | | | | | | | Ensure the offp capability bounds cover entire struct with checksum fields. This is needed for CHERI systems to avoid bounds violation trap, as otherwise offp allowed to dereference 4 bytes of csum_flags field only so bzero failed. Tested on ARM Morello. Reviewed by: kbowling Discussed with: jrtc27 Sponsored by: CHERI Research Centre Differential Revision: https://reviews.freebsd.org/D53903
* e1000: use newly exposed RSS hash key API rather than ad-hoc hashingAndrew Gallatin2025-11-224-10/+0
| | | | | | Differential Revision: https://reviews.freebsd.org/D53097 Reviewed by: kbowling Sponsored by: Netflix
* e1000: Don't enable ASPM L1 without L0sKevin Bowling2025-11-211-1/+2
| | | | | | | | | | | Reporter noted packet loss with 82583. NVM is down level. The errata docs mention disabling this, which should be the firmware default, so I am not sure why we were enabling this bit. Linux and OpenBSD have the same issue, while NetBSD got it right. Reported by: Codin <codin@nagi.ftp.sh> Tested by: Codin <codin@nagi.ftp.sh> MFC after: 2 weeks
* e1000: Bump 82574/82583 PBA to 32KKevin Bowling2025-11-211-1/+5
| | | | | | | | | | | | | | | | | The reporter contacted me with packet loss and throughput fluctuations on a low power machine (Intel J1900) that got worse with the recent AIM algorithm in FreeBSD 14.2+. 32K RX PBA matches Linux default. Add a conditional path since we don't otherwise do a fixup for jumbo frames to retain space for two frames in Tx. With this change and an additional errata change, the throughput meets line rate for the reporter. Reported by: Codin <codin@nagi.ftp.sh> Tested by: Codin <codin@nagi.ftp.sh> MFC after: 2 weeks
* igb(4): Fix VLAN support on VFsKrzysztof Galazka2025-11-171-14/+20
| | | | | | | | | | | | | | | | | Virtual Functions are considered untrusted and have no control over VLAN filtering configuration in HW. To allow using VLANs on VF intreface driver has to assume that VLAN HW Filtering is always enabled and pass requests for adding or removing VLAN tags to Physical Function driver using Mailbox API. Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com> Approved by: kbowling (mentor) Reviewed by: erj (previous version) Tested by: gowtham.kumar.ks_intel.com MFC after: 1 week Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D53245
* igb(4): Fix out-of-bounds register access on VFsKrzysztof Galazka2025-10-242-49/+80
| | | | | | | | | | | | | | | | Virtual Functions have access to a limited number of registers, and their bus space size is lower. Use KASSERT to detect out-of-bounds access and eliminate them to avoid kernel panics in production environment. Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com> Reviewed by: jmg Tested by: mateusz.moga_intel.com Approved by: kbowling (mentor), erj (mentor) Sponsored by: Intel Corporation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52976
* e1000: fix/complete merge of previous two commitsJohn-Mark Gurney2025-09-151-1/+2
| | | | | | | | When fixing the conflicts caused by gallatin's commit and the reviewed patch, I missed this location because it didn't exist when gallatin did their change. Obtained from: Juniper Networks, Inc.
* e1000: fix igb VF statsJohn-Mark Gurney2025-09-122-128/+232
| | | | | | | | | | | igb VF must not read normal stat registers and only read a limited set of registers. The PF registers also don't make since as the VF is an internal port, and there is no PHY to collect stats like CRC errors from. PR: 282309 Obtained from: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D52326
* iflib: report output drops and handle ENOBUFS properlyAndrew Gallatin2025-09-101-2/+2
| | | | | | | | | | | | | | | | | | | | - Fix an mbuf leak with iflib.simple_tx=1 when we run out of tx descs in iflib_encap(). It seems odd to free the mbuf in iflib_encap(), but that routine consumes mbufs for other reasons, and it seemed safest to free there rather than have the simple tx routine parse return values to determine what needed to be freed. - Increment counters for output drops when ENOBUFS is encountered and output errors when other transmit errors are encountered for both the simple and normal tx routines. - Performed driver changes so that iflib drivers now add the generic output drop and output error counters to their private counters in their ifdi_get_counter routines. Reviewed by: kbowling, markj Differential Revision: https://reviews.freebsd.org/D52369 Sponsored by: Netflix
* Revert "e1000: Try auto-negotiation for fixed 100 or 10 configuration"Kevin Bowling2025-08-192-41/+8
| | | | | | | | | | | | | | We've gotten a report of this breaking a fixed no autoneg setup. Since no link is worse than what this intends to fix (negotiating full duplex at forced speed), revert for the undeway 15.0 release cycle until this can be further reviewed. PR: 288827 MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D47336 This reverts commit 645c45e297c0fcbbb9d2d24cdeeb124234825019.
* e1000: Fix some issues in em_newitr()Mark Johnston2025-05-271-18/+22
| | | | | | | | | | | | - Load packet and byte counters exactly once, as they can be concurrently mutated. - Rename bytes_packets to bytes_per_packet, which seems clearer. - Use local variables that have the same types as the counter values, rather than truncating unsigned long to u32. Reviewed by: kbowling MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50416
* e1000: Initialize helper variables in em_newitr()Mark Johnston2025-05-271-0/+1
| | | | | | | | | | | | Due to races with the threaded transmit and receive paths, it's possible to have r/tx_bytes != 0 && r/tx_packets == 0, in which case the maximum byte count could be left uninitialized. Initialize them to zero to handle this case. PR: 286819 Reviewed by: kbowling MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50416
* dev: Use recently added improvements to PME# support to simplify driversJohn Baldwin2025-03-271-7/+3
| | | | | | | | | | Depend on the PCI bus driver clearing PME# after resume to remove the need for clearing PME# from DEVICE_RESUME methods. Use pci_has_pm and pci_enable_pme. Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com> Differential Revision: https://reviews.freebsd.org/D49251
* e1000: Fix vlan PCP/DEI on lem(4)Aurelien Cazuc2025-02-132-3/+1
| | | | | | | | | | | | | | The vlan PCP and CFI/DEI were discarded when receiving vlan tagged packets on lem(4) interfaces with vlanhwtag. According to the 82540 SDM[1] (pg. 24), vlan tag is in the standard format, so there's no reason to discard PCP/DEI. [1]: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf MFC after: 3 days Sponsored by: Stormshield (author) Differential Revision: https://reviews.freebsd.org/D48987
* e1000: Remove old itr sysctl handlerKevin Bowling2024-11-291-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implementation had various bugs. bde@ reported that the unit conversion/scaling is wrong, and it also does not handle 82574L or igb(4) devices correctly. With the new AIM code, it is expected most users will not need to manually tune this. If you do need static control: hw.em.enable_aim=0 for all interfaces at boot or dev.em.X.enable_aim=0 for individual interfaces at runtime and they will track the hw.em.max_interrupt_rate tunable. That codepath has been bugfixed for all supported chipsets. You may view the current rate with dev.em.X.queue_rx_0.interrupt_rate which has been bugfixed for all supported chipsets. If you need to set different rates per interface for some reason let me know and I will rethink how to add this back. Otherwise you can leave AIM on for general purpose interfaces and disable it at runtime on special purpose low or high latency interfaces that would track hw.em.max_interrupt_rate if you have a mix of concerns. PR: 235031 Reported by: Bruce Evans <bde@FreeBSD.org> MFC after: 3 days Relnotes: yes Sponsored by: BBOX.io
* e1000: Style txrxKevin Bowling2024-11-243-40/+62
| | | | | | | Fix up indentation and reflow long lines. MFC after: 3 days Sponsored by: BBOX.io
* e1000: Style pass on if_emKevin Bowling2024-11-241-426/+619
| | | | | | | Fix up some indentation and reflow long lines MFC after: 3 days Sponsored by: BBOX.io
* e1000: Try auto-negotiation for fixed 100 or 10 configurationKevin Bowling2024-11-242-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a retread of https://reviews.freebsd.org/D34449 which I think will fix the issue for the remote side not supporting autoneg. We now attempt an autoneg, and if that fails fall back to the current code that forces the link speed/duplex. The original intent of this patch is to inform the remote switch of duplex settings when we (the client) are specifying a fixed 10 or 100 speed. Otherwise it may get the duplex setting wrong. The tricky case is when the remote (switch) side is fixing its speed AND duplex while disabling autoneg and we (client) need to do the same, which still seems to be common enough at some ISPs. Original commit message follows: Currently if an e1000 interface is set to a fixed media configuration, for gigabit, it will participate in auto-negotiation as required by IEEE 802.3-2018 Clause 37. However, if set to fixed media configuration for 100 or 10, it does NOT participate in auto-negotiation. By my reading of Clauses 28 and 37, while auto-negotiation is optional for 100 and 10, it is not prohibited and is, in fact, "highly recommended". This patch enables auto-negotiation for fixed 100 and 10 media configuration, in a similar manner to that already performed for 1000. I.e., the patch enables advertising of just the manually configured settings with the goal of allowing the remote end to match the manually configured settings if it has them available. To be clear, this patch does NOT allow an em(4) interface that has been manually configured with specific media settings to respond to auto-negotiation by then configuring different parameters to those that were manually configured. The intent of this patch is to fully comply with the requirements of Clause 37, but for 100 and 10. The need for this has arisen on an em(4) link where the other end is under a different administrative control and is set to full auto-negotiation. Due to the cable length GigE is not working well. It is desired to set the em(4) end to "media 100baseTX mediatype full-duplex" which does work when both ends are configured that way. Currently, because em(4) does not participate in autoneg for this setting, the remote defaults to half-duplex - i.e., there's a duplex mismatch and things don't work. With this patch, em(4) would inform the remote that it has only 100baseTX full, the remote would match that and it will work. Tested by: Natalino Picone <natalino.picone@nozominetworks.com> Tested by: Franco Fichtner <franco@opnsense.org> Tested by: J.R. Oldroyd <fbsd@opal.com> (previous version) Sponsored by: Nozomi Networks Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D47336
* e1000: sysctl for TCP flag handling during TSOMichael Tuexen2024-11-211-0/+56
| | | | | | | | | | | | | | Add tso_tcp_flags_mask_first_segment, tso_tcp_flags_mask_middle_segment, and tso_tcp_flags_mask_last_segment sysctl-variables to control the handling of TCP flags during TSO. This allows to change the masks appropriate for classical ECN and to configure appropriate masks for accurate ECN. Reviewed by: rrs MFC after: 3 days Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D44259
* e1000: Improve igb(4) SFP supportKevin Bowling2024-11-071-19/+21
| | | | | | | | | | | | | | | | * Adds support for SFPs that are not correctly coded as an SFP transceiver. i.e. Coherent-Finisar FCLF8522P2BTL. * Configures multi-rate SFPs i.e. Coherent-Finisar FCLF8522P2BTL as SGMII so they can do 10/100/1000 auto-negotiation. * Adds support for 100BaseLX SGMII transceivers. * Some code cleanup and additional debugging. Reviewed by: emaste, markj, Franco Fichtner <franco@opnsense.org> Tested by: Natalino Picone <natalino.picone@nozominetworks.com> MFC after: 2 weeks Sponsored by: Nozomi Networks Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D47337
* e1000: Move I219 LM19/V19 to ADLKevin Bowling2024-10-243-6/+6
| | | | | | | | | | | This roughly corresponds to Linux 9d9e5347b035412daa844f884b94a05bac94f864 For FreeBSD this is currently not expected to cause any difference in behavior because we do not have the MTP force smbus changes for modern standby. MFC after: 3 days Sponsored by: BBOX.io
* e1000: txrx function prototype cleanupKevin Bowling2024-10-142-35/+30
| | | | | | | | Drop variable names of function prototypes since the file is mixed in listing them or not and they fall out of sync. MFC after: 1 week Sponsored by: BBOX.io
* e1000: Re-add AIMKevin Bowling2024-10-114-12/+299
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We originally left this out because iflib modulates interrupts and accomplishes some level of batching versus the custom queues in the older driver. Upon more detailed study of the Linux driver which has a newer implementation, it finally became clear to me this is actually a holdoff timer and not an interrupt limit as it is conventionally (statically) programmed and displayed as an interrupt rate. The data sheets also make this somewhat clear. Thus, AIM accomplishes two beneficial things for a wide variety of workloads[1]: 1. At low throughput/packet rates, it will significantly lower latency (by counter-intuitively "increasing" the interrupt rate.. better thought of as decreasing the holdoff timer because you will modulate down before coming anywhere near these interrupt rates). 2. At bulk data rates, it is tuned to achieve a lower interrupt rate (by increasing the holdoff timer) than the current static 8000/s. This decreases processing overhead and yields more headroom for other work such as packet filters or userland. For a single NIC this might be worth a few sys% on common CPUs, but may be meaningful when multiplied such as if_lagg, if_bridge and forwarding setups. The AIM algorithm was re-introduced from the older igb or out of tree driver, and then modernized with permission to use Intel code from other drivers. I have retroactively added it to lem(4) and em(4) where the same concept applies, albeit to a single ITR register. [1]: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/gbe-controllers-interrupt-moderation-appl-note.pdf Tested by: cc (https://wiki.freebsd.org/chengcui/testD46768) MFC after: 1 week Relnotes: yes Sponsored by: Rubicon Communications, LLC ("Netgate") Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D46768
* Revert "e1000: Remove redundant EITR shift from igb"Kevin Bowling2024-09-281-1/+2
| | | | | | Turns out this is necessary This reverts commit 26439b57877ccae7a2404f7d179afaa5ddb2f64d.
* e1000: Remove redundant EITR shift from igbKevin Bowling2024-09-281-2/+1
| | | | | | | | The E1000_EITR() macro is already multiplying by 0x4 which is the same as this shift, so we were shifting more than expected. MFC after: 6 days Sponsored by: BBOX.io
* e1000: Clean up ITR/EITR in preparation for AIMKevin Bowling2024-09-272-14/+17
| | | | | | | | | | | | Provide macros to derive the various needed values and make it a bit more clear the differences between em and igb. The igb default EITR was not landing at the right offset. Respect the 'max_interrupt_rate' tunable. MFC after: 1 week Sponsored by: BBOX.io
* e1000: Clean up legacy absolute and packet timersKevin Bowling2024-09-271-57/+59
| | | | | | | | | | | The absolute and packet timers only apply to lem and em with some only applying to the later. This cleans up the sysctl tree to only show these where applicable and stops writing to unexpected registers for igb. MFC after: 1 week Sponsored by: BBOX.io
* e1000: Delay safe_pause switch until SI_SUB_CLOCKSJoyu Liao2024-09-252-2/+14
| | | | | | | | | | | | | | | | | | | | | | Based on sysinit_sub_id, SI_SUB_CLOCKS is after SI_SUB_CONFIGURE. SI_SUB_CONFIGURE  = 0x3800000,  /* Configure devices */   At this stage, the variable “cold” will be set to 0. SI_SUB_CLOCKS    = 0x4800000,  /* real-time and stat clocks*/ At this stage, the clock configuration will be done, and the real-time clock can be used. In the e1000 driver, if the API safe_pause_* are called between SI_SUB_CONFIGURE and SI_SUB_CLOCKS stages, it will choose the wrong clock source. The API safe_pause_* uses “cold” the value of which is updated in SI_SUB_CONFIGURE, to decide if the real-time clock source is ready. However, the real-time clock is not ready til the SI_SUB_CLOCKS routines are done. Obtained from: Juniper Networks MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D42920
* e1000: Add sysctl for igb(4) DMA CoalesceKevin Bowling2024-09-241-0/+56
| | | | | | | | | | | | | | This feature can increase efficiency at the expense of latency It does not work well with the default interrupt delay, but expose the otherwise unconnected code in the driver in case people want to experiment. See https://www.intel.com/content/dam/support/us/en/documents/network/adapter/pro100/sb/466827_intel_r__dma_coalescing_white_paper_v003.pdf MFC after: 1 week Sponsored by: Blue Box Systems
* e1000: Handle igb EEE sysctlKevin Bowling2024-09-241-3/+12
| | | | | MFC after: 1 week Sponsored by: Blue Box Systems
* e1000: Add sysctls for some missing MAC statsKevin Bowling2024-09-241-0/+19
| | | | | MFC after: 1 week Sponsored by: Blue Box Systems
* e1000: drop NEEDGIANT from em_sysctl_debug_info useKevin Bowling2024-09-221-1/+1
| | | | | | | The write is only used to toggle the debug print function and this is otherwise stateless. MFC after: 1 week
* e1000: drop NEEDGIANT on em_sysctl_reg_handler usesKevin Bowling2024-09-221-6/+6
| | | | | | These are simple singular diagnostic register reads MFC after: 1 week
* e1000: remove NEEDGIANT from a couple sysctlsKevin Bowling2024-09-221-2/+2
| | | | | | These are internally locked already MFC after: 1 week
* e1000: Update igb driver version to 2.5.28-fbsdKevin Bowling2024-09-214-10/+11
| | | | | | | Bump to the current out of tree driver version since we only have some gratuitous changes. MFC after: 1 week
* e1000: fix link power downAnatoly Burakov2024-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | DPDK commit message net/e1000/base: fix link power down Current code is a result of work to reduce duplication between various device models. However, the logic that was replaced did not exactly match the new logic, and as a result the link power down was not working correctly for some NICs, and the link remained up even when the interface is down. Fix it to correctly power down the link under all circumstances that were supported by old logic. Fixes: 44dddd1 ("net/e1000/base: remove duplicated codes") Cc: stable@dpdk.org Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com> Obtained from: DPDK (a8218d0) MFC after: 1 week
* e1000: Fix a typo in a source code commentGordon Bergling2024-09-181-1/+1
| | | | | | - s/chekcsums/checksums/ MFC after: 3 days
* e1000(4): Remove disconnected SYSCTLMarius Strobl2024-01-092-13/+0
| | | | | | | | The global hw.em.rx_process_limit knob has been replaced by the device- specific dev.IF.N.iflib.rx_budget along with the conversion to iflib(4). While at it, remove the - besides initialization of tx_process_limit - unused {r,t}x_process_limit members.
* iflib: invert default restart on VLAN changesKevin Bowling2023-08-241-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In rS360398, a new iflib device method was added to opt out of VLAN events needing an interface reset. I am switching the default to not requiring a restart for: * VLAN events * unknown events After fixing various bugs, I do not think this would be a common need of hardware and it is undesirable from the user's perspective causing link flaps and much slower VLAN configuration. Currently, there are no other restart events besides VLAN events, and setting the ifdi_needs_restart default to false will alleviate the need to churn every driver if an odd event is added in the future for specific hardware. markj points out this could cause churn in the other direction; I will solve that problem with an event registration system as he mentions in the review should we need it in the future. These drivers will opt into restart and need further inspection or work: * ixv (needs code audit, 61a8231 fixed principal issue; re-init probably not necessary) * axgbe (needs code audit; re-init probably not necessary) * iavf - (needs code audit; interaction with Malicious Driver Detection mentioned in rS360398) * mgb - no VLAN functions are currently implemented. Left a comment. MFC after: 2 weeks Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D41558
* iflib drivers: Constify PCI ID LUTsMarius Strobl2023-08-171-4/+4
| | | | | | | | Since d49e83eac3baf16a22b1c5d42e8438b68b17e6f9, iflib(9) is ready for this change. While at it, make isc_driver_version strings (static) const where not apparently un-const on purpose, too. This reduces the size of the amd64 GENERIC by about 10 KiB.
* sys: Remove $FreeBSD$: one-line bare tagWarner Losh2023-08-162-2/+0
| | | | Remove /^\s*\$FreeBSD\$$\n/
* sys: Remove $FreeBSD$: one-line .c comment patternWarner Losh2023-08-1641-41/+0
| | | | Remove /^/[*/]\s*\$FreeBSD\$.*\n/
* e1000: Fix off by one ipcseKevin Bowling2023-08-151-1/+1
| | | | | | | | This has been off by one in the FreeBSD drivers as far back as I've looked. Emperically HW and SW emulations I have available don't seem to mind. Noticed while debugging other issues. MFC after: 3 days
* e1000: disable TSO on lem(4) and em(4)Kevin Bowling2023-08-151-0/+6
| | | | | | | | | Disable TSO on lem(4) and em(4) until a ring stall can be debugged. I am not able to reproduce the issue on lem(4) but disabling there in abundance of caution in case the issue is not specific to em(4). Reported by: grog
* e1000: Enable TSO on 82574Kevin Bowling2023-08-091-3/+0
| | | | | | | | Further testing indicates something wrong with particular reciever, enabling TSO 82574 for wider testing. Tested by: karels MFC after: 3 months
* e1000: Enable TSO for lem(4) and em(4)Kevin Bowling2023-08-031-29/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most em(4) devices now enjoy TSO and TSO6, matching NetBSD and Linux defaults. A prior commit automasks TSO on 10/100 Ethernet due to errata and other bugs for IPv6 were fixed recently allowing this. Mike Karels identified a performance anomaly on Intel 82574L devices. These are multiqueue enabled on FreeBSD since the conversion to iflib. I am investigating whether this can be fixed, in the mean time MSI-X with checksum offloads remain default. i219 SPT devices have an errata that downclocks the DMA engine, which results in TSO not being able to acheive line rate. Therefore, it is disabled on: * Intel(R) I219-LM and I219-V SPT * Intel(R) I219-LM and I219-V SPT-H (2) * Intel(R) I219-LM and I219-V LBG (3) * Intel(R) I219-LM and I219-V SPT (4) * Intel(R) I219-LM and I219-V SPT (5) Many lem(4) devices enjoy TSO, exceptions being 82542, 82543, 82547. TSO6 may be possible for some chipsets but I am still working through my testing matrix and that is hidden behind hw.em.unsupported_tso. If you encounter issues, you may disable TSO with for example: ifconfig em0 -tso -tso6. I ask to be informed of any deviations from normal operation requiring this. Thanks to cc@ for access to emulab.net. On a sample I219 system it saves about 16% CPU on IPv4 and 19% on IPv6. iperf3 -Vc reported numbers: total% user% system% IPv4 TSO 21.3 7 14.4 21.4 6 15.4 21.5 6 15.5 IPv4 no TSO 36.8 5.4 31.4 38.5 5.1 33.5 38.2 5.7 32.6 IPv4 no TSO no TXCSUM 45.1 5.8 39.3 46 6.3 39.7 46.2 5.9 40.4 IPv6 TSO6 21.7 5.4 16.3 21.6 5.1 16.5 21.9 5.6 16.3 IPv6 no TSO6 41.2 5.2 36 41 5.1 36 40.8 5.2 35.7 IPv6 no TSO6 no TXCSUM6 49 5.9 43.1 48.8 4.9 43.9 49 5.6 43.4 Tested by: cc (lem(4)), karels (82574L) MFC after: 3 months Relnotes: yes Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D41170
generated by cgit v1.3 (git 2.53.0) at 2026-05-28 10:31:21 +0000