Date: Wed, 02 Apr 2014 11:26:47 +0800 From: k simon <chio1990@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca>, "freebsd-net@freebsd.org >> FreeBSD Net" <freebsd-net@freebsd.org> Subject: Re: 9.2 ixgbe tx queue hang Message-ID: <533B8377.9060209@gmail.com> In-Reply-To: <1292881633.1858906.1395960241007.JavaMail.root@uoguelph.ca> References: <1292881633.1858906.1395960241007.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?533B8377.9060209>