9.2 ixgbe tx queue hang

[k simon]

Hi, Rick,
   Does these patches will commit to the stable soon, or I had to patch 
it manually?

Regards
Simon

于 14-3-28 6:44, 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
>
>
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>