#
c58d34dd |
| 24-Nov-2024 |
Kevin Bowling <kbowling@FreeBSD.org> |
ixgbe: Style pass on FreeBSD part of driver
Fix up some indentation and reflow long lines
MFC after: 3 days Sponsored by: BBOX.io
|
#
f72de14e |
| 21-Sep-2024 |
Kevin Bowling <kbowling@FreeBSD.org> |
ixgbe: update if_ix and ixgbe api with ix-3.3.38 changes
MFC after: 1 week
|
Revision tags: release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
71625ec9 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c comment pattern
Remove /^/[*/]\s*\$FreeBSD\$.*\n/
|
#
a0302c92 |
| 11-Jul-2023 |
Piotr Pietruszewski <piotr.pietruszewski@intel.com> |
ix, ixv: Update link status with autonegotiated baudrate value
Use autonegotiated link speed value while updating link status to iflib.
This patch is part of change made in NetBSD kernel by Masanob
ix, ixv: Update link status with autonegotiated baudrate value
Use autonegotiated link speed value while updating link status to iflib.
This patch is part of change made in NetBSD kernel by Masanobu Saitoh, NetBSD maintainer.
Differential Revision: https://reviews.freebsd.org/D19176 Approved by: erj
show more ...
|
Revision tags: release/13.2.0 |
|
#
8de48df3 |
| 02-Feb-2023 |
Andrew Gallatin <gallatin@FreeBSD.org> |
ixgbe: Do not count L3/L4 checksum errors as input errors
NIC input errors have traditionally indicated problems at the link level (crc errors, runts, etc). People tend to build monitoring infrastr
ixgbe: Do not count L3/L4 checksum errors as input errors
NIC input errors have traditionally indicated problems at the link level (crc errors, runts, etc). People tend to build monitoring infrastructure around such errors in order to monitor for bad network hardware. When L3/L4 checksum errors are included in the category of input errors, it breaks such monitoring, as these errors can originate anywhere on the internet, and do not necessarily indicate faulty local network hardware.
Reviewed by: erj, glebius Differential Revision: https://reviews.freebsd.org/D38346 Sponsored by: Netflix
show more ...
|
Revision tags: release/12.4.0, release/13.1.0 |
|
#
d381c807 |
| 04-Mar-2022 |
Piotr Pietruszewski <piotr.pietruszewski@intel.com> |
ix(4): Add control of 2.5/5G autonegotiation speeds
This change enables the user to control 2.5G and 5G autonegotiation speeds via advertise_speed sysctl for X550T devices. Due to reported interoper
ix(4): Add control of 2.5/5G autonegotiation speeds
This change enables the user to control 2.5G and 5G autonegotiation speeds via advertise_speed sysctl for X550T devices. Due to reported interoperability issues with switches, 2.5G and 5G speeds will not be advertised by default.
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com> Co-authored-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Tested by: gowtham.kumar.ks@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D26245
show more ...
|
#
a3e719bb |
| 04-Mar-2022 |
Piotr Pietruszewski <piotr.pietruszewski@intel.com> |
ixv(4): Allow PF to control the VF link state
This patch adds checks of a VF link state provided by PF via mailbox API. Such change enables the PF to disable a VF administratively.
Since command ne
ixv(4): Allow PF to control the VF link state
This patch adds checks of a VF link state provided by PF via mailbox API. Such change enables the PF to disable a VF administratively.
Since command needed by the PF to control the VF is introduced in mailbox api version 1.2, this patch also bumps supported mailbox api version to 1.2.
Co-authored-by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed By: kbowling@ Tested by: lukasz.szczepaniak@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D32004
show more ...
|
Revision tags: release/12.3.0 |
|
#
15d07799 |
| 26-Sep-2021 |
Kevin Bowling <kbowling@FreeBSD.org> |
ixgbe: whitespace cleanup pass
Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D32131
|
#
b1d5caf3 |
| 26-Sep-2021 |
Kevin Bowling <kbowling@FreeBSD.org> |
ixgbe: Rename 'struct adapter' to 'struct ixgbe_softc'
Rename the 'struct adapter' to 'struct ixgbe_softc' to avoid type ambiguity in things like kgdb.
Reviewed by: markj MFC after: 1 week Differen
ixgbe: Rename 'struct adapter' to 'struct ixgbe_softc'
Rename the 'struct adapter' to 'struct ixgbe_softc' to avoid type ambiguity in things like kgdb.
Reviewed by: markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D32131
show more ...
|
#
79b36ec9 |
| 07-Sep-2021 |
Kevin Bowling <kbowling@FreeBSD.org> |
ixgbe: Use C99 bool types
Approved by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D31621
|
#
64881da4 |
| 03-May-2021 |
Sai Rajesh Tallamraju <stallamr@netapp.com> |
ixgbe: Restore AIM support
AIM (adaptive interrupt moderation) was part of BSD11 driver. Upon IFLIB migration, AIM feature got lost. Re-introducing AIM back into IFLIB based IXGBE driver.
One cavea
ixgbe: Restore AIM support
AIM (adaptive interrupt moderation) was part of BSD11 driver. Upon IFLIB migration, AIM feature got lost. Re-introducing AIM back into IFLIB based IXGBE driver.
One caveat is that in BSD11 driver, a queue comprises both Rx and Tx ring. Starting from BSD12, Rx and Tx have their own queues and rings. Also, IRQ is now only configured for Rx side. So, when AIM is re-enabled, we should now consider only Rx stats for configuring EITR register in contrast to BSD11 where Rx and Tx stats were considered to manipulate EITR register.
Reviewed by: gallatin, markj Sponsored by: NetApp, Inc. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D27344
show more ...
|
Revision tags: release/13.0.0 |
|
#
afb1aa4e |
| 03-Mar-2021 |
Piotr Pietruszewski <piotr.pietruszewski@intel.com> |
ix(4): Report RX errors as sum of all RX error counters
HW keeps track of RX errors using several counters, each for specific type of errors. Report RX errors to OS as sum of all those counters: CRC
ix(4): Report RX errors as sum of all RX error counters
HW keeps track of RX errors using several counters, each for specific type of errors. Report RX errors to OS as sum of all those counters: CRC errors, illegal bytes, checksum, length, undersize, fragment, oversize and jabber errors.
Also, add new "rx_errs" sysctl in the dev.ix.N.mac_stats tree. This is to provide an another way to display the sum of RX errors.
Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com>
Reviewed By: erj Tested By: gowtham.kumar.ks@intel.com Sponsored By: Intel Corporation Differential Revision: https://reviews.freebsd.org/D27191
show more ...
|
Revision tags: release/12.2.0, release/11.4.0, release/12.1.0 |
|
#
668ee101 |
| 26-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352587 through r352763.
|
#
749597dc |
| 24-Sep-2019 |
Eric Joyner <erj@FreeBSD.org> |
ix, ixv: Read msix_bar from device configuration
Instead of predicting the MSI-X bar index based on the device's MAC type, read it from the device's PCI configuration instead.
PR: 239704 Submitted
ix, ixv: Read msix_bar from device configuration
Instead of predicting the MSI-X bar index based on the device's MAC type, read it from the device's PCI configuration instead.
PR: 239704 Submitted by: Piotr Pietruszewski <piotr.pietruszewski@intel.com> Reviewed by: erj@ MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21547
show more ...
|
#
a63915c2 |
| 28-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @r350386
Sponsored by: The FreeBSD Foundation
|
#
2dc2d580 |
| 23-Jul-2019 |
Eric Joyner <erj@FreeBSD.org> |
ixgbe(4): Fix enabling/disabling and reconfiguration of queues
- Wrong order of casting and bit shift caused that enabling and disabling queues didn't work properly for queues number larger than 3
ixgbe(4): Fix enabling/disabling and reconfiguration of queues
- Wrong order of casting and bit shift caused that enabling and disabling queues didn't work properly for queues number larger than 32. Use literals with right suffix instead.
- TX ring tail address was not updated during reinitiailzation of TX structures. It could block sending traffic.
- Also remove unused variables 'eims' and 'active_queues'.
Submitted by: Krzysztof Galazka <krzysztof.galazka@intel.com> Reviewed by: erj@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D20826
show more ...
|
Revision tags: release/11.3.0 |
|
#
c2c227a5 |
| 03-Feb-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343571 through r343711.
|
#
b2c1e8e6 |
| 31-Jan-2019 |
Eric Joyner <erj@FreeBSD.org> |
ix(4): Run {mod,msf,mbx,fdir,phy}_task in if_update_admin_status
From Piotr:
This patch introduces adapter->task_requests register responsible for recording requests for mod_task, msf_task, mbx_tas
ix(4): Run {mod,msf,mbx,fdir,phy}_task in if_update_admin_status
From Piotr:
This patch introduces adapter->task_requests register responsible for recording requests for mod_task, msf_task, mbx_task, fdir_task and phy_task calls. Instead of enqueueing these tasks with GROUPTASK_ENQUEUE, handlers will be called directly from ixgbe_if_update_admin_status() while holding ctx lock.
SIOCGIFXMEDIA ioctl() call reads adapter->media list. The list is deleted and rewritten in ixgbe_handle_msf() task without holding ctx lock. This change is needed to maintain data coherency when sharing adapter info via ioctl() calls.
Patch co-authored by Krzysztof Galazka <krzysztof.galazka@intel.com>.
PR: 221317 Submitted by: Piotr Pietruszewski <piotr.pietruszewski@intel.com> Reviewed by: sbruno@, IntelNetworking Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D18468
show more ...
|
Revision tags: release/12.0.0 |
|
#
7f87c040 |
| 15-Jul-2018 |
Marius Strobl <marius@FreeBSD.org> |
Assorted TSO fixes for em(4)/iflib(9) and dead code removal: - Ever since the workaround for the silicon bug of TSO4 causing MAC hangs was committed in r295133, CSUM_TSO always got disabled uncondi
Assorted TSO fixes for em(4)/iflib(9) and dead code removal: - Ever since the workaround for the silicon bug of TSO4 causing MAC hangs was committed in r295133, CSUM_TSO always got disabled unconditionally by em(4) on the first invocation of em_init_locked(). However, even with that problem fixed, it turned out that for at least e. g. 82579 not all necessary TSO workarounds are in place, still causing MAC hangs even at Gigabit speed. Thus, for stable/11, TSO usage was deliberately disabled in r323292 (r323293 for stable/10) for the EM-class by default, allowing users to turn it on if it happens to work with their particular EM MAC in a Gigabit-only environment. In head, the TSO workaround for speeds other than Gigabit was lost with the conversion to iflib(9) in r311849 (possibly along with another one or two TSO workarounds). Yet at the same time, for EM-class MACs TSO4 got enabled by default again, causing device hangs. Therefore, change the default for this hardware class back to have TSO4 off, allowing users to turn it on manually if it happens to work in their environment as we do in stable/{10,11}. An alternative would be to add a whitelist of EM-class devices where TSO4 actually is reliable with the workarounds in place, but given that the advantage of TSO at Gigabit speed is rather limited - especially with the overhead of these workarounds -, that's really not worth it. [1] This change includes the addition of an isc_capabilities to struct if_softc_ctx so iflib(9) can also handle interface capabilities that shouldn't be enabled by default which is used to handle the default-off capabilities of e1000 as suggested by shurd@ and moving their handling from em_setup_interface() to em_if_attach_pre() accordingly. - Although 82543 support TSO4 in theory, the former lem(4) didn't have support for TSO4, presumably because TSO4 is even more broken in the LEM-class of MACs than the later EM ones. Still, TSO4 for LEM-class devices was enabled as part of the conversion to iflib(9) in r311849, causing device hangs. So revert back to the pre-r311849 behavior of not supporting TSO4 for LEM-class at all, which includes not creating a TSO DMA tag in iflib(9) for devices not having IFCAP_TSO4 set. [2] - In fact, the FreeBSD TCP stack can handle a TSO size of IP_MAXPACKET (65535) rather than FREEBSD_TSO_SIZE_MAX (65518). However, the TSO DMA must have a maxsize of the maximum TSO size plus the size of a VLAN header for software VLAN tagging. The iflib(9) converted em(4), thus, first correctly sets scctx->isc_tx_tso_size_max to EM_TSO_SIZE in em_if_attach_pre(), but later on overrides it with IP_MAXPACKET in em_setup_interface() (apparently, left-over from pre-iflib(9) times). So remove the later and correct iflib(9) to correctly cap the maximum TSO size reported to the stack at IP_MAXPACKET. While at it, let iflib(9) use if_sethwtsomax*(). This change includes the addition of isc_tso_max{seg,}size DMA engine constraints for the TSO DMA tag to struct if_shared_ctx and letting iflib_txsd_alloc() automatically adjust the maxsize of that tag in case IFCAP_VLAN_MTU is supported as requested by shurd@. - Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet header length from {ixgbe,ixl,ixlv,ixv,em}_setup_interface() to iflib(9) so adjustment is automatically done in case IFCAP_VLAN_MTU is supported. As a consequence, this adjustment now is also done in case of bnxt(4) which missed it previously. - Move the reduction of the maximum TSO segment count reported to the stack by the number of m_pullup(9) calls (which in the worst case, can add another mbuf and, thus, the requirement for another DMA segment each) in the transmit path for performance reasons from em_setup_interface() to iflib_txsd_alloc() as these pull-ups are now done in iflib_parse_header() rather than in the no longer existing em_xmit(). Moreover, this optimization applies to all drivers using iflib(9) and not just em(4); all in-tree iflib(9) consumers still have enough room to handle full size TSO packets. Also, reduce the adjustment to the maximum number of m_pullup(9)'s now performed in iflib_parse_header(). - Prior to the conversion of em(4)/igb(4)/lem(4) and ixl(4) to iflib(9) in r311849 and r335338 respectively, these drivers didn't enable IFCAP_VLAN_HWFILTER by default due to VLAN events not being passed through by lagg(4). With iflib(9), IFCAP_VLAN_HWFILTER was turned on by default but also lagg(4) was fixed in that regard in r203548. So just remove the now redundant and defunct IFCAP_VLAN_HWFILTER handling in {em,ixl,ixlv}_setup_interface(). - Nuke other redundant IFCAP_* setting in {em,ixl,ixlv}_setup_interface() which is (more completely) already done in {em,ixl,ixlv}_if_attach_pre() now. - Remove some redundant/dead setting of scctx->isc_tx_csum_flags in em_if_attach_pre(). - Remove some IFCAP_* duplicated either directly or indirectly (e. g. via IFCAP_HWCSUM) in {EM,IGB,IXL}_CAPS. - Don't bother to fiddle with IFCAP_HWSTATS in ixgbe(4)/ixgbev(4) as iflib(9) adds that capability unconditionally. - Remove some unused macros from em(4). - Bump __FreeBSD_version as some of the above changes require the modules of drivers using iflib(9) to be recompiled.
Okayed by: sbruno@ at 201806 DevSummit Transport Working Group [1] Reviewed by: sbruno (earlier version), erj PR: 219428 (part of; comment #10) [1], 220997 (part of; comment #3) [2] Differential Revision: https://reviews.freebsd.org/D15720
show more ...
|
Revision tags: release/11.2.0 |
|
#
54b4b13c |
| 24-Dec-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r326936 through r327149.
|
#
c19c7afe |
| 20-Dec-2017 |
Eric Joyner <erj@FreeBSD.org> |
ixgbe(4): Convert driver to use iflib
Initial update to the ixgbe PF and VF drivers to support the iflib interface.
The PF driver version is bumped to 4.0.0, and the VF driver version is bumped to
ixgbe(4): Convert driver to use iflib
Initial update to the ixgbe PF and VF drivers to support the iflib interface.
The PF driver version is bumped to 4.0.0, and the VF driver version is bumped to 2.0.0.
Special thanks to sbruno@ for the support in helping make this conversion happen.
Submitted by: Jeb Cramer <cramerj@intel.com>, Krzysztof Galazka (Chris) <krzysztof.galazka@intel.com>, Piotr Pietruszewski <piotr.pietruszewski@intel.com> Reviewed by: sbruno@, shurd@, #IntelNetworking Tested by: Jeffrey Pieper <jeffrey.e.pieper@intel.com>, Sergey Kozlov <kozlov.sergey.404@gmail.com> Sponsored by: Limelight Networks, Intel Corporation Differential Revision: https://reviews.freebsd.org/D11727
show more ...
|
#
82725ba9 |
| 23-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r325999 through r326131.
|
#
7282444b |
| 20-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier
sys/dev: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point.
show more ...
|
Revision tags: release/10.4.0 |
|
#
531c2d7a |
| 24-Jul-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r320180
|
#
bca9d05f |
| 23-Jul-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r319973 through 321382.
|