Date: Mon, 24 Mar 2014 09:54:06 -0700 From: Julian Elischer <julian@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca>, Christopher Forgeron <csforgeron@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Garrett Wollman <wollman@freebsd.org>, Jack Vogel <jfvogel@gmail.com>, Markus Gebert <markus.gebert@hostpoint.ch> Subject: Re: 9.2 ixgbe tx queue hang Message-ID: <5330632E.3050505@freebsd.org> In-Reply-To: <1936201708.1670348.1395619029045.JavaMail.root@uoguelph.ca> References: <1936201708.1670348.1395619029045.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/23/14, 4:57 PM, Rick Macklem wrote:
> Christopher Forgeron wrote:
>>
>>
>>
>>
>>
>> On Sat, Mar 22, 2014 at 6:41 PM, Rick Macklem < rmacklem@uoguelph.ca
>>> wrote:
>>
>>
>> Christopher Forgeron wrote:
>>> #if defined(INET) || defined(INET6)
>>> /* Initialize to max value. */
>>> if (ifp->if_hw_tsomax == 0)
>>> ifp->if_hw_tsomax = IP_MAXPACKET;
>>> KASSERT(ifp->if_hw_tsomax <= IP_MAXPACKET &&
>>> ifp->if_hw_tsomax >= IP_MAXPACKET / 8,
>>> ("%s: tsomax outside of range", __func__));
>>> #endif
>>>
>>>
>>> Should this be the location where it's being set rather than in
>>> ixgbe? I would assume that other drivers could fall prey to this
>>> issue.
>>>
>> All of this should be prepended with "I'm an NFS guy, not a
>> networking
>> guy, so I might be wrong".
>>
>> Other drivers (and ixgbe for the 82598 chip) can handle a packet that
>> is in more than 32 mbufs. (I think the 82598 handles 100, grep for
>> SCATTER
>> in *.h in sys/dev/ixgbe.)
>>
the Xen backend can not handle mor ethan 32 segments in some versions
of Xen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5330632E.3050505>