FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.4 2021-10-03T02:03:11Z 2021-10-03T02:03:11Z Matt Macy mmacy@FreeBSD.org 2020-12-19T01:08:33Z urn:sha1:a5a91bd2a09ffe748b6dd7d5f996fe725c22c774 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) 2021-10-03T01:55:49Z Mark Johnston markj@FreeBSD.org 2021-03-08T17:39:06Z urn:sha1:3a13449e4daa28fd7be43c91017212818006ed5c This structure is shared among multiple instances of a driver, so we should ensure that it doesn't somehow get treated as if there's a separate instance per interface. This is especially important for software-only drivers like wg. DEVICE_REGISTER() still returns a void * and so the per-driver sctx structures are not yet defined with the const qualifier. Reviewed by: gallatin, erj MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D29102 (cherry picked from commit ffe3def903a5f239c319e5fe12450659658974a5) 2021-09-16T01:44:06Z Alexander Motin mav@FreeBSD.org 2021-09-02T22:11:58Z urn:sha1:1a9342cfb036b22fad93759c6093139ead6ecddb Before this change driver reported IFCAP_WOL_MAGIC enabled, but not supported. It caused errors on some SIOCSIFCAP calls. Instead report the support if hardware supports WOL, and enabled status if it has such filter installed on boot. Also bnxt_wol_config() should check WOL status in if_getcapenable(), not in if_getcapabilities() to get current one. MFC after: 2 weeks Sponsored by: iXsystems, Inc. (cherry picked from commit 8c14d7da5b9be78f71b1aa803e93ae7de973dd42) 2020-09-22T21:43:43Z Vincenzo Maffione vmaffione@FreeBSD.org 2020-09-22T21:43:43Z urn:sha1:b03f8f9615d3eb916718042b896d70f1de7a5687 iflib: leave only 1 receive descriptor unused The pidx argument of isc_rxd_flush() indicates which is the last valid receive descriptor to be used by the NIC. However, current code has multiple issues: - Intel drivers write pidx to their RDT register, which means that NICs will only use the descriptors up to pidx-1 (modulo ring size N), and won't actually use the one pointed by pidx. This does not break reception, but it is anyway confusing and suboptimal (the NIC will actually see only N-2 descriptors as available, rather than N-1). Other drivers (if_vmx, if_bnxt, if_mgb) adhere to this semantic. - The semantic used by Intel (RDT is one descriptor past the last valid one) is used by most (if not all) NICs, and it is also used on the TX side (also in iflib). Since iflib is not currently using this semantic for RX, it must decrement fl->ifl_pidx (modulo N) before calling isc_rxd_flush(), and then the per-driver callback implementation must increment the index again (to match the real semantic). This is confusing and suboptimal. - The iflib refill function is also called at initialization. However, in case the ring size is smaller than 128 (e.g. if_mgb), the refill function will actually prepare all the receive descriptors (N), without leaving one unused, as most of NICs assume (e.g. to avoid RDT to overrun RDH). I can speculate that the code looks like this right now because this issue showed up during testing (e.g. with if_mgb), and it was easy to workaround by decrementing pidx before isc_rxd_flush(). The goal of this change is to simplify the code (removing a bunch of instructions from the RX fast path), and to make the semantic of isc_rxd_flush() consistent across drivers. To achieve this, we: - change the semantics of the pidx argument to the usual one (that is the index one past the last valid one), so that both iflib and drivers avoid the decrement/increment dance. - fix the initialization code to prepare at most N-1 descriptors. Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D26191 2020-06-03T18:09:31Z Kristof Provost kp@FreeBSD.org 2020-06-03T18:09:31Z urn:sha1:2e5ee8d543101e34f7647790de8d76b38f22c177 bnxt: isc_nrxd_max and isc_ntxd_max must be powers of two 2020-03-16T23:20:56Z Brooks Davis brooks@FreeBSD.org 2020-03-16T23:20:56Z urn:sha1:b86bd63a3e8ea69224c663279111a249b3fdac61 bnxt(4): Fix ioctls when user addresses are inaccessable. Check copyin's error code (differ adding copyout checks at this time). Don't directly access user memory in the switch statement. Since bnxt_ioctl_data isn't all that big, use a stack allocation. Reviewed by: jhb Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D23933 2018-07-15T19:04:23Z Marius Strobl marius@FreeBSD.org 2018-07-15T19:04:23Z urn:sha1:7f87c0406df8e22d6a76b2d1245043619b40e983 - 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 2018-05-19T05:57:26Z Matt Macy mmacy@FreeBSD.org 2018-05-19T05:57:26Z urn:sha1:24a7d6d3a6ac1bc35adeac8233ecf59afe1728bf 2018-05-18T13:49:12Z Sean Bruno sbruno@FreeBSD.org 2018-05-18T13:49:12Z urn:sha1:f097a19eabbf84af430a3d804b0b7ce1e7403532 - Fix HWRM warning message during HW LRO configuration. Submitted by: bhargava.marreddy@broadcom.com MFC after: 1 week Sponsored by: Broadcom Limited Differential Revision: https://reviews.freebsd.org/D15466 2018-04-11T15:15:34Z Mark Johnston markj@FreeBSD.org 2018-04-11T15:15:34Z urn:sha1:fbf8b74c1096a04fe6a936a829f622cd22dc3bff Reviewed by: sbruno MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D15041