[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101006012509.GA3540@gondor.apana.org.au>
Date: Wed, 6 Oct 2010 09:25:09 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Arnaud Ebalard <arno@...isbad.org>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
netdev@...r.kernel.org
Subject: Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook
in xfrm_input()
On Wed, Oct 06, 2010 at 01:28:42AM +0200, Arnaud Ebalard wrote:
>
> 1) First, current net-next-2.6 (no patches applied)
> 2) then, with my patches applied and CONFIG_XFRM_SUB_POLICY enabled
> 3) then, with my patches applied and CONFIG_XFRM_SUB_POLICY disabled
To measure the effect of this properly you should use null
encryption/hashing and look at the CPU utilisation with minimum
packet sizes.
> > With your remapping, would it be possible to add dummy xfrm_state
> > objects with the remapped destination address that could then call
> > xfrm6_input_addr?
> >
> > That way normal IPsec users would not be affected at all while
> > preserving your new functionality.
>
> I don't think I can do that easily (at all?) with what XFRM provides,
> can I? Or at least I don't see how it is possible because I would need
> some kind of policy for the state to be applied and the only trigger I
> see is the src/dst address mismatch when processing the IPsec packet.
So do you know the remapped destination addresses a priori?
If not then then other possibility would be to add the code hook
in case of xfrm_state_lookup failure.
But more importantly you need to solve the hash collission issue
that I mentioned earlier. Without that it won't work at all.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists