9.2 ixgbe tx queue hang

[Rick Macklem]

K Simon wrote:
> Hi, Rick,
>    Does these patches will commit to the stable soon, or I had to
>    patch
> it manually?
> 
Yonghyeon Pyun has already committed the changes for the drivers to
head (making them handle 35 mbufs in the chain instead of 32). I'll
assume those will be in stable in a couple of weeks.

I will be able to commit the one line change that reduces the default
setting for if_hw_tsomax in a couple of weeks, so it should be in stable
in about 1month.

rick

> 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"
> >
> _______________________________________________
> 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"