Julian's netowrking challenge 2005

[Max Laier]

On Tuesday 28 June 2005 14:15, Milan Obuch wrote:
> On Tuesday 28 June 2005 14:09, Max Laier wrote:
> ...
>
> > > > > > pf does something along these lines in case you are looking for
> > > > > > references.
> > > > >
> > > > > Would it be possible to share this tag among pf and ipfw ?
> > > >
> > > > Sure, it's a simple mbuf tag with a (at this point) 16bit cookie. 
> > > > The downside of this approach is that you need to malloc the tag, but
> > > > on the other hand it's even more complicated for set-nexthop where
> > > > you need to allocate a route and maybe even hold it for some time and
> > > > make sure you properly GC it ... tags seem way simpler to me.
> > >
> > > Agreed. I am far from being networking code guru, so maybe this
> > > question sounds stupid, but could not this cookie be allocated when
> > > packet enters system? Maybe optionally...
> >
> > We could always extend the pkthdr to hold more information.  An
> > additional bitfield and maybe a 32Bit cookie might be useful, but there
> > are tradoffs to consider:  Dragonfly did extend the pkthdr to pack all
> > the possible pf mbuf tags inside it.  This adds 12 byte at the moment. 
> > As a consequence it decreases the datasize in presence of a pkthdr by 12
> > byte.  With an MSIZE of 256 this means you can have 219 (32bit
> > pointer/int) / 195 (64bit pointer/int) byte in a packet before you need
> > to create an mbuf cluster. With FreeBSD (also using MSIZE of 256) this is
> > 231 / 207 - one has to carefully look at mean packet sizes to evaluate if
> > this is a tradeoff that is worth paying. Keep in mind that not everybody
> > does packet filtering and might just need raw packet pushing performace
> > (i.e. wants to avoid mbuf clusters for small packets at any cost).
>
> Well, that's why I said optionally. The question remains how this option
> should be turned on. We need some evaluation on this option - now it is
> just a guess. After some benchmarking on both approaches we could build an
> educated guess :)

The problem here is that this has to be a static thing (otherwise you need an 
additional malloc and your possible performance gain is lost).  If you change 
MSIZE or sizeof(struct pkthdr) on a kernel option, you will have to recompile 
all network device drivers and everything else that touches mbufs.  This will 
effectively prevent the use of 3rd party drivers.  So it has to be one size 
fits all, which is - most likely - the minimal version pkthdr and additional 
mallocs when needed.

> > On the other hand a zone allocator for mbuf tags might be the right
> > sollution here?
>
> [This space left for those understanding this issue at least a bit :)]

See zone(9) for details.  Basically we would have a cache of mbuf tags that 
get reused, thus taking of pressure off the rest of the memory management 
system.  Again we have to evaluate carefully if that is actually a 
performance gain or hit - though I certainly suspect a gain.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20050628/b34627ab/attachment.bin