Commit Graph

218 Commits

Author SHA1 Message Date
George V. Neville-Neil
927dd68e04 Add support for latest Intel I219 device, supported in Lenovo Carbon X1 v7
MFC after:	2 weeks
2020-01-20 12:53:02 +00:00
Eric Joyner
e81998f407 net: prefer ETHER_ADDR_LEN over ETH_ADDR_LEN
A couple of drivers and one place in if.c use ETH_ADDR_LEN, even though
net/ethernet.h provides an equivalent ETHER_ADDR_LEN definition.

Cleanup all of the locations which refer to ETH_ADDR_LEN to use the
standard ETHER_ADDR_LEN instead.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	erj@, jpaetzel@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D21239
2019-11-04 22:57:36 +00:00
Gleb Smirnoff
c42980268b Convert to if_foreach_llmaddr() KPI. 2019-10-21 18:11:24 +00:00
Marius Strobl
cd1cf2fc1d - In em_intr(), just call em_handle_link() instead of duplicating it.
- In em_msix_link(), properly handle IGB-class devices after the iflib(4)
  conversion again by only setting EM_MSIX_LINK for the EM-class 82574
  and by re-arming link interrupts unconditionally, i. e. not only in
  case of spurious interrupts. This fixes the interface link state change
  detection for the IGB-class. [1]
- In em_if_update_admin_status(), only re-arm the link state change
  interrupt for 82574 and also only if such a device uses MSI-X, i. e.
  takes advantage of autoclearing. In case of INTx and MSI as well as
  for LEM- and IGB-class devices, re-arming isn't appropriate here and
  setting EM_MSIX_LINK isn't either.
  While at it, consistently take advantage of the hw variable.

PR:	236724 [1]
Differential Revision:	https://reviews.freebsd.org/D21924
2019-10-20 17:40:50 +00:00
Eric Joyner
ea0e3f4db5 e1000: correctly set isc_pause_frames only when XOFF increases
From Jake:
The e1000 driver sets the iflib shared context isc_pause_frames value to
the number of received xoff frames. This is done so that the iflib
watchdog timer won't trigger a Tx Hang due to pause frames.

Unfortunately, the function simply sets it to the value of the xoffrxc
counter. Once the device has received a single XOFF packet, the driver
always reports that we received pause frames. This will prevent the Tx
hang detection entirely from that point on.

Fix this by assigning isc_pause_frames to a non-zero value if we
received any XOFF packets in the last timer interval.

We could attempt to calculate the total number of received packets by
doing a subtraction, but the iflib stack only seems to check if
isc_pause_frames is non-zero.

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/D21868
2019-10-16 17:13:46 +00:00
Marius Strobl
ca2ebb27ed o Avoid determining the MAC class (LEM/EM or IGB) - possibly even multiple
times - on every interrupt by using an own set of device methods for the
  IGB class. This translates to introducing igb_if_intr_{disable,enable}()
  and igb_if_{rx,tx}_queue_intr_enable() with that IGB-specific code moved
  out of their EM counterparts and otherwise continuing to use the EM IFDI
  methods also for IGB.
  Note that igb_if_intr_{disable,enable}() also issue E1000_WRITE_FLUSH as
  lost with the conversion of igb(4) to iflib(4).
  Also note, that the em_if_{disable,enable}_intr() methods are renamed to
  em_if_intr_{disable,enable}() for consistency with the names used in the
  interface declaration.
o In em_intr():
  - Don't bother to bail out if the interrupt type is "legacy", i. e. INTx
    or MSI, as iflib(4) doesn't use ift_legacy_intr methods for MSI-X. All
    other iflib(4)-based drivers avoid this check, too.
  - Given that only the MSI-X interrupts have one-shot behavior (by taking
    advantage of the EIAC register), explicitly disable interrupts. Hence,
    em_intr() now matches what {em,igb}_irq_fast() previously did (in case
    of igb(4) supposedly also to work around MSI message reordering errata
    on certain systems).
o In em_if_intr_disable():
  - Clear the EIAC register unconditionally for 82574 and not just in case
    of MSI-X, matching em_if_intr_enable() and bringing back the last hunk
    of r206437 lost with the iflib(4) conversion.
  - Write to EM_EIAC for clearing said register instead of to the IGB-only
    E1000_EIAC used ever since the iflib(4) conversion.

Reviewed by:	shurd
Differential Revision:	https://reviews.freebsd.org/D20176
2019-05-07 08:31:54 +00:00
Eric Joyner
1b9d93948a iflib: expose the Rx mbuf buffer size to drivers
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 <jacob.e.keller@intel.com>
Reviewed by:	shurd@, erj@
MFC after:	1 week
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D19489
2019-03-19 17:59:56 +00:00
Eric Joyner
bc408c7d61 Remove references to CONTIGMALLOC_WORKS in iflib and em
From Jake:
"The iflib_fl_setup() function tries to pick various buffer sizes based
on the max_frame_size value defined by the parent driver. However, this
code was wrapped under CONTIGMALLOC_WORKS, which was never actually
defined anywhere.

This same code pattern was used in if_em.c, likely trying to match
what iflib uses.

Since CONTIGMALLOC_WORKS is not defined, remove this dead code from
iflib_fl_setup and if_em.c

Given that various iflib drivers appear to be using a similar
calculation, it might be worth making this buffer size a value that the
driver can peek at in the future."

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	shurd@
MFC after:	1 week
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D19199
2019-03-05 19:12:51 +00:00
Marius Strobl
6143b97764 - Remove the redundant device disabled hint handling; ever since
r241119 that's performed globally by device_attach(9).
- As for the EM-class of devices, em(4) supports multiple queues
  and MSI-X respectively only with 82574 devices. However, since
  the conversion to iflib(4), em(4) relies on the interrupt type
  fallback mechanism, i. e. MSI-X -> MSI -> INTx, of iflib(4) to
  figure out the interrupt type to use for the EM-class (as well
  as the IGB-class) of MACs. Moreover, despite the datasheet for
  82583V not mentioning any support of MSI-X, there actually are
  82583V devices out there that report a varying number of MSI-X
  messages as supported. The interrupt type fallback of iflib(4)
  is causing two failure modes depending on the actual number of
  MSI-X messages supported for such instances of 82583V:
  1) With only one MSI-X message supported, none is left for the
     RX/TX queues as that one message gets assigned to the admin
     interrupt. Worse, later on - which will be addressed with a
     separate fix - iflib(4) interprets that one messages as MSI
     or INTx to be set up, but fails to actually do so as it has
     previously called pci_alloc_msix(9). [1, 2]
  2) With more message supported, their distribution is okay but
     then em_if_msix_intr_assign() doesn't work for 82583V, with
     the interface being left in a non-working state, too. [3]
  Thus, let em_if_attach_pre() indicate to iflib(4) to try MSI-X
  with 82574 only, and at most MSI for the remainder of EM-class
  devices.
  While at it, remove "try_second_bar" as it's polarity inverted
  and not actually needed.
- Remove code from em_if_timer() that effectively is a NOP since
  the conversion to iflib(4) ("trigger" is no longer read).
  While at it, let the comment for em_if_timer() reflect reality
  after said conversion.
- Implement an ifdi_watchdog_reset method which only updates the
  em(4) "watchdog_events" counter but doesn't perform any reset,
  so that the em(4) "watchdog_timeouts" SYSCTL (iflib(4) doesn't
  provide a counterpart) reflects reality and these timeouts add
  to IFCOUNTER_OERRORS again after the iflib(4) conversion.
- Remove the "mbuf_defrag_fail" and "tx_dma_fail" SYSCTLS; since
  the iflib(4) conversion, associated counters are disconnected,
  but iflib(4) provides "mbuf_defrag_failed" and "tx_map_failed"
  respectively as equivalents.
- Move the description preceding lem_smartspeed() to the correct
  spot before em_reset() and bring back appropriate comments for
  {igb,em}_initialize_rss_mapping() and lem_smartspeed() lost in
  the iflib(4) conversion.
- Adapt some other function descriptions and INIT_DEBUGOUT() use
  to match reality after the iflib(4) conversion.
- Put the debugging message of em_enable_vectors_82574() (missed
  in r343578) under bootverbose, too.

PR:		219428 [1], 235246 [2], 235147 [3]
Reviewed by:	erj (previous version)
Differential Revision:	https://reviews.freebsd.org/D19108
2019-02-09 11:58:40 +00:00
Patrick Kelsey
d533db848c Fix em(4) interrupt routing
When configured with more tx queues than rx queues,
em_if_msix_intr_assign() was incorrectly routing the tx event
interrupts.

Reviewed by:	erj, marius
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D19070
2019-02-08 20:34:47 +00:00
Marius Strobl
b97de13ae0 - Stop iflib(4) from leaking MSI messages on detachment by calling
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
2019-01-30 13:21:26 +00:00
Eric Joyner
088a0b27ad intel iflib drivers: correct initialization of tx_cidx_processed
From Jake:

In r341156 ("Fix first-packet completion", 2018-11-28) a hack to work
around a delta calculation determining how many descriptors were used
was added to ixl_isc_tx_credits_update_dwb.

The same fix was also applied to the em and igb drivers in r340310, and
to ix in r341156.

The hack checked the case where prev and cur were equal, and then added
one. This works, because by the time we do the delta check, we already
know there is at least one packet available, so the delta should be at
least one.

However, it's not a complete fix, and as indicated by the comment is
really a hack to work around the real bug.

The real problem is that the first time that we transmit a packet,
tx_cidx_processed will be set to point to the start of the ring.
Ultimately, the credits_update function expects it to point to the
*last* descriptor that was processed. Since we haven't yet processed any
descriptors, pointing it to 0 results in this incorrect calculation.

Fix the initialization code to have it point to the end of the ring
instead. One way to think about this, is that we are setting the value
to be one prior to the first available descriptor.

Doing so, corrects the delta calculation in all cases. The original fix
only works if the first packet has exactly one descriptor. Otherwise, we
will report 1 less than the correct value.

As part of this fix, also update the MPASS assertions to match the real
expectations. First, ensure that prev is not equal to cur, since this
should never happen. Second, remove the assertion about prev==0 || delta
!= 0. It looks like that originated from when the em driver was
converted to iflib. It seems like it was supposed to ensure that delta
was non-zero. However, because we originally returned 0 delta for the
first calculation, the "prev == 0" was tacked on.

Instead, replace this with a check that delta is greater than zero,
after the correction necessary when the ring pointers wrap around.

This new solution should fix the same bug as r341156 did, but in a more
robust way.

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	shurd@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D18545
2019-01-24 01:03:00 +00:00
Eric van Gyzen
382000a1fd em/igb: Do not print link state messages
These messages are totally redundant with the iflib messages.
They're also not very useful, since they don't include the
interface name.

Discussed with:	shurd
Approved by:	re (rgrimes)
Sponsored by:	Dell EMC Isilon
2018-10-08 01:28:46 +00:00
Stephen Hurd
861437f83a Add IFCAP_TSO6 for igb
It seems igb supports TSO6, but the capability got lost in
the iflib update. Restore this capability.

PR:		231476
Reported by:	lev
Reviewed by:	erj
Approved by:	re (gjb)
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D17242
2018-09-20 20:06:44 +00:00
Marius Strobl
73ed47f04f Remove the duplicated CSUM_IP6_TCP introduced in r311849 from the TX
checksum capabilities of IGB-class MACs. While at it, fix the line
wrapping.

PR:	230571
2018-08-13 20:29:39 +00:00
Marius Strobl
9820d94555 o In em_if_update_admin_status():
- Don't bother calling if_setbaudrate(9) as iflib_link_state_change(9)
    takes care of that,
  - correctly check for E1000_CTRL_EXT_LINK_MODE_GMII in E1000_CTRL_EXT [1],
  - properly convert the uint16_t link_speed to a uint64_t baudrate by
    using IF_Mbps() which contains an appropriate cast [2],
  - remove the duplicate link down announcement when bootverbose isn't
    zero and bring the remaining one in line with the other link state
    messages.
o Remove a dead store to rid in em_if_msix_intr_assign(). [3]
o Or in the DMA coalescing Rx threshold so the other bits set in E1000_DMACR
  remain intact as intended in igb_init_dmac(). [4]

Reported by:	Coverity
CID:		1378464 [1], 1368765 [2], 1381681 [3], 1304929 [4]
2018-07-22 17:40:13 +00:00
Marius Strobl
c1176e63e8 Update igb_sctx_init for r336313, missed when incorporating shurd@'s
feedback on the initial D15720.

Reported by:	kib
2018-07-16 19:47:57 +00:00
Marius Strobl
7f87c0406d 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
2018-07-15 19:04:23 +00:00
Matt Macy
d5210708dd Sleep rather than spin in e1000 when doing long running config operations.
With r333218 it is now possible for drivers to use an sx lock and thus sleep while
waiting on long running operations rather than DELAY().

Reported by:	gallatin
Reviewed by:	sbruno
Approved by:	sbruno
MFC after:	1 month
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D14984
2018-05-08 01:39:45 +00:00
Stephen Hurd
7021bf0569 Update copyright per Matthew Macy
"Under my tutelage Nicole did 85% of the work. At the time it seemed
simplest for a number of reasons to put my copyright on it. I now consider
that to have been a mistake."

Submitted by:	Matthew Macy <mmacy@mattmacy.io>
Reviewed by:	shurd
Approved by:	shurd
Differential Revision:	https://reviews.freebsd.org/D14766
2018-03-21 15:57:36 +00:00
Pedro F. Giffuni
ac2fffa4b7 Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).

The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation size attributes which put extra pressure
on the compiler.

Given that most of these checks are superfluous we have to choose better
where to use mallocarray(9). We still have more uses of mallocarray(9) but
hopefully this is enough to bring swap usage to a reasonable level.

Reported by:	wosch
PR:		225197
2018-01-21 15:42:36 +00:00
Eric Joyner
1b65356b43 e1000: Fix typos in value written to register and a comment
The value written to E1000_TARC(0) wasn't intended to have every bit but
E1000_TARC0_CB_MULTIQ_3_REQ cleared; a ~ was missing.

Also change the referenced spec update section in the comment to the correct
section.

Sponsored by:	Intel Corporation
2018-01-11 19:24:51 +00:00
Pedro F. Giffuni
efaa3e0789 dev/(e1000,ixl): Make some use of mallocarray(9).
Reviewed by:	erj
Differential Revision: https://reviews.freebsd.org/D13833
2018-01-11 15:25:26 +00:00
Sean Bruno
6fe4c0a063 e1000: Add support for Ice Lake and Cannon Lake
Ths add initial support for Ice Lake and Cannon Lake ethernet devices.

This also addressed errata 1.5.4.4 for Sky Lake and Kabby Lake devices:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/i218-i219-ethernet-connection-spec-update.pdf?asset=9561

Submitted by:	Kevin Bowling <kevin.bowling@kev009.com>
Relnotes:	Yes
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D13660
2017-12-28 21:26:40 +00:00
Stephen Hurd
96fc97c81f Update Matthew Macy contact info
Email address has changed, uses consistent name (Matthew, not Matt)

Reported by:	Matthew Macy <mmacy@mattmacy.io>
Differential Revision:	https://reviews.freebsd.org/D13537
2017-12-19 17:59:00 +00:00
Pedro F. Giffuni
7282444b10 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.
2017-11-20 19:36:21 +00:00
Stephen Hurd
1c0054d261 Fix "taskqgroup_attach: setaffinity failed: 3" with iflib drivers
Improved logging added in r323879 exposed an error during
attach. We need the irq, not the rid to work correctly. em uses
shared irqs, so it will use the same irq for TX as RX. bnxt does
not use shared irqs, or TX irqs at all, so there's no need to set
the TX irq affinity.

Reviewed by:	sbruno
Approved by:	sbruno (mentor)
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D12496
2017-10-05 14:43:30 +00:00
Conrad Meyer
916616c4c5 Add PNP metadata to more drivers
GPUs: radeonkms, i915kms
NICs: if_em, if_igb, if_bnxt

This metadata isn't used yet, but it will be handy to have later to
implement automatic module loading.

Reviewed by:	imp, mmacy
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D12488
2017-09-26 23:23:58 +00:00
Stephen Hurd
c5cf217261 Some small packet performance improvements
If the packet is smaller than MTU, disable the TSO flags.
Move TCP header parsing inside the IS_TSO?() test.
Add a new IFLIB_NEED_ZERO_CSUM flag to indicate the checksums need to be zeroed before TX.

Reviewed by:	sbruno
Approved by:	sbruno (mentor)
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D12442
2017-09-23 01:33:20 +00:00
Stephen Hurd
ab2e3f7958 Revert r323516 (iflib rollup)
This was really too big of a commit even if everything worked, but there
are multiple new issues introduced in the one huge commit, so it's not
worth keeping this until it's fixed.

I'll work on splitting this up into logical chunks and introduce them one
at a time over the next week or two.

Approved by:	sbruno (mentor)
Sponsored by:	Limelight Networks
2017-09-16 02:41:38 +00:00
Stephen Hurd
d300df0182 Roll up iflib commits from github. This pulls in most of the work done
by Matt Macy as well as other changes which he has accepted via pull
request to his github repo at https://github.com/mattmacy/networking/

This should bring -CURRENT and the github repo into close enough sync to
allow small feature branches rather than a large chain of interdependant
patches being developed out of tree.  The reset of the synchronization
should be able to be completed on github by splitting the remaining
changes that are not yet ready into short feature branches for later
review as smaller commits.

Here is a summary of changes included in this patch:

1)  More checks when INVARIANTS are enabled for eariler problem
    detection
2)  Group Task Queue cleanups
    - Fix use of duplicate shortdesc for gtaskqueue malloc type.
      Some interfaces such as memguard(9) use the short description to
      identify malloc types, so duplicates should be avoided.
3)  Allow gtaskqueues to use ithreads in addition to taskqueues
    - In some cases, this can improve performance
4)  Better logging when taskqgroup_attach*() fails to set interrupt
    affinity.
5)  Do not start gtaskqueues until they're needed
6)  Have mp_ring enqueue function enter the ABDICATED rather than BUSY
    state.  This moves the TX to the gtaskq and allows processing to
    continue faster as well as make TX batching more likely.
7)  Add an ift_txd_errata function to struct if_txrx.  This allows
    drivers to inspect/modify mbufs before transmission.
8)  Add a new IFLIB_NEED_ZERO_CSUM for drivers to indicate they need
    checksums zeroed for checksum offload to work.  This avoids modifying
    packet data in the TX path when possible.
9)  Use ithreads for iflib I/O instead of taskqueues
10) Clean up ioctl and support async ioctl functions
11) Prefetch two cachlines from each mbuf instead of one up to 128B.  We
    often need to parse packet header info beyond 64B.
12) Fix potential memory corruption due to fence post error in
    bit_nclear() usage.
13) Improved hang detection and handling
14) If the packet is smaller than MTU, disable the TSO flags.
    This avoids extra packet parsing when not needed.
15) Move TCP header parsing inside the IS_TSO?() test.
    This avoids extra packet parsing when not needed.
16) Pass chains of mbufs that are not consumed by lro to if_input()
    rather call if_input() for each mbuf.
17) Re-arrange packet header loads to get as much work as possible done
    before a cache stall.
18) Lock the context when calling IFDI_ATTACH_PRE()/IFDI_ATTACH_POST()/
    IFDI_DETACH();
19) Attempt to distribute RX/TX tasks across cores more sensibly,
    especially when RX and TX share an interrupt.  RX will attempt to
    take the first threads on a core, and TX will attempt to take
    successive threads.
20) Allow iflib_softirq_alloc_generic() to request affinity to the same
    cpus an interrupt has affinity with.  This allows TX queues to
    ensure they are serviced by the socket the device is on.
21) Add new iflib sysctls to net.iflib:
    - timer_int - interval at which to run per-queue timers in ticks
    - force_busdma
22) Add new per-device iflib sysctls to dev.X.Y.iflib
    - rx_budget allows tuning the batch size on the RX path
    - watchdog_events Count of watchdog events seen since load
23) Fix error where netmap_rxq_init() could get called before
    IFDI_INIT()
24) e1000: Fixed version of r323008: post-cold sleep instead of DELAY
    when waiting for firmware
    - After interrupts are enabled, convert all waits to sleeps
    - Eliminates e1000 software/firmware synchronization busy waits after
      startup
25) e1000: Remove special case for budget=1 in em_txrx.c
    - Premature optimization which may actually be incorrect with
      multi-segment packets
26) e1000: Split out TX interrupt rather than share an interrupt for
    RX and TX.
    - Allows better performance by keeping RX and TX paths separate
27) e1000: Separate igb from em code where suitable
    Much easier to understand separate functions and "if (is_igb)" than
    previous tests like "if (reg_icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))"

#blamebruno

Reviewed by:	sbruno
Approved by:	sbruno (mentor)
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D12235
2017-09-13 01:18:42 +00:00
Konstantin Belousov
dc63dc00cb Fix malloc() uses in em_get_regs().
Do not use malloc(M_NOWAIT), wait is possible there, and the malloc
failures where not checked.  Do not forget to free malloced memory.

Reported and tested by:	pho
Approved by:	sbruno
Sponsored by:	The FreeBSD Foundation
2017-09-08 14:54:07 +00:00
Sean Bruno
a969350226 Revert r323008 and its conversion of e1000/iflib to using SX locks.
This seems to be missing something on the 82574L causing NFS root mounts
to hang.

Reported by:	kib
2017-08-30 18:56:24 +00:00
Sean Bruno
e17e5b4134 Continuation of lock cleanup in e1000.
Post-cold sleep instead of DELAY when waiting for firmware.

Convert softc mutex to an SX lock.  Change all waits to sleeps
once interrupts are enabled (and it is safe to sleep).

Submitted by:	Matt Macy <matt@mattmacy.io>
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D12101
2017-08-30 00:20:43 +00:00
Marius Strobl
e023501c6a Don't set any WOL enabling hardware bits if WOL isn't requested
according to the enabled interface capability bits. Also remove
some dead code, which tried to preserve already set contents of
E1000_WUC while that register is completely overwritten shortly
after in all cases.
2017-08-28 22:09:12 +00:00
Sean Bruno
7d0d648446 Add a different #define for the maximum number of transmit and
recieve descriptors for the igb(4) class of devices.  This will
allow a better definition for maximum going forward.  Some igb(4)
devices support more than the default 4K.

Reported by:	Jason (j@nitrology.com)
Sponsored by:	Limelight Networks
2017-08-25 22:38:55 +00:00
Sean Bruno
5eedcb0969 Do not update stats counter in SWI context. Defer to the already existing
admin thread.

Submitted by:	Matt Macy <mmacy@mattmacy.io>
Sponsored by:	Limelight Networks
2017-07-21 17:42:54 +00:00
Enji Cooper
2df7231dbf Some trivial style(9) fixes
- Delete trailing whitespace.
- Fix leading indentation (convert single column spaces to tabs).
- Convert "[Ff]all through" to "FALLTHROUGH", per implicit project
  style/spelling.

Reviewed by:	sbruno
Differential Revision:	D11665
2017-07-20 04:32:06 +00:00
Sean Bruno
d8c2808fcf Restore igb(4) code dropped during iflib conversion
- restore newer code for vf, i350, i210, i211
 - restore dmac init code for i354 and i350
 - restore WUC/WUFC update
 - check for igb mac type before attempting trying to assert
   a media changed event.
 - handle link events for igb(4) and em(4) devices differently
   and appropriately for their respective model types.

Submitted by:	Matt Macy <mmacy@mattmacy.io>
Sponsored by:	Limelight Networks
2017-07-19 22:41:22 +00:00
Sean Bruno
60596476cf Move pause frame counter out of struct if_ctx and into struct if_softc_ctx_t
so that we can use it in iflib to detect pause frames.

The igb(4) driver definitely used to use this in its old timer function and
I see no reason to restrict it to that driver only.

Sponsored by:	Limelight Networks
2017-04-07 00:33:03 +00:00
Sean Bruno
fd70242dbc no_desc_avail is tracked in iflib now making this redundant.
Sponsored by:	Limelight Networks
2017-04-04 16:54:46 +00:00
Sean Bruno
548b549ade Remove unsafe and non-functional DDB functions that I added long ago
for debugging.
2017-04-03 21:19:12 +00:00
Sean Bruno
c45420ccac Remove rx_processing_limit sysctl and now orphaned function em_set_sysctl_value
Sponsored by:	Limelight Networks
2017-04-03 21:17:57 +00:00
Sean Bruno
935ca1ae7c Access *correct* ifp data structure when debug sysctl is invoked.
Submitted by:	Kevin Bowling <kevin.bowling@kev009.com>
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D10126
2017-03-27 15:08:02 +00:00
Sean Bruno
cb101e1257 Add missing 'else' to conditional. This doesn't really affect the code
flow or configuration in any way.
2017-03-24 14:27:29 +00:00
Sean Bruno
fdb25f38cb Add missing 'else' to 3-state conditional during setup of interrupts.
We don't want to overwrite the 82574 interrupt setup with a different
configuration.

PR:		218041
Submitted by:	razmyslov@viva64.com
2017-03-24 14:25:56 +00:00
Sean Bruno
b207ed2b4a Actually set the MTU to the requested value and fixup handling of jumbo
frames.

Submitted by:	Matt Macy <mmacy@nextbsd.org>
Reported by:	pho
Sponsored by:	Limelight Networks
2017-03-15 14:44:59 +00:00
Sean Bruno
95246abb21 IFLIB updates
- unconditionally enable BUS_DMA on non-x86 architectures
- speed up rxd zeroing via customized function
- support out of order updates to rxd's
- add prefetching to hardware descriptor rings
- only prefetch on 10G or faster hardware
- add seperate tx queue intr function
- preliminary rework of NETMAP interfaces, WIP

Submitted by:	Matt Macy <mmacy@nextbsd.org>
Sponsored by:	Limelight Networks
2017-03-13 22:53:06 +00:00
Sean Bruno
38b7de95a1 Restore PBA setup for igb(4) class devices.
Do no write to PBA register on igb(4) devices unless we need
to make adjustments for the 82575 and jumbo frames.

Remove redundant LPE/~LPE assignments.

Move e1000_lv_jumbo_workaround_ich8lan() invokcation into a block
so that its not executed in the igb case.

Move em(4) class assignments of RCTL values to its own code block.

Adjust a few direct accesses of ifp->mtu to use accessor functions.

PR:		216734
Submitted by:	Kaho Toshikazu <kaho@elam.kais.kyoto-u.ac.jp>
2017-02-19 05:06:29 +00:00
Sean Bruno
9c030a21d0 Push max_frame_len back into iflib so that jumbo frame sizes work.
Reported by:	pho
2017-02-17 21:30:16 +00:00