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