Julian's netowrking challenge 2005

Milan Obuch net at dino.sk
Tue Jun 28 12:16:00 GMT 2005


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 :)

> 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 :)]

Milan


More information about the freebsd-net mailing list