netdev
[Top] [All Lists]

Re: [PATCH] IPv6 IPsec support

To: kunihiro@xxxxxxxxxxxxxx
Subject: Re: [PATCH] IPv6 IPsec support
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 18 Feb 2003 23:02:11 -0800 (PST)
Cc: Kazunori.Miyazawa@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, usagi-core@xxxxxxxxxxxxxx, kuznet@xxxxxxxxxxxxx
In-reply-to: <87znos3j8s.wl@ipinfusion.com>
References: <20030219134850.5f203ea7.Kazunori.Miyazawa@jp.yokogawa.com> <87znos3j8s.wl@ipinfusion.com>
Sender: netdev-bounce@xxxxxxxxxxx
   From: Kunihiro Ishiguro <kunihiro@xxxxxxxxxxxxxx>
   Date: Tue, 18 Feb 2003 21:57:39 -0800

   I think no need of broadcasting my comments to kernel ML, so I took it
   of from CC:.  netdev guys will be interested in right?  So I kept it.
   
Yes, this is fine.

   1. Do we really need to remove AH header from skb?
   
   In case of IPv4 we modify iph->protocol for further processing thus AH
   header is removed.  But in case of IPv6, we just simply authenticate
   the packet then process next header.  So do we really need to remove
   AH header in IPv6?  Remaining AH header does not harm...
   
This is an interesting topic.

Actually, there is no reason to prefer one way or another.
Remember, if anyone else is interested in SKB contents (such as
tcpdump), that entity has clone of skb and can still see full
contents.

   2. Easy kmalloc()...
   
   It seems there are some easy kmalloc().  Yes I'm stingy with memory.

It is another fun topic.

These are great long term improvements.  But for now, please consider
something important when evaluating "overhead".  This is the fact that
we are performing full encryption or hash function.  Such operation is
quite massively more expensive than kmalloc here and there.

Some day we will have hw acceleration support both at IPSEC and at
crypto library level.  At that time cost analysis will change.

   Well, I'll find more.  Maybe we should be offline and come up with a
   single patch.

I would ask that Alexey and myself stay on the CC: list.

It would not hurt to keep netdev as well, perhaps we can
breed some new experts in our ipsec code :-)


<Prev in Thread] Current Thread [Next in Thread>