Julian's netowrking challenge 2005

[Max Laier]

On Tuesday 28 June 2005 13:10, Milan Obuch wrote:
> On Tuesday 28 June 2005 12:37, Max Laier wrote:
> > On Tuesday 28 June 2005 12:27, Jeremie Le Hen wrote:
> > > > Wouldn't a more general approach be better.  e.g. a way to "tag" a
> > > > packet before it is sent to divert and a matching tag-lookup that can
> > > > do further action.  This would make it very easy to do all kinds of
> > > > stuff that needs to know the original address instead of the
> > > > translated one while avoiding code duplication.
> > >
> > > Having the possibility to tag a packet would be worth indeed.  But I
> > > think that Milan wants to bring network stack virtualization in
> > > newer release of FreeBSD IIUC.  This would be, IMO, a great improvement
> > > of FreeBSD networking, although I'm pretty sure this would make
> > > Netgraph people react a bit ;-).
> >
> > Stack virtualization is independent of this.  All I am trying to say
> > here, is that I think it is better to have a general mechanism to do
> > thing like that, instead of a special solution for fwd (i.e.
> > set-nexthop).
>
> We agree on this. Tagging and virtualization are independent and solve
> different purposes. My reaction was to post mentioning request caused from
> various limitations/deficiences, namely lack of multiple routing tables
> support.
>
> > > > 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).

On the other hand a zone allocator for mbuf tags might be the right sollution 
here?

-- 
/"\  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/71c783c9/attachment.bin