On Wed, Aug 09, 2006 at 11:02:37AM +0200, Scott Wilson wrote: > On 8/8/06, David (Controller AE) Christensen <[EMAIL PROTECTED]> 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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"