Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-06 Thread jamal 
On Wed, 2006-06-09 at 09:38 +1000, Herbert Xu wrote:
 On Sat, Sep 02, 2006 at 09:43:02AM -0400, jamal wrote:
 
  Allow for searching the SAD from external data path points without
  assumming L3 details. The only customer of this exposure currently
  is pktgen.
 
 Any reason why xfrm_state_find can't be used? 

xfrm_state_find is overkill (if you compare the two functionalities). 

 It doesn't look right
 to add generic code that's only used by pktgen.

The alternative would require heavy mods to xfrm_state_find to do the
minimal needed (a lot more than what i was asking for in mode output). I
could move the function to outside of xfrm_state.c but that would
require a few exports for it to use which looks less fair to me ;- 

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: [IPSEC]: searching SAD without assumming L3 details

2006-09-06 Thread Herbert Xu 
On Wed, Sep 06, 2006 at 07:20:39AM -0400, jamal wrote:

  Any reason why xfrm_state_find can't be used? 
 
 xfrm_state_find is overkill (if you compare the two functionalities). 

Could you show me how you plan to use this in pktgen? Perhaps we can
move it to the slow path where it wouldn't matter whether it's an
overkill or not.  There should be no reason to be looking up an SA
in the pktgen fast path.

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: [IPSEC]: searching SAD without assumming L3 details

2006-09-06 Thread jamal 
On Wed, 2006-06-09 at 21:26 +1000, Herbert Xu wrote:
 On Wed, Sep 06, 2006 at 07:20:39AM -0400, jamal wrote:
 
   Any reason why xfrm_state_find can't be used? 
  
  xfrm_state_find is overkill (if you compare the two functionalities). 
 
 Could you show me how you plan to use this in pktgen? 

Older patch attached - has a few bugs; just ignore them.

 Perhaps we can
 move it to the slow path where it wouldn't matter whether it's an
 overkill or not.  There should be no reason to be looking up an SA
 in the pktgen fast path.

It is needed if you want replay protection - unless you can come with
some clever way to handle it without violating the integrity. 
For non replay protection, thats easy: We just do one lookup and reclone
the packet within pktgen - maybe thats what you meant by slow path?

cheers,
jamal
Add IPSEC support to pktgen. Currently only IPV4 and ESP/Transport
mode. IPV6 next. And Tunnel mode to follow after some discussions with
Herbert and Dave.

---
commit 0721d8f9d3e1a9a8f5f038365ae12ec605a2d5d6
tree 3069707bec44c992c0bfdbe871c7e3bd68d37882
parent 1a4c28d2bd2fcf82b84bffdb7be47aa9224483d0
author Jamal Hadi Salim [EMAIL PROTECTED] Tue, 22 Aug 2006 21:43:37 -0400
committer Jamal Hadi Salim [EMAIL PROTECTED](none) Tue, 22 Aug 2006 21:43:37 
-0400

 net/core/pktgen.c |  169 +
 1 files changed, 156 insertions(+), 13 deletions(-)

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 67ed14d..5fc725d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -148,6 +148,7 @@ #include linux/etherdevice.h
 #include net/checksum.h
 #include net/ipv6.h
 #include net/addrconf.h
+#include net/xfrm.h
 #include asm/byteorder.h
 #include linux/rcupdate.h
 #include asm/bitops.h
@@ -178,6 +179,8 @@ #define F_MACDST_RND  (15)/* MAC-Dst 
 #define F_TXSIZE_RND  (16)   /* Transmit size is random */
 #define F_IPV6(17)   /* Interface in IPV6 Mode */
 #define F_MPLS_RND(18)   /* Random MPLS labels */
+#define F_FLOW_RND(19)   /* Random flows */
+#define F_IPSEC_ON(110)  /* Run ipsec when possible */
 
 /* Thread control flag bits */
 #define T_TERMINATE   (10)
@@ -200,6 +203,7 @@ #define MAX_CFLOWS  65536
 
 struct flow_state {
__u32 cur_daddr;
+   struct xfrm_state *x;
int count;
 };
 
@@ -226,6 +230,7 @@ struct pktgen_dev {
 
int min_pkt_size;   /* = ETH_ZLEN; */
int max_pkt_size;   /* = ETH_ZLEN; */
+   int pkt_overhead;   /* overhead in case of MPLS or IPSEC */
int nfrags;
__u32 delay_us; /* Default delay */
__u32 delay_ns;
@@ -324,6 +329,8 @@ struct pktgen_dev {
 */
struct flow_state *flows;
unsigned cflows;/* Concurrent flows (config) */
+   unsigned nextfl;/* next flow when not random */
+   unsigned curfl; /* current running flow */
unsigned lflow; /* Flow length  (config) */
unsigned nflows;/* accumulated flows (stats) */
 };
@@ -667,6 +674,14 @@ static int pktgen_if_show(struct seq_fil
if (pkt_dev-flags  F_MPLS_RND)
seq_printf(seq,  MPLS_RND  );
 
+   if (pkt_dev-flags  F_FLOW_RND)
+   seq_printf(seq,  FLOW_RND  );
+   else
+   seq_printf(seq,  FLOW_SQN  ); /*in sequence */
+
+   if (pkt_dev-flags  F_IPSEC_ON)
+   seq_printf(seq,  IPSEC_ON  );
+
if (pkt_dev-flags  F_MACSRC_RND)
seq_printf(seq, MACSRC_RND  );
 
@@ -1140,6 +1155,12 @@ static ssize_t pktgen_if_write(struct fi
else if (strcmp(f, !MPLS_RND) == 0)
pkt_dev-flags = ~F_MPLS_RND;
 
+   else if (strcmp(f, IPSEC_ON) == 0)
+   pkt_dev-flags |= F_IPSEC_ON;
+
+   else if (strcmp(f, !IPSEC_ON) == 0)
+   pkt_dev-flags = ~F_IPSEC_ON;
+
else {
sprintf(pg_result,
Flag -:%s:- unknown\nAvailable flags, (prepend 
! to un-set flag):\n%s,
@@ -1447,6 +1468,10 @@ static ssize_t pktgen_if_write(struct fi
  n == pkt_dev-nr_labels-1 ?  : ,);
return count;
}
+   if (!strcmp(name, ipsec)) {
+   /*XXX: Add the OK: ipsec on thing */
+   pkt_dev-flags |= F_IPSEC_ON;
+   }
 
sprintf(pkt_dev-result, No such parameter \%s\, name);
return -EINVAL;
@@ -1879,11 +1904,26 @@ static void mod_cur_headers(struct pktge
__u32 imx;
int flow = 0;
 
+   pkt_dev-pkt_overhead = 0;
if (pkt_dev-cflows) {
-   flow = pktgen_random() % pkt_dev-cflows;
+   if (pkt_dev-flags  F_FLOW_RND) {
+   flow = pktgen_random() % pkt_dev-cflows;
+   if (pkt_dev-flows[flow].count  pkt_dev-lflow)
+

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-06 Thread jamal 
On Wed, 2006-06-09 at 08:14 -0400, jamal wrote:
 maybe thats what you meant by slow path?

Never mind what i said above;- what is needed to have replay protection
is calling the IPSEC fast path. The xfrm state is looked up during the
pktgen fast still because flows are created as needed on the fly. You
could argue that we need to change the architecture of pktgen so it
creates all flows first, but that is a huge change.
If i can read your mind correctly (;-)you may be thinking of splitting
xfrm_state_find() into two pieces: a slow path lookup which perhaps
involves the manager and a fast path which looks up just the SAD?
Note, theres still a lot of clunky stuff like policies and templates and
flowis etc that i dont need.

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: [IPSEC]: searching SAD without assumming L3 details

2006-09-05 Thread Herbert Xu 
On Sat, Sep 02, 2006 at 09:43:02AM -0400, jamal wrote:

 Allow for searching the SAD from external data path points without
 assumming L3 details. The only customer of this exposure currently
 is pktgen.

Any reason why xfrm_state_find can't be used? It doesn't look right
to add generic code that's only used by 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

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread James Morris 
On Sat, 2 Sep 2006, jamal wrote:

 Against net-2.6.19
 
 signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]

+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr, 
+   unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+   unsigned int h = xfrm_dst_hash(daddr, saddr, 0, family);
+   struct xfrm_state *rx = NULL, *x = NULL;
+   struct hlist_node *entry;
+   
+   spin_lock(xfrm_state_lock);

Shouldn't this be spin_lock_bh()?

+   spin_unlock(xfrm_state_lock);
+
+   if (rx)
+   xfrm_state_hold(rx);

I think you need to grab the reference before letting go of the lock.


Can you please include patches inline, or tell me how to get pine to 
quote attachments? :-)


-- 
James Morris
[EMAIL PROTECTED]

-- 
VGER BF report: U 0.5
-
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: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread jamal 
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
 On Sat, 2 Sep 2006, jamal wrote:

 +   
 +   spin_lock(xfrm_state_lock);
 
 Shouldn't this be spin_lock_bh()?
 
 +   spin_unlock(xfrm_state_lock);
 +

the call is made at the moment only by pktgen (kernel threads on
dev_queue_xmit level contending with softirqs essentially). I think
(although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
Obviously the easy thing for me to do is change it and see what
happens;-

 +   if (rx)
 +   xfrm_state_hold(rx);
 
 I think you need to grab the reference before letting go of the lock.
 

I believe you are right. I will make the change, retest and repost.

 
 Can you please include patches inline, or tell me how to get pine to 
 quote attachments? :-)

I could get evolution to inline attachments although last time i tried
it made Dave unhappy with not being to use git am or some such
reason ;- I think some white spaces get added or some other mangling
happens.
I could try it on the repost.

Thanks for the comments James.

cheers,
jamal




-- 
VGER BF report: U 0.55
-
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: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread jamal 
On Sat, 2006-02-09 at 13:16 -0400, jamal wrote:

 the call is made at the moment only by pktgen (kernel threads on
 dev_queue_xmit level contending with softirqs essentially). I think
 (although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
 Obviously the easy thing for me to do is change it and see what
 happens;-

Both your suggestions work. Should i instead just use read_{un}lock_bh?
All i am doing is scanning to find the state.

cheers,
jamal



-- 
VGER BF report: U 0.502731
-
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: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread James Morris 
On Sat, 2 Sep 2006, jamal wrote:

 On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
  On Sat, 2 Sep 2006, jamal wrote:
 
  +   
  +   spin_lock(xfrm_state_lock);
  
  Shouldn't this be spin_lock_bh()?
  
  +   spin_unlock(xfrm_state_lock);
  +
 
 the call is made at the moment only by pktgen (kernel threads on
 dev_queue_xmit level contending with softirqs essentially). I think
 (although havent tried) the spin_{un}lock_bh() wont work. Thoughts?

If bh's are already disabled when you call this, it'll be ok, but as this 
will be a generally exported function, I'd suggest using bh locking.  I 
guess you could also make a xfrm_stateonly_find_bh() to be called only 
with bh's disabled, if needed.


- James
-- 
James Morris
[EMAIL PROTECTED]

-- 
VGER BF report: U 0.523211
-
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