aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/e1000
Commit message (Collapse)AuthorAgeFilesLines
* e1000: Fix vlan PCP/DEI on lem(4)Aurelien Cazuc13 days2-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 Sponsored by: Stormshield (author) Differential Revision: https://reviews.freebsd.org/D48987 (cherry picked from commit 4b29599fbbe33b75b7b58cfc5deea7a881e9a10e)
* e1000: Remove old itr sysctl handlerKevin Bowling2024-12-031-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> Relnotes: yes Sponsored by: BBOX.io (cherry picked from commit 4020351325c02cc27aa4992c199ff18a9542a52c)
* e1000: Try auto-negotiation for fixed 100 or 10 configurationKevin Bowling2024-11-272-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 (cherry picked from commit bceec3d80a3caf9249e24247fb937674bf5b46b5)
* e1000: Style txrxKevin Bowling2024-11-273-40/+62
| | | | | | | | Fix up indentation and reflow long lines. Sponsored by: BBOX.io (cherry picked from commit 7390daf87c53073da5e74b2d73ac7320c1a44475)
* e1000: Style pass on if_emKevin Bowling2024-11-273-437/+630
| | | | | | | | Fix up some indentation and reflow long lines Sponsored by: BBOX.io (cherry picked from commit 6f14883066f10afc9e3e2af45c5b509586f9da9e)
* e1000: sysctl for TCP flag handling during TSOMichael Tuexen2024-11-241-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 Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D44259 (cherry picked from commit 90853dfac851afa9e8840f5a38383256d75458b6)
* e1000: Improve igb(4) SFP supportKevin Bowling2024-11-211-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> Sponsored by: Nozomi Networks Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D47337 (cherry picked from commit 15853a5fc9548d9805a2ef22f24e2eb580198341)
* e1000: txrx function prototype cleanupKevin Bowling2024-10-212-37/+32
| | | | | | | | | Drop variable names of function prototypes since the file is mixed in listing them or not and they fall out of sync. Sponsored by: BBOX.io (cherry picked from commit 9dc452b983f042aa9d2a2562517d44c1928ff42a)
* e1000: Re-add AIMKevin Bowling2024-10-184-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) Relnotes: yes Sponsored by: Rubicon Communications, LLC ("Netgate") Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D46768 (cherry picked from commit 3e501ef896671cb190e8c40c6258b8f27d136f07)
* e1000: Clean up ITR/EITR in preparation for AIMKevin Bowling2024-10-042-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. Sponsored by: BBOX.io (cherry picked from commit 9bf9164fc8aad1ca828c725413e06462aef1e4dd)
* e1000: Clean up legacy absolute and packet timersKevin Bowling2024-10-041-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. Sponsored by: BBOX.io (cherry picked from commit 1c578f1c93112d3d53820f8b6b411488b83f0ab2)
* e1000: Delay safe_pause switch until SI_SUB_CLOCKSJoyu Liao2024-10-022-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 Differential Revision: https://reviews.freebsd.org/D42920 (cherry picked from commit 930a1e6f3d2dd629774f1b48b1acf7ba482ab659)
* e1000: Add sysctl for igb(4) DMA CoalesceKevin Bowling2024-10-021-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 Sponsored by: Blue Box Systems (cherry picked from commit c9021340a3266f924bf721182f14f2d265d8a82c)
* e1000: Handle igb EEE sysctlKevin Bowling2024-10-021-3/+12
| | | | | | Sponsored by: Blue Box Systems (cherry picked from commit 2e78e568c268e4ba846ab140d9ac6b42886f8ec7)
* e1000: Add sysctls for some missing MAC statsKevin Bowling2024-10-021-0/+19
| | | | | | Sponsored by: Blue Box Systems (cherry picked from commit aa7d086ad94642fa40375db9976177fc9e54a2cf)
* e1000: drop NEEDGIANT from em_sysctl_debug_info useKevin Bowling2024-09-291-1/+1
| | | | | | | The write is only used to toggle the debug print function and this is otherwise stateless. (cherry picked from commit 5f6964d9fbf663f85ee60dae7dfff153b82759d8)
* e1000: drop NEEDGIANT on em_sysctl_reg_handler usesKevin Bowling2024-09-291-6/+6
| | | | | | These are simple singular diagnostic register reads (cherry picked from commit c11a0649b97281699e39d0fc82818f235c1dfb87)
* e1000: remove NEEDGIANT from a couple sysctlsKevin Bowling2024-09-291-2/+2
| | | | | | These are internally locked already (cherry picked from commit f6e1b567921187b9331bd71c86e94cf232dd7761)
* e1000: Update igb driver version to 2.5.28-fbsdKevin Bowling2024-09-284-10/+11
| | | | | | | Bump to the current out of tree driver version since we only have some gratuitous changes. (cherry picked from commit ddfec1fb6814088abc5805f45c4a18c5731d51b9)
* e1000: fix link power downAnatoly Burakov2024-09-261-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) (cherry picked from commit 811912c46b5886f1aa3bb7a51a6ec1270bc947a8)
* e1000: Fix a typo in a source code commentGordon Bergling2024-09-211-1/+1
| | | | | | - s/chekcsums/checksums/ (cherry picked from commit 3e614fb600f233097ee5e007cbffdb3001aa110b)
* e1000(4): Remove disconnected SYSCTLMarius Strobl2024-01-182-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. (cherry picked from commit 0d6d28ce5650d1cd23dbe4bbac87fb103b3e2d3d)
* iflib drivers: Constify PCI ID LUTsMarius Strobl2024-01-051-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. (cherry picked from commit 51e235148a4becba94e824a44bd69687644a7f56) Conflicts (drivers missing in stable/13): sys/dev/enetc/if_enetc.c sys/dev/enic/if_enic.c
* iflib: invert default restart on VLAN changesKevin Bowling2023-09-111-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. Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D41558 (cherry picked from commit 725e4008efef32dfbe57b3e21635fa80dde8ee38)
* sys: Remove $FreeBSD$: one-line bare tagWarner Losh2023-08-232-2/+0
| | | | | | | Remove /^\s*\$FreeBSD\$$\n/ Similar commit in current: (cherry picked from commit 78d146160dc5)
* sys: Remove $FreeBSD$: one-line .c comment patternWarner Losh2023-08-2341-41/+0
| | | | | | | Remove /^/[*/]\s*\$FreeBSD\$.*\n/ Similar commit in current: (cherry picked from commit 71625ec9ad2a)
* e1000: Some fixes for hardware capabilitiesKevin Bowling2023-08-181-29/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MFC squash retains disabled TSO ultimately, but contains some capability fixes. f1b5488f: e1000: Enable TSO for lem(4) and em(4) 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) Relnotes: yes Sponsored by: BBOX.io Differential Revision: https://reviews.freebsd.org/D41170 13da8423: e1000: Enable TSO on 82574 Further testing indicates something wrong with particular reciever, enabling TSO 82574 for wider testing. Tested by: karels 797e480c: e1000: disable TSO on lem(4) and em(4) 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 (cherry picked from commit f1b5488f7bba7f25a57750f87cbcbccbd5b9d16b) (cherry picked from commit 13da84237a37961938e9e237171ac111ddc1897c) (cherry picked from commit 797e480cba8834e584062092c098e60956d28180)
* e1000: Fix off by one ipcseKevin Bowling2023-08-181-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. (cherry picked from commit eac761e967b34066aa7183474249df87d79a2f32)
* e1000: Automask TSO on lem(4)/em(4) 10/100 EthernetKevin Bowling2023-08-102-2/+49
| | | | | | | | | | | | | This feature masks TSO capability when a link comes up at 10 or 100mbit due to errata on the chips. This behavior matches previous versions of FreeBSD as well as NetBSD and Linux. A tunable, hw.em.unsupported_tso may be set if the admin desires to disabling automasking and configure TSO settings manually. Differential Revision: https://reviews.freebsd.org/D41170 (cherry picked from commit 2ddf24f8f52559b08da700ab044c33d0a9ed5601)
* e1000: Fix lem(4)/em(4) TSO6Kevin Bowling2023-08-072-21/+28
| | | | | | | | | | | | * Fix TSO6 by specializing IP checksum insertion and following Intel SDM values for IPv6. * Remove unnecessary 82544 IP-bit handling * Remove TSO6 from lem(4) capabilitities Reviewed by: erj (earlier version) Differential Revision: https://reviews.freebsd.org/D41170 (cherry picked from commit e1353dcb63bbdb33be6a907ed6236c120518129e)
* e1000: HWCSUM excemption fixesKevin Bowling2023-08-041-2/+3
| | | | | | | | | | | Also disable IPV6 checksum offload. Spell hw->mac.type < e1000_82543 as e1000_82542. Confusingly, chips like 82540 and 82541 come later and do not have these issues. There is no functional change here, as the enum was defined in such a way it worked correctly. But this reads literally. (cherry picked from commit 38588749af45d738e6f548f15beb415c46ba8658)
* e1000: Corrections for lem(4)/em(4) txcsum offloadKevin Bowling2023-08-042-21/+27
| | | | | | | | | | | Explicitly set ipcss/ipcse/ipcso for IPv6 per intel SDM as indicated in inline comments. Fix and consolidate 82543/82547 hwcsum exemption. While here rearrange and expand some commentary. (cherry picked from commit cbcab907f8ad1a4ac38dbc574c747ac2901faa54)
* e1000: add missing parens in csum setupKevin Bowling2023-08-041-1/+1
| | | | | | | Reported by: rscheff Fixes: 4f9a44a215f8 e1000: Fix/enable IPv6 transmit checksum offload (cherry picked from commit 92fd2f39e5b1fd588fdc49a07d626273eb8f7539)
* e1000: Fix/enable IPv6 transmit checksum offloadKevin Bowling2023-08-042-4/+7
| | | | | | | | Fixes and enables txcsum6 offload for lem(4) and em(4). MFC after: 2 weeks (cherry picked from commit 4f9a44a215f873c6842a693f2e81e0abbe1531cf)
* e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixesKevin Bowling2023-08-042-26/+46
| | | | | | | | | | | | | | | | | * em(4) obey administrative ifcaps for using hwcsum offload * em(4) obey administrative ifcaps for hw vlan receive tagging * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4 * lem(4) obey administrative ifcaps for using hwcsum offload * lem(4) add support for hw vlan receive tagging * lem(4) Add ifcaps for TSO offload experimentation, but disabled by default due to errata and possibly missing txrx code. * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around full duplex links. It may still be administratively enabled. Reviewed by: markj (previous version) Differential Revision: https://reviews.freebsd.org/D30072 (cherry picked from commit 918c25677d882a901696672bd4d39b62faa56dfa)
* Revert "e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixes"Kevin Bowling2023-08-042-40/+23
| | | | This reverts commit bd07d5c451995353cbf1d86f97c5264232ea401b.
* e1000: lem(4)/em(4) ifcaps, TSO and hwcsum fixesKevin Bowling2023-08-042-23/+40
| | | | | | | | | | | | | | | | | * em(4) obey administrative ifcaps for using hwcsum offload * em(4) obey administrative ifcaps for hw vlan receive tagging * em(4) add additional TSO6 ifcap, but disabled by default as is TSO4 * lem(4) obey administrative ifcaps for using hwcsum offload * lem(4) add support for hw vlan receive tagging * lem(4) Add ifcaps for TSO offload experimentation, but disabled by default due to errata and possibly missing txrx code. * lem(4) disable HWCSUM ifcaps by default on 82547 due to errata around full duplex links. It may still be administratively enabled. Reviewed by: markj (previous version) Differential Revision: https://reviews.freebsd.org/D30072 (cherry picked from commit 95f7b36e8fac45092b9a4eea5e32732e979989f0)
* e1000: Some fixes for em(4) TSO setupKevin Bowling2023-08-041-6/+19
| | | | | | | | | | Always set TXD_CMD_IP for 82544 Otherwise set TXD_CMD_IP for IPv4, not IPv6 Reviewed by: markj (previous version) Differential Revision: https://reviews.freebsd.org/D30072 (cherry picked from commit 201c4b7c29da44500ccb9e47b854dc1207df8b0a)
* e1000: Add SPDX tag to em_txrxKevin Bowling2023-06-271-0/+2
| | | | | | | Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D30072 (cherry picked from commit 034f38cdf864e6794fd63b67bf16c59627576699)
* e1000: Format em_txrxKevin Bowling2023-06-271-31/+46
| | | | | | | | | No functional changes intended. Reviewed by: markj (prior version) Differential Revision: https://reviews.freebsd.org/D30072 (cherry picked from commit 5253d74e4650300815af351cc510a1c392a16584)
* e1000: fix VLAN 0Kristof Provost2023-05-151-1/+3
| | | | | | | | | | | | | | | | | | VLAN 0 essentially means "Treat as untagged, but with priority bits", and is used by some ISPs. On igb/em interfaces we did not receive packets with VLAN tag 0 unless vlanhwfilter was disabled. This can be fixed by explicitly listing VLAN 0 in the hardware VLAN filter (VFTA). Do this from em_setup_vlan_hw_support(), where we already (re-)write the VFTA. Reviewed by: kbowling Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D40046 (cherry picked from commit 0229fab2fe0eed843ebec98fd31b7d49bb2e8438)
* e1000: Fix packet loss on 11th gen and laterKevin Bowling2023-02-231-0/+7
| | | | | | | | | | | | | | Ungate DMA clock on TGP and later to avoid packet loss. A similar fix appears in Linux 639e298f432fb058a9496ea16863f53b1ce935fe This may be needed as far back as SPT but no confirmation from intel or other OS yet. Obtained from: OpenBSD (if_em_hw.c 1.116) Sponsored by: BBOX.io (cherry picked from commit 56365902147791994157c3a8f75784dafd46dbd8)
* e1000: Add support for future client platformsKevin Bowling2023-02-234-0/+54
| | | | | | Sponsored by: BBOX.io (cherry picked from commit 905ae5881bdc1b9742e08d660d787204c08d6022)
* e1000: Remove redundant disable_ulp for ich8lanKevin Bowling2023-02-232-8/+5
| | | | | | | | | | | This call only makes sense for ich8lan, and the shared code does it in e1000_setup_init_funcs() above this deletion. Obtained from: DPDK Sponsored by: BBOX.io Pull Request: https://github.com/freebsd/freebsd-src/pull/539 (cherry picked from commit d36fbdb08ff567393a698aaf16f726275901ec96)
* e1000: bump driver versionKevin Bowling2023-02-221-2/+3
| | | | | | | | | | | Incrementing these to avoid confusion in users; we are on par with these out of tree versions. Reviewed by: erj Sponsored by: BBOX.io Pull Request: https://github.com/freebsd/freebsd-src/pull/540 (cherry picked from commit 647f2d2bc0cb9357ac083bf2aae4b669167dd66b)
* e1000: fix I219 hang on resetKevin Bowling2023-02-221-2/+117
| | | | | | | | | | | | Clear the rings before reset to avoid a HW hang. Inspired by em-7.7.8 and DPDK (1fc9701238edcf0541289b9ae15565b6d9d7ab30) Reviewed by: erj Sponsored by: BBOX.io Pull Request: https://github.com/freebsd/freebsd-src/pull/540 (cherry picked from commit ae1dca798e0f826de46f4ec11914ba4c91928d7a)
* Revert "e1000: Try auto-negotiation for fixed 100 or 10 configuration"Kevin Bowling2022-10-121-12/+8
| | | | | | | | | | This reverts commit 9ab4dfce8feda8cf3545be0c3c7569095b1fcd24. OPNsense users have reported a regression with fixed configs. The e1000 api is not ready for this change. (cherry picked from commit 66dad2db0a484d65df331df76db0b68ef518f4db)
* e1000: Increase rx_buffer_size to 32bKevin Bowling2022-05-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the size of the local rx_buffer_size variable to account for larger buffer sizes possible on 82580, i350 chips. From i350 datasheet, 6.2.10 Initialization Control 4 (LAN Base Address + Offset 0x13): When 4 ports are enabled maximum buffer size is 36 KB. When 2 ports are enabled maximum buffer size is 72 KB. When only a single port is enabled maximum buffer size is 144 KB. and 8.3: The overall available internal buffer size in the I350 for all ports is 144 KB for receive buffers and 80 KB for transmit Buffers. Disabled ports memory can be shared between active ports and sharing can be asymmetric. The default buffer size for each port is loaded from the EEPROM on initialization. From the reporter: But for I350 when only 2 ports are used PBA size can be set as 72KB (see datasheet RXPbsize or e1000_rxpbs_adjust_82580 function in e1000_82575.c). In this case calculating the rx_buffer_size overflows as 0x0048 << 10 = 73728 or 0x12000 pushed into u16. It is then set as 0x2000 or 8192. PR: 263896 Reported by: hannula@gmail.com Tested by: hannula@gmail.com Approved by: markj Differential Revision: https://reviews.freebsd.org/D35167 (cherry picked from commit 6987c47569b377f4b6eba9966afdedfb1b39fca8)
* e1000: Try auto-negotiation for fixed 100 or 10 configurationJ.R. Oldroyd2022-04-271-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Approved by: erj Differential Revision: https://reviews.freebsd.org/D34449 (cherry picked from commit 9ab4dfce8feda8cf3545be0c3c7569095b1fcd24)
* e1000: Update mc filter before RCTL flagsKevin Bowling2022-04-271-3/+3
| | | | | | | | Update mc filter array before changing RCTL flags as in 5a3eb6207a35 Approved by: grehan (cherry picked from commit 07ede751612f8879675e2970b3875ea3831e2b9c)
generated by cgit v1.2.3 (git 2.25.1) at 2025-02-28 15:58:30 +0000