em driver input errors

[Stanislav Sedov]

On Wed, 5 Aug 2009 00:30:20 -0700 (PDT)
alexpalias-bsdstable at yahoo.com mentioned:

> dev.em.0.rx_processing_limit=300
> dev.em.1.rx_processing_limit=300
> dev.em.2.rx_processing_limit=300
> dev.em.3.rx_processing_limit=300
>

This tunables only affects polling mode.  Do you use polling with this
adapters or just standard interrupt-based mode?

<.. snip ..>

> em0: Excessive collisions = 0
> em0: Sequence errors = 0
> em0: Defer count = 402
> em0: Missed Packets = 12762
> em0: Receive No Buffers = 0
> em0: Receive Length Errors = 0
> em0: Receive errors = 0
> em0: Crc errors = 0
> em0: Alignment errors = 0
> em0: Collision/Carrier extension errors = 0
> em0: RX overruns = 237
> em0: watchdog timeouts = 0
> em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0
> em0: XON Rcvd = 249
> em0: XON Xmtd = 244
> em0: XOFF Rcvd = 402
> em0: XOFF Xmtd = 261
> em0: Good Packets Rcvd = 3092053709
> em0: Good Packets Xmtd = 2622962119
> em0: TSO Contexts Xmtd = 12760095
> em0: TSO Contexts Failed = 0
> 

>From the output it looks like that the driver is unable to process the
adapter input queue fast enough so it runs out of free descriptors.  One
of the easiest things you can try is to enable the polling mode and see
if it improves the situation.  You may want also to play with
rx_processing_limit tunables in that case.

The em(4) driver in HEAD also includes multiqueue processing fetaure so
it is possible it will improve the situation for you too.

-- 
Stanislav Sedov
ST4096-RIPE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090806/01c866a9/attachment.pgp