Subject: Re: Patch for Fast-IPsec over loopback
To: Jason Thorpe <thorpej@wasabisystems.com>
From: Sam Leffler <sam@errno.com>
List: tech-net
Date: 08/22/2003 21:20:19
> On Friday, August 22, 2003, at 06:46  PM, Jun-ichiro itojun Hagino wrote:
>
>> 	because L2 driver behavior is different, ip_output() needs to behave
>> 	differently.  yes, ip_output() should remove ipsec tags used in L3
>> 	logic, and then add ipsec-hardware tags to tell L2 to do special
>> stuff.
>
> No, I don't like that idea.  All that extra allocating/freeing of the
> L2-specific IPsec tags is added expense.  Better for the IPsec tags to be
> generic enough so as to be useful all over.

Yes and no (yes definitely on avoiding the additional overhead).

An important reason for the abi+id "naming" of tags in freebsd is to insure 
that tags are not "generic" but instead private to specific code.  For 
example, tags specific to ipsec should be private to ipsec and no other 
hunk of code should futz with it w/o a well-defined pact or agreement.  The 
notion that tags are "L2" or similar is contrary to this model.

The reason these issues are coming up is because you must do special 
processing when reusing mbufs that have tags associated with them to insure 
the tags are not misinterpreted when/if the mbuf chain passes back through 
the module that installed them.  When packets flow in the expected 
direction (e.g. down to the interface) then the tags are reclaimed together 
with the mbuf chain is reclaimed.  That if_loop re-uses mbufs and passes 
them back up introduces issues.  The other known case is icmp input which 
turns packets around to send a response.

That freebsd has "persistent tags" is not something that netbsd (currently) 
needs to care about, but which we now have a model for.  Jonathan and I 
were just working out a solution whereby he could accommodate our needs 
without unnecessarily burdening netbsd.

I haven't seen Angelos chime in here, but FWIW he has a BSDCon paper about 
tags that echo's what I'm saying (or so I believe :)).

	Sam