Re: [RFC][IPSEC]: tunnel mode processing
On Fri, 2006-01-09 at 14:07 +1000, Herbert Xu wrote: On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote: Would it be reasonable to do a check so that incase a skb-dst doesnt exist, the inner headers values can be used i.e something along xfrm4_tunnel_output():: If you didn't care what values they were, couldn't you just stuff some bogus dst into the skb? That bogus dst is NULL ;- If this packet is going somewhere you're going to have a dst one way or another :) If i was going to use routing/layer 3, then true. At the pktgen level somewhere is just shove down the ether. Actually (i havent thought clearly about this) wouldnt a bump in the wire implementation aka bridging level also not care about route details? Note: This does not absolve the need for a secure ipid or a proper ttl. Also, the IPID is only generated if DF is not set on the packet. Otherwise this path is already as fast as it can be. In the case of traffic generation, if i could shave even more cycles the better since i want to generate high speed. In this case the cycles would be in creating a fake dst and attaching it some fake values. I do agree that it is an awkward way of achieving my goals - but i dont know of a clever way to do it ;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][IPSEC]: tunnel mode processing
On Fri, Sep 01, 2006 at 08:17:14AM -0400, jamal wrote:
In the case of traffic generation, if i could shave even more cycles the
better since i want to generate high speed. In this case the cycles
would be in creating a fake dst and attaching it some fake values.
Right, you're testing the receiver side. In that case I suggest that
you replicate the IPsec transport mode logic in the generator. Just
as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't
really need to use xfrm4_output.c to generate IPsec traffic.
You can still call down to esp4.c through the type pointer of course.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][IPSEC]: tunnel mode processing
On Fri, 2006-01-09 at 22:22 +1000, Herbert Xu wrote: Right, you're testing the receiver side. both in/out sides (on the receiver); i just count and drop all packets coming back to the sender (the pktgenerator) In that case I suggest that you replicate the IPsec transport mode logic in the generator. Tunnel mode you mean, i think. Just as pktgen doesn't use net/ipv4/udp.c to generate UDP traffic, it doesn't really need to use xfrm4_output.c to generate IPsec traffic. IPsec is slightly different since i need to use state in the core. i.e it is stateful. Nothing that pktgen does today has such requirements. You can still call down to esp4.c through the type pointer of course. Thats one idea i havent thought of. i.e the code would look like: - if (mode == tunnel) err = mytunneloutput (x, skb); else err = x-mode-output(x, skb); if (err) goto error; err = x-type-output(x, skb); -- This is what you are suggesting? I am probably better off going back to creating a dummy dst with just those two fields when in tunnel mode;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][IPSEC]: tunnel mode processing
On Fri, Sep 01, 2006 at 08:56:18AM -0400, jamal wrote:
Thats one idea i havent thought of.
i.e the code would look like:
-
if (mode == tunnel)
err = mytunneloutput (x, skb);
else
err = x-mode-output(x, skb);
if (err)
goto error;
err = x-type-output(x, skb);
--
This is what you are suggesting?
Yes, I suppose you could even replace x-mode directly.
I am probably better off going back to creating a dummy dst with just
those two fields when in tunnel mode;-
Probably. Although if you write your own output function you could
make it go faster by adapting it to the specifics of pktgen.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][IPSEC]: tunnel mode processing
At the moment transport mode processing is not dependent on skb-dst
being passed. Tunnel mode derives the ip-id and ttl from it. More like
computes ip-id.
I am trying to generate traffic via pktgen and it would be nice if i
could get the same behavior on tunnel mode as in transport mode. I dont
think it matters what the values of those two fields are.
Would it be reasonable to do a check so that incase a skb-dst doesnt
exist, the inner headers values can be used i.e something along
xfrm4_tunnel_output()::
top_iph-frag_off = (flags XFRM_STATE_NOPMTUDISC) ?
0 : (iph-frag_off htons(IP_DF));
if (dst) {
if (!top_iph-frag_off)
__ip_select_ident(top_iph, dst-child, 0);
top_iph-ttl = dst_metric(dst-child, RTAX_HOPLIMIT);
} else {
top_iph-id = iph-id;
top_iph-ttl = iph-ttl;
}
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][IPSEC]: tunnel mode processing
On Thu, Aug 31, 2006 at 08:55:27PM -0400, jamal wrote:
Would it be reasonable to do a check so that incase a skb-dst doesnt
exist, the inner headers values can be used i.e something along
xfrm4_tunnel_output()::
If you didn't care what values they were, couldn't you just stuff some
bogus dst into the skb? If this packet is going somewhere you're going
to have a dst one way or another :)
Also, the IPID is only generated if DF is not set on the packet.
Otherwise this path is already as fast as it can be.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
