From: Kazunori Miyazawa <[email protected]>
Date: Wed, 5 Mar 2003 23:30:25 +0900
Hello Miyazawa-san,
I submit the patch to let the kernel support ipv6 ipsec again.
It is able to comple ipv6 as module.
This patch incldes a couple of clean-up and
changes of function name.
Excellent work.
I have comments, but they are very minor and can wait.
I will apply your patch after basic build testing.
The next large task will be to abstract out more common
pieces of code. There is still quite a bit of code duplication
between v4 and v6 xfrm methods,
Thank you!
In article <[email protected]> (at Wed, 05 Mar 2003 07:21:49 -0800 (PST)), "David S. Miller" <[email protected]> says:
> I will apply your patch after basic build testing.
Thank you.
> The next large task will be to abstract out more common
> pieces of code. There is still quite a bit of code duplication
> between v4 and v6 xfrm methods,
Yes, we will do that. That patch is first step for reducing
duplicate codes between IPv4 and IPv6.
--yoshfuji
From: YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
Date: Thu, 06 Mar 2003 00:48:20 +0900 (JST)
> The next large task will be to abstract out more common
> pieces of code. There is still quite a bit of code duplication
> between v4 and v6 xfrm methods,
Yes, we will do that. That patch is first step for reducing
duplicate codes between IPv4 and IPv6.
Great. I believe it should be possible, in the end, to make the XFRM
engine %100 address-family (v4, v6 etc.) and protocol (ah, esp)
independant. If that goal is achieved, we may move generic parts from
net/ipv4/xfrm_*.c to net/xfrm_*.c
Note that this coincides with the idea to eventually have
an address-family independant flow cache.
Most of the address-family specific areas are:
1) DST lookup (xfrm_dst_lookup_t)
2) selector key comparisons and state lookup
(xfrm$(AF)_selector_match, xfrm$(AF)_state_find)
3) receive processing (xfrm${AF}_rcv)
#1 is made for ipv6 by Miyazawa-san's patch. This could logically
be extended to handle issues #2 and #3 above.
All protocol specific (ESP, AH) and address-family specific references
should go away from places like include/net/xfrm.h
I think you understand all of this, and therefore I cannot wait for the
next ipsec cleanup patch from you :)
Finally, note that eventually we will need some reference counting scheme
for to allow xfrm address-family modules to be unloaded safely.
Currently, ipv4 cannot be a module and ipv6 as a module is not able
to unload :-) So the module unload problem does not exist right
at this moment. So ignore this issue for now.
On Wed, Mar 05, 2003 at 03:41:00PM -0800, David S. Miller wrote:
> Note that this coincides with the idea to eventually have an
> address-family independant flow cache.
Actually... at that point being able to monitor updates to the
flow-cache would be useful for various statistical purposes and
applications, especially if the flow cache was able to periodically
export utilization counters...
--cw
From: Chris Wedgwood <[email protected]>
Date: Thu, 6 Mar 2003 13:32:17 -0800
Actually... at that point being able to monitor updates to the
flow-cache would be useful for various statistical purposes and
applications, especially if the flow cache was able to periodically
export utilization counters...
It will keep statistics, just like the route cache keeps
them now.