John-Mark Gurney wrote:
Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400:

Mike Silbersack wrote:

On Fri, 29 Sep 2006, Andre Oppermann wrote:



over it an copies the data into the mbufs by using uiomove(). sosend_dgram() and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin().


Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to
see if performance changes there as well?

Hmm.. I would think 512b and 1K will not show any
improvement.. since they would probably end up either
in an mbuf chain.. or a single 2k (or maybe 4k) cluster..
... quite a waste.. now if we had 512b and 1k clusters that
would be cool...

In fact I have always thought we should:

a) have no data portion in an mbuf.. just pointers i.e. always
  an EXT

b) Have a 256/512 and 1k cluster too..

This would allow copy by reference no matter what size si
being sent...


IMO it's quite a waste of memory the way we have thigns now, though
w/ TSO it'll change things...

Receive path != send path.

w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data,
that's only 60% effeciency wrt to memory usage...  so, we currently
waste 40% of memory allocated to mbufs+clusters...  Even reducing
mbufs back to 128 or 256 would be a big help, though IPSEC I believe
would have issues...

mbufs are 256 bytes.

Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to
fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)...  The
only issue w/ that would be that a few of the clusters would possibly
split page boundaries...  How much this would effect performance would
be an interesting question to answer...

Splitting page boundaries is not an option as it may not be physically
contigous.

Just don't overengineer the stuff.  Mbufs are only used temporarily and
a bit theoretical waste is not much a problem (so far at least).

--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to