src-test/sys/dev/ixgbe/if_ixv.c, branch main

em/ix/ixv/ixl/iavf: Implement ifdi_needs_restart iflib method

2020-05-11T17:42:04Z

Pursuant to r360398, implement driver-specific versions of the ifdi_needs_restart iflib device method. Some (if not most?) Intel network cards don't need reinitializing when a VLAN is added or removed from the device hardware, so these implement ifdi_needs_restart in a way that tell iflib not to bring the interface up or down when a VLAN is added or removed, regardless of whether the VLAN_HWFILTER interface capability flag is set or not. This could potentially solve several PRs relating to link flaps that occur when VLANs are added/removed to devices. Signed-off-by: Eric Joyner PR: 240818, 241785 Reviewed by: gallatin@, olivier@ MFC after: 3 days MFC with: r360398 Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D24659

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (15 of many)

2020-02-24T10:51:26Z

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags.

if_ixv: disable RSS configuration on 82599 and X540 VFs

2019-11-05T06:34:20Z

It is reported that those VFs share their RSS configuration with PF and, thus, they cannot be configured independently. Also: - add missing opt_rss.h to if_ixv.c, otherwise RSS kernel option could not be seen - do not enable IXGBE_FEATURE_RSS on the older VFs - set flowid / hash type to M_HASHTYPE_NONE or M_HASHTYPE_OPAQUE_HASH (based on what the hardware reports) if IXGBE_FEATURE_RSS is not set Reviewed by: nobody MFC after: 4 weeks Sponsored by: Panzura Differential Revision: https://reviews.freebsd.org/D21705

ix, ixv: Read msix_bar from device configuration

2019-09-24T17:06:32Z

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 Reviewed by: erj@ MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21547

ixgbe(4): Fix enabling/disabling and reconfiguration of queues

2019-07-23T18:14:32Z

- 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 Reviewed by: erj@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D20826

ixv(4): Add missing IFLIB_IS_VF flag in iflib shared ctx

2019-03-19T18:07:44Z

From Krzysztof: The driver built as KLD cannot be unloaded, if this flag is not set. Submitted by: Krzysztof Galazka Reviewed by: shurd@, erj@ MFC after: 1 week Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D19402

iflib: expose the Rx mbuf buffer size to drivers

2019-03-19T17:59:56Z

From Jake: iflib_fl_setup calculates a suitable buffer size for the Rx mbufs based on the isc_max_frame_size value that drivers setup. This calculation is repeated by drivers when programming their hardware with the size of each Rx buffer. This can lead to a mismatch where the iflib mbuf size is different from the expected size of the buffer as programmed by the hardware. This can lead to unexpected results. If iflib ever wants to support mbuf sizes larger than one page, every driver must be updated to account for the new possible buffer sizes. Fix this by calculating the mbuf size prior to calling IFDI_INIT, and adding the iflib_get_rx_mbuf_sz function which will expose this value to drivers, so that they do not repeat the same calculation. Submitted by: Jacob Keller Reviewed by: shurd@, erj@ MFC after: 1 week Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D19489

ix(4),ixv(4): Fix TSO offloads when TXCSUM is disabled

2019-01-31T21:53:03Z

This patch and commit message are based on r340256 created by Jacob Keller: The iflib stack does not disable TSO automatically when TXCSUM is disabled, instead assuming that the driver will correctly handle TSOs even when CSUM_IP is not set. This results in iflib calling ixgbe_isc_txd_encap with packets which have CSUM_IP_TSO, but do not have CSUM_IP or CSUM_IP_TCP set. Because of this, ixgbe_tx_ctx_setup will not setup the IPv4 checksum offloading. This results in bad TSO packets being sent if a user disables TXCSUM without disabling TSO. Fix this by updating the ixgbe_tx_ctx_setup function to check both CSUM_IP and CSUM_IP_TSO when deciding whether to enable checksums. Once this is corrected, another issue for TSO packets is revealed. The driver sets IFLIB_NEED_ZERO_CSUM in order to enable a work around that causes the ip->sum field to be zero'd. This is necessary for ix hardware to correctly perform TSOs. However, if TXCSUM is disabled, then the work around is not enabled, as CSUM_IP will not be set when the iflib stack checks to see if it should clear the sum field. Fix this by adding IFLIB_TSO_INIT_IP to the iflib flags for the ix and ixv interface files. Once both of these changes are made, the ix and ixv drivers should correctly offload TSO packets when TSO offload is enabled, regardless of whether TXCSUM is enabled or disabled. Submitted by: Piotr Pietruszewski Reviewed by: IntelNetworking Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D18470

Make iflib a loadable module.

2019-01-31T19:05:56Z

iflib is already a module, but it is unconditionally compiled into the kernel. There are drivers which do not need iflib(4), and there are situations where somebody might not want iflib in kernel because of using the corresponding driver as module. Reviewed by: marius Discussed with: erj Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D19041

- Stop iflib(4) from leaking MSI messages on detachment by calling

2019-01-30T13:21:26Z

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