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

[Doug Ambrisko]

Mike Silbersack writes:
| 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. :)

Yes, I was thinking that as well.
 
| > 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 did that in my testing, but just used a printf for debugging.
 
| 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. :)

Maybe an extent count could be used that said how long the chain is.

As Sam mentioned having little things scattered around is not good thing.
Memory and CPU can be a lot faster then the I/O bus.

Doug A.