src/sys/dev/ice, branch release/12.3.0

iflib: ensure that tx interrupts enabled and cleanups

2021-10-03T02:03:11Z

Doing a 'dd' over iscsi will reliably cause stalls. Tx cleaning _should_ reliably happen as data is sent. However, currently if the transmit queue fills it will wait until the iflib timer (hz/2) runs. This change causes the the tx taskq thread to be run if there are completed descriptors. While here: - make timer interrupt delay a sysctl - simplify txd_db_check handling - comment on INTR types Background on the change: Initially doorbell updates were minimized by only writing to the register on every fourth packet. If txq_drain would return without writing to the doorbell it scheduled a callout on the next tick to do the doorbell write to ensure that the write otherwise happened "soon". At that time a sysctl was added for users to avoid the potential added latency by simply writing to the doorbell register on every packet. This worked perfectly well for e1000 and ixgbe ... and appeared to work well on ixl. However, as it turned out there was a race to this approach that would lockup the ixl MAC. It was possible for a lower producer index to be written after a higher one. On e1000 and ixgbe this was harmless - on ixl it was fatal. My initial response was to add a lock around doorbell writes - fixing the problem but adding an unacceptable amount of lock contention. The next iteration was to use transmit interrupts to drive delayed doorbell writes. If there were no packets in the queue all doorbell writes would be immediate as the queue started to fill up we could delay doorbell writes further and further. At the start of drain if we've cleaned any packets we know we've moved the state machine along and we write the doorbell (an obvious missing optimization was to skip that doorbell write if db_pending is zero). This change required that tx interrupts be scheduled periodically as opposed to just when the hardware txq was full. However, that just leads to our next problem. Initially dedicated msix vectors were used for both tx and rx. However, it was often possible to use up all available vectors before we set up all the queues we wanted. By having rx and tx share a vector for a given queue we could halve the number of vectors used by a given configuration. The problem here is that with this change only e1000 passed the necessary value to have the fast interrupt drive tx when appropriate. Reported by: mav@ Tested by: mav@ Reviewed by: gallatin@ MFC after: 1 month Sponsored by: iXsystems Differential Revision: https://reviews.freebsd.org/D27683 (cherry picked from commit 81be655266fac2b333e25f386f32c9bcd17f523d)

ice(4): Update to version 0.28.1-k

2021-09-20T22:09:29Z

This updates the driver to align with the version included in the "Intel Ethernet Adapter Complete Driver Pack", version 25.6. There are no major functional changes; this mostly contains bug fixes and changes to prepare for new features. This version of the driver uses the previously committed ice_ddp package 1.3.19.0. Signed-off-by: Eric Joyner Tested by: jeffrey.e.pieper@intel.com Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D28640 (cherry picked from commit d08b8680e12ad692736c84238dcf45c70c228914)

MFC r368745:

2020-12-19T04:24:05Z

ice: quiet -Wredundant-decls Reapply r364240 after driver update in r365617. Reviewed by: lwhsu Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D27561

ice: MFC commits for update to 0.26.16

2020-09-14T21:33:11Z

These include r365332, r365550, and r365617, which update both the ice_ddp package and the ice(4) driver itself. Relnotes: yes Sponsored by: Intel Corporation

MFC r361541, r362038, r364240

2020-09-10T20:46:16Z

These MFCs add the ice(4) driver to the kernel for Intel 800 Series Ethernet adapters, a couple fixes for the ice_ddp module makefile, and remove some redeclarations, respectively. Relnotes: yes Sponsored by: Intel Corporation