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...

Milan
_______________________________________________
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