Date: Wed, 9 Aug 2006 19:26:34 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Scott Wilson <scott.wilson@gmail.com> Cc: stable@freebsd.org, "David \(Controller AE\) Christensen" <davidch@broadcom.com>, davidch@freebsd.org, Eric Hodel <drbrain@segment7.net> Subject: Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain! Message-ID: <20060809102634.GD12382@cdnetworks.co.kr> In-Reply-To: <abf642980608090202x43059ae3k684ae2d8adbbfe90@mail.gmail.com> References: <20060808003404.GA5411@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF@NT-IRVA-0750.brcm.ad.broadcom.com> <abf642980608090202x43059ae3k684ae2d8adbbfe90@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 09, 2006 at 11:02:37AM +0200, Scott Wilson wrote: > 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? > There are several cases here. 1. Due to lack of free Tx descriptors bus_dmamap_load_mbuf(9) can fail, so loaded DMA map should be unloaded with bus_dmamap_unload(9) in order to reload it after m_defrag(9) call. 2. If m_defrag(9) fail you may want to free m_head as keeping it in queue may result in stuck condition. Since m_defrag(9) can't defragment the mbuf chain you can never send it again if you requeue the mbuf chain. 3. If the second bus_dmamap_load_mbuf(9) fail you should requeue m_head which was alreay modified with m_defrag(9). Just returning error from failure make bce(4) reuse invalud mbuf chain. As a general rule caller of m_defrag(9) should be prepared to cope with modified mbuf chains when it requeues the mbuf chains. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060809102634.GD12382>