Re: [RFC][IPSEC]: tunnel mode processing
On Fri, 2006-01-09 at 23:04 +1000, Herbert Xu wrote: > 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. gah. Ok, probably better solution to go this path then ;-> 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 ~{PmV>HI~} <[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: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 ~{PmV>HI~} <[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 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 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 ~{PmV>HI~} <[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
