Date: Wed, 9 Aug 2006 11:02:37 +0200 From: "Scott Wilson" <scott.wilson@gmail.com> To: "David (Controller AE) Christensen" <davidch@broadcom.com> Cc: pyunyh@gmail.com, stable@freebsd.org, davidch@freebsd.org, Eric Hodel <drbrain@segment7.net> Subject: Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain! Message-ID: <abf642980608090202x43059ae3k684ae2d8adbbfe90@mail.gmail.com> In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF@NT-IRVA-0750.brcm.ad.broadcom.com> References: <20060808003404.GA5411@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF@NT-IRVA-0750.brcm.ad.broadcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/8/06, David (Controller AE) Christensen <davidch@broadcom.com> wrote: > > > > Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly > > fragmented packets under heavy loads. To simulate the situation > > you can use m_fragment(9) to fragment the frame in bce_tx_encap(). > > With m_fragment(9), "ping -f -s 65507 x.x.x.x" may trigger it. > > > > I didn't know about m_fragment before. I'll write a note to myself > and look at how to add it to the debug path for a future driver > revision. > > > Btw, I've never seen this small number of Tx DMA segments support( > > BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation? > > > > The real value for BCE_MAX_SEGMENTS should be 16, not 8. I chose 8 as a > reasonable value to start with. If the number of fragments exceeds 16 > then we would expect to see performance drop and it is probably faster > to > have the OS defragment the packet rather than try to perform so many > DMAs. > What I don't understand is why the driver stays locked up after it gets into this mode. I guess that's a separate issue from the low max segments which is triggering it in the first place? -scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?abf642980608090202x43059ae3k684ae2d8adbbfe90>