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 Approved by: re (gjb) Sponsored By: Intel Corporation Differential Revision: https://reviews.freebsd.org/D27191 (cherry picked from commit afb1aa4e6df245d38fd2ba683fa521d5dabe8392) (cherry picked from commit 8fa11f89225695c185a8a92c7530e270e77552f8)
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
Coverity flagged this condition: The condition
offset == 0 && offset == 65535
can never be true because offset cannot be equal
to two different values at the same time.
Submitted by: bret_ketchum@dell.com
Reported by: Coverity
Reviewed by: tsoome, cem
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D26144
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 <erj@freebsd.org> 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
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.
All of these uses of sizeof() were on the wrong type in relation to the pointer passed to SYSCTL_ADD_PROC as arg1. Fortunately, none of the handlers actually use arg2. So just don't pass a (non-zero) arg2. Reported by: Coverity CID: 1007701
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
From Jake: Notify the iflib stack of whether we received any pause frames during the timer window. This allows the stack to avoid reporting a Tx hang due to the device being paused. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Submitted by: Jacob Keller <jacob.e.keller@intel.com> Reviewed by: gallatin@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21869
From Zach: Intel documentation indicates that backplane X550EM_X KR devices do not support Energy Efficient Ethernet. Prior to this patch, X552 devices (device ID 0x15AB) will crash the system when transitioning EEE state via sysctl. Signed-off-by: Zach Vargas <zvargas@xes-inc.com> PR: 240320 Submitted by: Zach Vargas <zvargas@xes-inc.com> Reviewed by: erj@ MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D21673
Reviewed by: erj