9.2 ixgbe tx queue hang

[Rick Macklem]

Christopher Forgeron wrote:
> 
> 
> 
> 
> 
> 
> On Wed, Mar 26, 2014 at 9:35 PM, Rick Macklem < rmacklem at uoguelph.ca
> > wrote:
> 
> 
> 
> 
> I've suggested in the other thread what you suggested in a recent
> post...ie. to change the default, at least until the propagation
> of driver set values is resolved.
> 
> rick
> 
> 
> 
> I wonder if we need to worry about propagating values up from the
> sub-if's - Setting the default in if.c means this is set for all
> if's, and it's a simple 1 line code change. If a specific 'if' needs
> a different value, it can be set before ether_attach() is called.
> 
> 
> I'm more concerned with the equation we use to calculate if_hw_tsomax
> - Are we considering the right variables? Are we thinking on the
> wrong OSI layer for headers?
> 
Well, I'm pragmatic (which means I mostly care about some fix that works),
but it seems to me that:
- The problem is that some TSO enabled network drivers/hardware can only
  handle 32 transmit segments (or 32 mbufs in the chain for the TSO packet
  to be transmitted, if that is clearer).
--> Since the problem is in certain drivers, it seems that those drivers
    should be where the long term fix goes.
--> Since some hardware can't handle more than 32, it seems that the
    driver should be able to specify that limit, which tcp_output() can
    then apply.

I have an untested patch that does this by adding if_hw_tsomaxseg.
(The attachment called tsomaxseg.patch.)

Changing if_hw_tsomax or its default value is just a hack that gets tcp_output()
to apply a limit that the driver can then fix to 32 mbufs in the chain via
m_defrag().

Since if_hw_tsomax (and if_hw_tsomaxseg in the untested patch) aren't
propagated up through lagg, that needs to be fixed.
(Yet another attached untested patch called lagg.patch.)

As I said before, I don't see these patches getting tested/reviewed etc
in time for 9.3, so I think reducing the default value of if_hw_tsomax
is a reasonable short term hack to work around the problem.
(And it sounds like Pyun YongHyeon has volunteered to fix many of the
drivers, where the 32 limit isn't a hardware one.)

rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsomaxseg.patch
Type: text/x-patch
Size: 4179 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140327/94396432/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lagg.patch
Type: text/x-patch
Size: 1138 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140327/94396432/attachment-0001.bin>