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