Subject: Re: Patch for Fast-IPsec over loopback
To: Jun-ichiro itojun Hagino <itojun@itojun.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-net
Date: 08/25/2003 15:39:00
On Sat, 23 Aug 2003, Jun-ichiro itojun Hagino wrote:

> > >>>	i don't think such complexity is not needed.  you just need to cleanup
> > >>>	fast-ipsec m_aux on the call to if_output, that's all you need to do.
> > >> Other users of the packet-tag API disagree.
> > >
> > > 	who are they?
> >
> > He's pimping for me.  In FreeBSD tags are used for more than just data that
> > expire once an mbuf chain hits an interface.  Think of this data as an
> > extension of m_pkthdr.  What's been presented is a (hopefuly) simple
> > compromise that allows us to better cooperate going forward.
>
> 	even in NetBSD m_tag are used not just for ipsec but also other purposes
> 	(VLAN for instance).  however that does not back up his proposal of
> 	removing m_tag in if_loop.c.  m_tag removal has to be implemented in
> 	proper place under fast-ipsec's responsibility, not in if_loop.c
> 	(it is not if_loop's responsibility to clean up garbage for you).

I disagree. I think that it _IS_ if_loop's responsibility, for two
reasons:

1) It's if_loop that is taking an existing packet (with tags) and turning
it around. New fresh-off-the-wire packets don't have tags, or have only
tags specific to the act of reception. It's if_loop that's cheeting that.

ICMP and multicast send out SIMPLEX interfaces are the other examples of
this that I'm aware of.

2) clearing tags at each layer of the stack is inefficient.  Cleaning tags
at each layer means walking the list of tags in it entirety, so you can
find all of them. Assuming tags are named in such a manner that there
aren't name collisions (which really needs to be true anyway for developer
sanity), the names are distinct and nothing else will be using those tags;
nothing in the lower layers will really care that a tag is there or isn't.
So we walk the tag list for no benefit. We do needless work.

While I see the abstraction and design considerations you're thinking of,
Itojun, I really think that making packet processing efficient is more
important.

Ok, make it 3 reasons. 3) We can eventuallythink about bpf gaining a way
to pass packet tags down a tap. :-)

Take care,

Bill