Hi,
I tested IPSec(tunnel mode) routing performance between 2 GbE ports using packet generator(SMARTBIT) on ARM 500MHz with latest OCF patched on Openswan2.4.9 and I noticed the callback functions are using workqueue.
Since RX was performed in NAPI mode with higher priority then TX (in workqueue), the callback function(in ipsec_ocf.c) was starved with zero routing.
The problem was solved after I switched to use tasklet instead of the workqueue.
Is there a room for updating next OCF release ?
Please advice.
Thanks,
Eran Ben-Avi
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
--- openswan-2.4.9/linux/net/ipsec/ipsec_ocf.c 2007-08-30 10:29:39.000000000 -0200
+++ openswan-2.4.9_last/linux/net/ipsec/ipsec_ocf.c 2007-08-30 10:39:42.000000000 -0200
@@ -53,10 +53,10 @@
* Tuning parameters, the settings below appear best for
* the IXP
*/
-#define USE_BATCH 1 /* enable batch mode */
-#define USE_CBIMM 1 /* enable immediate callbacks */
-#define FORCE_QS 0 /* force use of queues for continuation of state machine */
-
+#define USE_BATCH 1 /* enable batch mode */
+#define USE_CBIMM 1 /* enable immediate callbacks */
+#define FORCE_QS 0 /* force use of queues for continuation of state machine */
+#define USE_TASKLET 1 /* force use of tasklet for continuation of state machine */
/*
* Because some OCF operations are synchronous (ie., software encryption)
* we need to protect ourselves from distructive re-entry. All we do
@@ -83,7 +83,11 @@
(*sm)(arg); \
})
-#if FORCE_QS == 0
+#if USE_TASKLET == 1
+ #define PROCESS_NEXT(tskl, sm, arg) \
+ tasklet_init(&tskl,(void (*)(unsigned long)) sm, (unsigned long)arg);\
+ tasklet_schedule(&tskl);
+#elif FORCE_QS == 0
#define PROCESS_NEXT(wq, wqsm, sm, arg) \
if (in_interrupt()) { \
PROCESS_LATER(wq, wqsm, arg); \
@@ -218,6 +222,7 @@
return 1;
}
+#if USE_TASKLET == 0
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
static void
ipsec_rsm_wq(struct work_struct *work)
@@ -228,6 +233,7 @@
#else
#define ipsec_rsm_wq ipsec_rsm
#endif
+#endif /* USE_TASKLET */
static int
ipsec_ocf_rcv_cb(struct cryptop *crp)
@@ -235,7 +241,6 @@
struct ipsec_rcv_state *irs = (struct ipsec_rcv_state *)crp->crp_opaque;
KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");
-
if (irs == NULL) {
KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb: "
"NULL irs in callback\n");
@@ -273,7 +278,11 @@
crp = NULL;
/* setup the rest of the processing now */
+#if USE_TASKLET == 1
+ PROCESS_NEXT(irs->tasklet, ipsec_rsm, irs);
+#else
PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm, irs);
+#endif
return 0;
}
@@ -396,6 +405,7 @@
return(IPSEC_RCV_PENDING);
}
+#if USE_TASKLET == 0
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
static void
ipsec_xsm_wq(struct work_struct *work)
@@ -406,6 +416,7 @@
#else
#define ipsec_xsm_wq ipsec_xsm
#endif
+#endif /* USE_TASKLET */
static int
ipsec_ocf_xmit_cb(struct cryptop *crp)
@@ -445,7 +456,11 @@
crp = NULL;
/* setup the rest of the processing now */
+#if USE_TASKLET == 1
+ PROCESS_NEXT(ixs->tasklet, ipsec_xsm, ixs);
+#else
PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);
+#endif
return 0;
}
Jivin Eran Ben-Avi lays it down ...
>
> --- David McCullough
> <[email protected]> wrote:
>
> >
> >
> >
> > Jivin Eran Ben-Avi lays it down ...
> > > Hi,
> > >
> > > I tested IPSec(tunnel mode) routing performance
> > between 2 GbE ports using packet generator(SMARTBIT)
> > on ARM 500MHz with latest OCF patched on
> > Openswan2.4.9 and I noticed the callback functions
> > are using workqueue.
> > > Since RX was performed in NAPI mode with higher
> > priority then TX (in workqueue), the callback
> > function(in ipsec_ocf.c) was starved with zero
> > routing.
> > > The problem was solved after I switched to use
> > tasklet instead of the workqueue.
> > > Is there a room for updating next OCF release ?
> >
> > Sure, send in a patch. This is against
> > ocf-linux-20070727 right ?
>
> Yes.
> Can you please estimate when next release will be
> ready?
When there is a need, I can turn it around in a day or so.
I could also post a patch that is current much more quickly
if you would prefer ?
Cheers,
Davidm
--
David McCullough, [email protected], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
We can also do direct function call of ipsec_xsm or ipsec_rsm instead of using tasklet.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Eran Ben-Avi
Sent: Thursday, August 30, 2007 2:58 AM
To: David McCullough
Cc: [email protected]
Subject: Re: Openswan 2.4.9 - tasklet or workqueue ?
--- David McCullough
<[email protected]> wrote:
>
>
>
> Jivin Eran Ben-Avi lays it down ...
> > Hi,
> >
> > I tested IPSec(tunnel mode) routing performance
> between 2 GbE ports using packet generator(SMARTBIT) on ARM 500MHz
> with latest OCF patched on
> Openswan2.4.9 and I noticed the callback functions are using
> workqueue.
> > Since RX was performed in NAPI mode with higher
> priority then TX (in workqueue), the callback function(in ipsec_ocf.c)
> was starved with zero routing.
> > The problem was solved after I switched to use
> tasklet instead of the workqueue.
> > Is there a room for updating next OCF release ?
>
> Sure, send in a patch. This is against
> ocf-linux-20070727 right ?
Yes.
Can you please estimate when next release will be ready?
Thanks.
>
> Cheers,
> Davidm
>
> --
> David McCullough,
> [email protected], Ph:+61
> 734352815
> Secure Computing - SnapGear http://www.uCdot.org
> http://www.cyberguard.com
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-crypto" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
____________________________________________________________________________________
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
Jivin Kabir Ahsan-r9aahw lays it down ...
> We can also do direct function call of ipsec_xsm or ipsec_rsm instead
> of using tasklet.
Care to come up with something that still works for 2.4 but it targetted
more at 2.6 ? I wasn't all the happy with the double function thing
going on there,
Cheers,
Davidm
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Eran Ben-Avi
> Sent: Thursday, August 30, 2007 2:58 AM
> To: David McCullough
> Cc: [email protected]
> Subject: Re: Openswan 2.4.9 - tasklet or workqueue ?
>
>
> --- David McCullough
> <[email protected]> wrote:
>
> >
> >
> >
> > Jivin Eran Ben-Avi lays it down ...
> > > Hi,
> > >
> > > I tested IPSec(tunnel mode) routing performance
> > between 2 GbE ports using packet generator(SMARTBIT) on ARM 500MHz
> > with latest OCF patched on
> > Openswan2.4.9 and I noticed the callback functions are using
> > workqueue.
> > > Since RX was performed in NAPI mode with higher
> > priority then TX (in workqueue), the callback function(in ipsec_ocf.c)
> > was starved with zero routing.
> > > The problem was solved after I switched to use
> > tasklet instead of the workqueue.
> > > Is there a room for updating next OCF release ?
> >
> > Sure, send in a patch. This is against
> > ocf-linux-20070727 right ?
> Yes.
> Can you please estimate when next release will be ready?
>
> Thanks.
>
> >
> > Cheers,
> > Davidm
> >
> > --
> > David McCullough,
> > [email protected], Ph:+61
> > 734352815
> > Secure Computing - SnapGear http://www.uCdot.org
> > http://www.cyberguard.com
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-crypto" in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
>
>
> ____________________________________________________________________________________
> Got a little couch potato?
> Check out fun summer activities for kids.
> http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
>
--
David McCullough, [email protected], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
Jivin Eran Ben-Avi lays it down ...
> > Jivin Eran Ben-Avi lays it down ...
> > > Hi,
> > >
> > > I tested IPSec(tunnel mode) routing performance
> > between 2 GbE ports using packet generator(SMARTBIT)
> > on ARM 500MHz with latest OCF patched on
> > Openswan2.4.9 and I noticed the callback functions
> > are using workqueue.
> > > Since RX was performed in NAPI mode with higher
> > priority then TX (in workqueue), the callback
> > function(in ipsec_ocf.c) was starved with zero
> > routing.
> > > The problem was solved after I switched to use
> > tasklet instead of the workqueue.
> > > Is there a room for updating next OCF release ?
> >
> > Sure, send in a patch. This is against
> > ocf-linux-20070727 right ?
> Yes.
> Can you please estimate when next release will be
> ready?
I can probably do one in about a week (offline next week). I could more
easily drop a diff since the last release if that helps you out.
I have made a few small changes to your patch so it should be safe on
2.4 systems yet still select tasklets on 2.6 automatically.
Could you have a look at it ? I have done some basic testing here
and it seems ok, haven't checked your performance increases yet ;-)
Thanks,
Davidm
--
David McCullough, [email protected], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
----- Original Message ----
> From: David McCullough <[email protected]>
> To: Eran Ben-Avi <[email protected]>
> Cc: [email protected]; [email protected]
> Sent: Wednesday, September 26, 2007 12:26:10 PM
> Subject: Re: Openswan 2.4.9 - tasklet or workqueue ?
>
>
> Jivin Eran Ben-Avi lays it down ...
> > > Jivin Eran Ben-Avi lays it down ...
> > > > Hi,
> > > >
> > > > I tested IPSec(tunnel mode) routing performance
> > > between 2 GbE ports using packet generator(SMARTBIT)
> > > on ARM 500MHz with latest OCF patched on
> > > Openswan2.4.9 and I noticed the callback functions
> > > are using workqueue.
> > > > Since RX was performed in NAPI mode with higher
> > > priority then TX (in workqueue), the callback
> > > function(in ipsec_ocf.c) was starved with zero
> > > routing.
> > > > The problem was solved after I switched to use
> > > tasklet instead of the workqueue.
> > > > Is there a room for updating next OCF release ?
> > >
> > > Sure, send in a patch. This is against
> > > ocf-linux-20070727 right ?
> > Yes.
> > Can you please estimate when next release will be
> > ready?
>
> I can probably do one in about a week (offline next week). I could more
> easily drop a diff since the last release if that helps you out.
>
> I have made a few small changes to your patch so it should be safe on
> 2.4 systems yet still select tasklets on 2.6 automatically.
>
> Could you have a look at it ? I have done some basic testing here
> and it seems ok, haven't checked your performance increases yet ;-)
>
Sorry for the late response.
It seems to be ok. I will test it more intensely in the next few days.
Thanks.
> Thanks,
> Davidm
>
> --
> David McCullough, [email protected],
> Ph:+61
>
734352815
> Secure Computing - SnapGear
> http://www.uCdot.org
>
http://www.cyberguard.com
>
>
> -----Inline Attachment Follows-----
>
> Index: openswan/linux/include/openswan/ipsec_rcv.h
> ===================================================================
> RCS file: openswan/linux/include/openswan/ipsec_rcv.h,v
> retrieving revision 1.13
> diff -u -r1.13 ipsec_rcv.h
> --- openswan/linux/include/openswan/ipsec_rcv.h 26 Jun 2007
> 06:28:52
>
-0000 1.13
> +++ openswan/linux/include/openswan/ipsec_rcv.h 26 Sep 2007
> 14:17:25
>
-0000
> @@ -149,6 +149,9 @@
>
> #ifdef CONFIG_KLIPS_OCF
> struct work_struct workq;
> +#ifdef DECLARE_TASKLET
> + struct tasklet_struct tasklet;
> +#endif
> #endif
> #ifndef NET_21
> struct net_device *devp;
> Index: openswan/linux/include/openswan/ipsec_xmit.h
> ===================================================================
> RCS file: openswan/linux/include/openswan/ipsec_xmit.h,v
> retrieving revision 1.9
> diff -u -r1.9 ipsec_xmit.h
> --- openswan/linux/include/openswan/ipsec_xmit.h 26 Jun
> 2007
>
05:26:25 -0000 1.9
> +++ openswan/linux/include/openswan/ipsec_xmit.h 26 Sep
> 2007
>
14:17:25 -0000
> @@ -140,6 +140,9 @@
> int next_state;
> #ifdef CONFIG_KLIPS_OCF
> struct work_struct workq;
> +#ifdef DECLARE_TASKLET
> + struct tasklet_struct tasklet;
> +#endif
> #endif
> #ifdef CONFIG_KLIPS_ALG
> struct ipsec_alg_auth *ixt_a;
> Index: openswan/linux/net/ipsec/ipsec_ocf.c
> ===================================================================
> RCS file: openswan/linux/net/ipsec/ipsec_ocf.c,v
> retrieving revision 1.27
> diff -u -r1.27 ipsec_ocf.c
> --- openswan/linux/net/ipsec/ipsec_ocf.c 11 Jul 2007 00:35:01
> -0000
>
1.27
> +++ openswan/linux/net/ipsec/ipsec_ocf.c 26 Sep 2007 14:17:25 -0000
> @@ -56,7 +56,11 @@
> #define USE_BATCH 1 /* enable batch mode */
> #define USE_CBIMM 1 /* enable immediate callbacks */
> #define FORCE_QS 0 /* force use of queues for continuation
> of
>
state machine */
> -
> +#ifdef DECLARE_TASKLET
> +#define USE_TASKLET 1 /* use tasklet for continuation of
> state
>
machine */
> +#else
> +#define USE_TASKLET 0 /* don't use tasklet for continuation of
> state
>
machine */
> +#endif
> /*
> * Because some OCF operations are synchronous (ie.,
> software
>
encryption)
> * we need to protect ourselves from distructive re-entry. All we do
> @@ -83,15 +87,21 @@
> (*sm)(arg); \
> })
>
> -#if FORCE_QS == 0
> - #define PROCESS_NEXT(wq, wqsm, sm, arg) \
> +#if USE_TASKLET == 1
> + #define PROCESS_NEXT(this, wqsm, sm) ({ \
> + tasklet_init(&this->tasklet, \
> + (void (*)(unsigned long)) sm, (unsigned long)this); \
> + tasklet_schedule(&this->tasklet); \
> + })
> +#elif FORCE_QS == 0
> + #define PROCESS_NEXT(this, wqsm, sm) \
> if (in_interrupt()) { \
> - PROCESS_LATER(wq, wqsm, arg); \
> + PROCESS_LATER(this->workq, wqsm, this); \
> } else { \
> - PROCESS_NOW(sm, arg); \
> + PROCESS_NOW(sm, this); \
> }
> #else
> - #define PROCESS_NEXT(wq, wqsm, sm, arg) PROCESS_LATER(wq,
> wqsm,
>
arg)
> + #define PROCESS_NEXT(this, wqsm, sm)
> PROCESS_LATER(this->workq,
>
wqsm, this)
> #endif
>
> /*
> @@ -218,6 +228,7 @@
> return 1;
> }
>
> +#if USE_TASKLET == 0
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> static void
> ipsec_rsm_wq(struct work_struct *work)
> @@ -228,6 +239,7 @@
> #else
> #define ipsec_rsm_wq ipsec_rsm
> #endif
> +#endif /* USE_TASKLET */
>
> static int
> ipsec_ocf_rcv_cb(struct cryptop *crp)
> @@ -235,7 +247,6 @@
> struct ipsec_rcv_state *irs = (struct
> ipsec_rcv_state
>
*)crp->crp_opaque;
>
> KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");
> -
> if (irs == NULL) {
> KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb: "
> "NULL irs in callback\n");
> @@ -273,7 +284,7 @@
> crp = NULL;
>
> /* setup the rest of the processing now */
> - PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm, irs);
> + PROCESS_NEXT(irs, ipsec_rsm_wq, ipsec_rsm);
> return 0;
> }
>
> @@ -396,6 +407,7 @@
> return(IPSEC_RCV_PENDING);
> }
>
> +#if USE_TASKLET == 0
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> static void
> ipsec_xsm_wq(struct work_struct *work)
> @@ -406,6 +418,7 @@
> #else
> #define ipsec_xsm_wq ipsec_xsm
> #endif
> +#endif /* USE_TASKLET */
>
> static int
> ipsec_ocf_xmit_cb(struct cryptop *crp)
> @@ -445,7 +458,7 @@
> crp = NULL;
>
> /* setup the rest of the processing now */
> - PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);
> + PROCESS_NEXT(ixs, ipsec_xsm_wq, ipsec_xsm);
> return 0;
> }
>
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Jivin Eran Ben-Avi lays it down ...
...
> > I have made a few small changes to your patch so it should be safe on
> > 2.4 systems yet still select tasklets on 2.6 automatically.
> >
> > Could you have a look at it ? I have done some basic testing here
> > and it seems ok, haven't checked your performance increases yet ;-)
> >
> Sorry for the late response.
> It seems to be ok. I will test it more intensely in the next few days.
No problems, I have it sitting there ready to go :-)
Cheers,
Davidm
> > -----Inline Attachment Follows-----
> >
> > Index: openswan/linux/include/openswan/ipsec_rcv.h
> > ===================================================================
> > RCS file: openswan/linux/include/openswan/ipsec_rcv.h,v
> > retrieving revision 1.13
> > diff -u -r1.13 ipsec_rcv.h
> > --- openswan/linux/include/openswan/ipsec_rcv.h 26 Jun 2007
> > 06:28:52
> >
> -0000 1.13
> > +++ openswan/linux/include/openswan/ipsec_rcv.h 26 Sep 2007
> > 14:17:25
> >
> -0000
> > @@ -149,6 +149,9 @@
> >
> > #ifdef CONFIG_KLIPS_OCF
> > struct work_struct workq;
> > +#ifdef DECLARE_TASKLET
> > + struct tasklet_struct tasklet;
> > +#endif
> > #endif
> > #ifndef NET_21
> > struct net_device *devp;
> > Index: openswan/linux/include/openswan/ipsec_xmit.h
> > ===================================================================
> > RCS file: openswan/linux/include/openswan/ipsec_xmit.h,v
> > retrieving revision 1.9
> > diff -u -r1.9 ipsec_xmit.h
> > --- openswan/linux/include/openswan/ipsec_xmit.h 26 Jun
> > 2007
> >
> 05:26:25 -0000 1.9
> > +++ openswan/linux/include/openswan/ipsec_xmit.h 26 Sep
> > 2007
> >
> 14:17:25 -0000
> > @@ -140,6 +140,9 @@
> > int next_state;
> > #ifdef CONFIG_KLIPS_OCF
> > struct work_struct workq;
> > +#ifdef DECLARE_TASKLET
> > + struct tasklet_struct tasklet;
> > +#endif
> > #endif
> > #ifdef CONFIG_KLIPS_ALG
> > struct ipsec_alg_auth *ixt_a;
> > Index: openswan/linux/net/ipsec/ipsec_ocf.c
> > ===================================================================
> > RCS file: openswan/linux/net/ipsec/ipsec_ocf.c,v
> > retrieving revision 1.27
> > diff -u -r1.27 ipsec_ocf.c
> > --- openswan/linux/net/ipsec/ipsec_ocf.c 11 Jul 2007 00:35:01
> > -0000
> >
> 1.27
> > +++ openswan/linux/net/ipsec/ipsec_ocf.c 26 Sep 2007 14:17:25 -0000
> > @@ -56,7 +56,11 @@
> > #define USE_BATCH 1 /* enable batch mode */
> > #define USE_CBIMM 1 /* enable immediate callbacks */
> > #define FORCE_QS 0 /* force use of queues for continuation
> > of
> >
> state machine */
> > -
> > +#ifdef DECLARE_TASKLET
> > +#define USE_TASKLET 1 /* use tasklet for continuation of
> > state
> >
> machine */
> > +#else
> > +#define USE_TASKLET 0 /* don't use tasklet for continuation of
> > state
> >
> machine */
> > +#endif
> > /*
> > * Because some OCF operations are synchronous (ie.,
> > software
> >
> encryption)
> > * we need to protect ourselves from distructive re-entry. All we do
> > @@ -83,15 +87,21 @@
> > (*sm)(arg); \
> > })
> >
> > -#if FORCE_QS == 0
> > - #define PROCESS_NEXT(wq, wqsm, sm, arg) \
> > +#if USE_TASKLET == 1
> > + #define PROCESS_NEXT(this, wqsm, sm) ({ \
> > + tasklet_init(&this->tasklet, \
> > + (void (*)(unsigned long)) sm, (unsigned long)this); \
> > + tasklet_schedule(&this->tasklet); \
> > + })
> > +#elif FORCE_QS == 0
> > + #define PROCESS_NEXT(this, wqsm, sm) \
> > if (in_interrupt()) { \
> > - PROCESS_LATER(wq, wqsm, arg); \
> > + PROCESS_LATER(this->workq, wqsm, this); \
> > } else { \
> > - PROCESS_NOW(sm, arg); \
> > + PROCESS_NOW(sm, this); \
> > }
> > #else
> > - #define PROCESS_NEXT(wq, wqsm, sm, arg) PROCESS_LATER(wq,
> > wqsm,
> >
> arg)
> > + #define PROCESS_NEXT(this, wqsm, sm)
> > PROCESS_LATER(this->workq,
> >
> wqsm, this)
> > #endif
> >
> > /*
> > @@ -218,6 +228,7 @@
> > return 1;
> > }
> >
> > +#if USE_TASKLET == 0
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> > static void
> > ipsec_rsm_wq(struct work_struct *work)
> > @@ -228,6 +239,7 @@
> > #else
> > #define ipsec_rsm_wq ipsec_rsm
> > #endif
> > +#endif /* USE_TASKLET */
> >
> > static int
> > ipsec_ocf_rcv_cb(struct cryptop *crp)
> > @@ -235,7 +247,6 @@
> > struct ipsec_rcv_state *irs = (struct
> > ipsec_rcv_state
> >
> *)crp->crp_opaque;
> >
> > KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");
> > -
> > if (irs == NULL) {
> > KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb: "
> > "NULL irs in callback\n");
> > @@ -273,7 +284,7 @@
> > crp = NULL;
> >
> > /* setup the rest of the processing now */
> > - PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm, irs);
> > + PROCESS_NEXT(irs, ipsec_rsm_wq, ipsec_rsm);
> > return 0;
> > }
> >
> > @@ -396,6 +407,7 @@
> > return(IPSEC_RCV_PENDING);
> > }
> >
> > +#if USE_TASKLET == 0
> > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,20)
> > static void
> > ipsec_xsm_wq(struct work_struct *work)
> > @@ -406,6 +418,7 @@
> > #else
> > #define ipsec_xsm_wq ipsec_xsm
> > #endif
> > +#endif /* USE_TASKLET */
> >
> > static int
> > ipsec_ocf_xmit_cb(struct cryptop *crp)
> > @@ -445,7 +458,7 @@
> > crp = NULL;
> >
> > /* setup the rest of the processing now */
> > - PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);
> > + PROCESS_NEXT(ixs, ipsec_xsm_wq, ipsec_xsm);
> > return 0;
> > }
> >
> >
> >
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
David McCullough, [email protected], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com