cvs commit: src/sys/conf options src/sys/netinet ip_output.c

Mike Silbersack silby at
Wed Mar 26 01:50:47 PST 2003

On Tue, 25 Mar 2003, Doug Ambrisko wrote:

> Mike Silbersack writes:
> |
> | FWIW, the two drivers I tested this with (if_xl and if_sis) both flunk.
> | if_xl tries to fix the situation, but fails, and if_sis goes totally
> | weird, eating mbufs and rendering the interface unuseable.
> |
> | I'll test more interfaces once I have these two fixed.
> This doesn't surprise me.  I fixed this in the ste(4) driver.  You can
> also make this happen to some extent by do a dd etc. into a connection
> with a small byte count.  This makes it easier though.
> Most of this is probably due to a common cut-n-paste of other drivers.

I think that we'll end up being even better off by just making a
m_defragment function, thereby reducing code duplication even more.  I'll
make sure to test any such function more than I tested the MBUF_FRAG_TEST
code, however. :)

> Might also look at tuning down the number of allowable frags in drivers.
> With 4 ste(4) chips on 3 ports consumed 1.5M of memory!  I reduced this
> in the ste(4) driver as well.  We might want to document a good rule of
> thumb for number of mbuf frags before de-fraging them.  Unfortunately
> this seems to imply you might have to walk the mbuf chain twice.

Hm, I suppose it would be pretty easy to tack together some statistics
code which tracked how long the chains being sent to the drivers are.

I've been pondering where the tradeoff between avoiding memory copies and
doing excessive scatter / gather DMA lies.  Perhaps we should be
defragmenting any chain over a certain amount of length, no matter the
limit imposed by the card.  This sounds like a Terry question. :)

Mike "Silby" Silbersack

More information about the cvs-src mailing list