Splitting ip{,6}_output

[DEGROOTE Arnaud]

In order to better integrate the fast_ipsec with our ipv{4,6} processing,
we need to make some changes to the current way to deal in the output
processing. Currently, we do something like that

ip6_output calls ipsec6_process_packet which process the ipsec
transformation on an asynchronous way. When it has finished,
ipsec_process_done is called and the packet is reinjected in ip6_output
with dummy arguments.

There is two problems here :
- we lose the current argument of ip6_output ( all the options in
particulary )
- we process some things that we already have processed on the first
pass

The situation is quite the same on the v4 side, maybe worse because when we
call ipsec4_process_packet, we have already process most of the ip_output
function.

The solution I have previously proposed for the v6 side, during the SoC is
to split the stack in two ip6_output and ip6_output2, and the
ipsec_process_done will callback in the ip6 output code with ip6_output2.

I propose to do the same thing for the netinet stack. I don't expect
any performance decrease.

You can find the both patchs attached.

Can people comment it ? I'm interested too if you have any better ideas.
If nobody has strong objections, I will commit it next week.

Take cares

--
Arnaud Degroote

[j***@dsg.stanford.edu]

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In order to better integrate the fast_ipsec with our ipv{4,6} processing,
we need to make some changes to the current way to deal in the output
processing. Currently, we do something like that
ip6_output calls ipsec6_process_packet which process the ipsec
transformation on an asynchronous way. When it has finished,
ipsec_process_done is called and the packet is reinjected in ip6_output
with dummy arguments.
- we lose the current argument of ip6_output ( all the options in
particulary )
- we process some things that we already have processed on the first
pass
The situation is quite the same on the v4 side, maybe worse because when we
call ipsec4_process_packet, we have already process most of the ip_output
function.

But for tunnel mode, don't we *want* to redo all that work?
("need to" might be more accurate.)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[degroote.netbsd]

Arnaud writes

Post by j***@dsg.stanford.edu

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In order to better integrate the fast_ipsec with our

ipv{4,6} processing,

Post by j***@dsg.stanford.edu

we need to make some changes to the current way to deal in

the output

Post by j***@dsg.stanford.edu

processing. Currently, we do something like that
ip6_output calls ipsec6_process_packet which process the ipsec
transformation on an asynchronous way. When it has finished,
ipsec_process_done is called and the packet is reinjected

in ip6_output

Post by j***@dsg.stanford.edu

with dummy arguments.
- we lose the current argument of ip6_output ( all the

options in

Post by j***@dsg.stanford.edu

particulary )
- we process some things that we already have processed

on the first

Post by j***@dsg.stanford.edu

pass
The situation is quite the same on the v4 side, maybe worse

because when we

Post by j***@dsg.stanford.edu

call ipsec4_process_packet, we have already process most of

the ip_output

Post by j***@dsg.stanford.edu

function.

But for tunnel mode, don't we *want* to redo all that work?
("need to" might be more accurate.)

I understand what you mean. I think in fact we don't need to
redo all the work. Kame ipsec doesn't do it and I think it is
safe. On V6 side, we do the ipsec transformation very quickly,
so if we don't reenter directly in ip6_output, we just miss
the creation of extension headers ( a thing we must not do on
tunnel mode ). So in v6 side, it is quite clear it is safe to
reenter only into ip6_output2.

On v4 side, it is maybe a bit less clear but we can assume
that the ipsec code has added a valid ipv4 header. We only
must check if we can join dst with the route stored in the SA.
This test can be easily done before reentring in ip_output2.

Splitting the stack for the v4 side is not an absolute need,
it would be better to have two parts from the point of view of
fast_ipsec but if someone think that it is required to replay
all the ip output stack, I can let the netinet code in the
current state.

Envoyez vos cartes de voeux depuis www.laposte.net
Elles seront ensuite distribuées par le facteur : pratique et malin !


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de