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
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
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?
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
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
Against net-2.6.19
signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
cheers,
jamal
Allow for searching the SAD from external data path points without
assumming L3 details. The only customer of this exposure currently
is pktgen.
---
commit 33d3060784e6aa55e30ae7d5efc491180e7f955d
tree
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,
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
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
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
10 matches
Mail list logo
