| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix and clean up usage of DMA and TSO segments:
- At Intel it is believed that most of their products support "only"
40 DMA segments so lower {EM,IGB}_MAX_SCATTER accordingly. Actually,
40 is more than plenty to handle full size TSO packets so it doesn't
make sense to further distinguish between MAC variants that really
can do 64 DMA segments. Moreover, capping at 40 DMA segments limits
the stack usage of {em,igb}_xmit() that - given the rare use of more
than these - previously hardly was justifiable, while still being
sufficient to avoid the problems seen with em(4) and EM_MAX_SCATTER
set to 32.
- In igb(4), pass the actually supported TSO parameters up the stack.
Previously, the defaults set in if_attach_internal() were applied,
i. e. a maximum of 35 TSO segments, which made supporting more than
these in the driver pointless. However, this might explain why no
problems were seen with IGB_MAX_SCATTER at 64.
- In em(4), take the 5 m_pullup(9) invocations performed by em_xmit()
in the TSO case into account when reporting TSO parameters upwards.
In the worst case, each of these calls will add another mbuf and,
thus, the requirement for an additional DMA segment. So for best
performance, it doesn't make sense to advertize a maximum of TSO
segments that typically will require defragmentation in em_xmit().
Again, this leaves enough room to handle full size TSO packets.
- Drop TSO macros from if_lem.h given that corresponding MACS don't
support TSO in the first place.
Reviewed by: erj, sbruno, jeffrey.e.pieper_intel.com
Approved by: re (gjb)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that don't apply to stable/10 (driver API, if_inc_counter(), RSS changes
etc.) and modulo r287465 (which reportedly breaks igb(4)), i. e. assorted
fixes and improvements only:
o MFC r267385 (partial):
- Don't compare bus_dma map pointers for static DMA allocations against
NULL to determine if bus_dmamap_unload() or bus_dmamem_free() should be
called. Instead, check the associated bus and virtual addresses.
- Don't clear static DMA maps to NULL.
o MFC r284933:
Delete the refernce to VLAN handling being disabled by default. This is
no longer the case. [1]
o MFC r285639:
Add an adapter CORE lock in the DDB hook em_dump_queue to avoid WITNESS
panic in em_init_locked() while debugging.
o MFC r285879:
- Remove unused txd_saved.
- Intialize txd_upper, txd_lower and txd_used at declaration.
o MFC r286162:
Free mbufs when busdma loading fails.
o MFC r286829:
Add capability to disable CRC stripping as it breaks IPMI/BMC capabilities
on certain adatpers. [2]
o MFC r286831: [3]
- Increase EM_MAX_SCATTER to 64 such that the size of em_xmit()::
segs[EM_MAX_SCATTER] doesn't get overrun by things like NFS that can
and do shove more than 32 segs when being used with em(4) and TSO4.
- Update tso handling code in em_xmit() with update from jhb@
- Set if_hw_tsomax, if_hw_tsomaxsegcount and if_hw_tsomaxsegsize to
appropriate values.
- Define a TSO workaround "magic" number of 4 that is used to avoid an
alignment issue in hardware.
- Change a couple of integer values that were used as booleans to actual
bool types.
- Ensure that em_enable_intr() enables the appropriate mask of interrupts
and not just a hardcoded define of values.
o MFC r286832:
e1000/if_lem.c bump to 1.1.0
o MFC r286833:
Bump all copywrite dates to 2015.
o MFC r287112:
Style/whitespace cleanup in shared/common code.
o MFC r293331:
- Switch em(4) to the extended RX descriptor format.
- Split rxbuffer and txbuffer apart to support the new RX descriptor
format structures. Move rxbuffer manipulation to em_setup_rxdesc() to
unify the new behavior changes.
- Add a RSSKEYLEN macro for help in generating the RSSKEY data structures
in the card.
- Change em_receive_checksum() to process the new rxdescriptor format
status bit.
o MFC r293332:
Disable the reuse of checksum offload context descriptors in the case
of multiple queues in em(4). Document errata in the code.
o MFC r293854:
Given that em(4), lem(4) and igb(4) hardware doesn't require the
alignment guarantees provided by m_defrag(9), use m_collapse(9)
instead for performance reasons.
While at it, sanitize the statistics softc members, i. e. retire
unused ones and add SYSCTL nodes missing for actually used ones.
PR: 118693 [1], 161277 [2], 195078 [3], 199174 [3], 200221 [3]
|
| |
|
|
|
|
|
|
|
|
| |
The paravirt support for the driver and netmap code was already MFCed,
but the adapter and ifnet API bits weren't.
This was backported from -HEAD by Eric Melville <eric@freebsd.org>.
Submitted by: eric
Sponsored by: Norse Corp, Inc.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
irrespective of the setting of lem_rx_process_limit, while
giving a chance to the taskqueue scheduler to act after
each chunk.
This makes lem_rxeof similar to the one in if_em.c and if_igb.c .
if_lem.c and if_em.c: add a sysctl to manually configure the
'itr' moderation register.
Approved by: Jack Vogel
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There have still been intermittent problems with apparent TX
hangs for some customers. These have been problematic to reproduce
but I believe these changes will address them. Testing on a number
of fronts have been positive.
EM: there is an important 'chicken bit' fix for 82574 in the shared
code this is supported in the core here.
- The TX path has been tightened up to improve performance. In
particular UDP with jumbo frames was having problems, and the
changes here have improved that.
- OACTIVE has been used more carefully on the theory that some
hangs may be due to a problem in this interaction
- Problems with the RX init code, the "lazy" allocation and
ring initialization has been found to cause problems in some
newer client systems, and as it really is not that big a win
(its not in a hot path) it seems best to remove it.
- HWTSO was broken when VLAN HWTAGGING or HWFILTER is used, I
found this was due to an error in setting up the descriptors
in em_xmit.
IGB:
- TX is also improved here. With multiqueue I realized its very
important to handle OACTIVE only under the CORE lock so there
are no races between the queues.
- Flow Control handling was broken in a couple ways, I have changed
and I hope improved that in this delta.
- UDP also had a problem in the TX path here, it was change to
improve that.
- On some hardware, with the driver static, a weird stray interrupt
seems to sometimes fire and cause a panic in the RX mbuf refresh
code. This is addressed by setting interrupts late in the init
path, and also to set all interrupts bits off at the start of that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
been undergoing test for some weeks. This improves the RX
mbuf handling to avoid system hang due to depletion. Thanks
to all those who have been testing the code, and to Beezar
Liu for the design changes.
Next the igb driver is updated for similar RX changes, but
also to add new features support for our upcoming i350 family
of adapters.
MFC after a week
|
| |
|
|
|
|
| |
Delete a unneeded test from the beginning of em_xmit.
CRITICAL: shared code fix for 82574, a mutex might not be
released, this can cause hangs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add a single sysctl procedure to all three drivers to read an arbitrary
register (the register is passed as arg2). Use it to replace existing
routines in igb(4) that used a separate routine for each register, and
to add support for missing stats in em(4) and lem(4).
- Move the 'rx_overruns' and 'watchdog_timeouts' stats out of the MAC stats
section as they are driver stats, not MAC counters.
- Simplify the code that creates per-queue stats in igb(4) to use a single
loop and remove duplicated code.
- Properly read all 64 bits of the 'good octets received/transmitted' in
em(4) and lem(4).
- Actually read the interrupt count registers in em(4), and drop the
'host to card' sysctl stats from em(4) as they are not implemented in
any of the hardware this driver supports.
- Restore several stats to em(4) that were lost in the earlier stats
conversion including per-queue stats.
- Export several MAC stats in em(4) that were exported in igb(4) but not
in em(4).
- Export stats in lem(4) using individual sysctls as in em(4) and igb(4).
Reviewed by: jfv
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
configuration function. For failed memory allocations, em(4)/lem(4)
called panic(9) which is not acceptable on production box.
igb(4)/ixgb(4)/ix(4) allocated the required memory in stack which
consumed 768 bytes of stack memory which looks too big.
To address these issues, allocate multicast array memory in device
attach time and make multicast configuration success under any
conditions. This change also removes the excessive use of memory in
stack.
Reviewed by: jfv
|
| |
|
|
|
|
|
|
| |
led(4) so they can be lit or f.e. made blink via `echo f2 > /dev/led/em0`
for localization purposes.
Approved by: jfv
MFC afer: 1 week (after r205869)
|
|
|
em revision 7.0.0:
- Using driver devclass, seperate legacy (pre-pcie) code
into a seperate source file. This will at least help
protect against regression issues. It compiles along
with em, and is transparent to end use, devices in each
appear to be 'emX'. When using em in a modular form this
also allows the legacy stuff to be defined out.
- Add tx and rx rings as in igb, in the 82574 this becomes
actual multiqueue for the first time (2 queues) while in
other PCIE adapters its just make code cleaner.
- Add RX mbuf handling logic that matches igb, this will
eliminate packet drops due to temporary mbuf shortage.
igb revision 1.9.3:
- Following the ixgbe code, use a new approach in what
was called 'get_buf', the routine now has been made
independent of rxeof, it now does the update to the
engine TDT register, this design allows temporary
mbuf resources to become non-critical, not requiring
a packet to be discarded, instead it just returns and
does not increment the tail pointer.
- With the above change it was also unnecessary to keep
'spare' maps around, since we do not have the discard
issue.
- Performance tweaks and improvements to the code also.
MFC in a week
|
