Thread: Re: [Ocf-linux-users] Openswan 2.4.9 - tasklet or workqueue ?
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users
|
From: David M. <Dav...@se...> - 2007-08-30 22:39:49
|
Jivin Eran Ben-Avi lays it down ... > > --- David McCullough > <Dav...@se...> 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, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-09-12 12:07:33
|
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: lin...@vg... [mailto:lin...@vg...] On Behalf Of Eran Ben-Avi > Sent: Thursday, August 30, 2007 2:58 AM > To: David McCullough > Cc: lin...@vg... > Subject: Re: Openswan 2.4.9 - tasklet or workqueue ? > > > --- David McCullough > <Dav...@se...> 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, > > dav...@se..., 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 maj...@vg... > > 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, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: David M. <Dav...@se...> - 2007-09-26 14:25:09
Attachments:
tasklet.diff
|
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, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com |
|
From: Eran Ben-A. <era...@ya...> - 2007-11-01 14:34:04
|
=0A=0A----- Original Message ----=0A> From: David McCullough <David_Mccullo= ug...@se...>=0A> To: Eran Ben-Avi <era...@ya...>=0A> Cc= : lin...@vg...; ocf...@li...=0A> S= ent: Wednesday, September 26, 2007 12:26:10 PM=0A> Subject: Re: Openswan 2.= 4.9 - tasklet or workqueue ?=0A> =0A> =0A> Jivin Eran Ben-Avi lays it down = ...=0A> > > Jivin Eran Ben-Avi lays it down ...=0A> > > > Hi,=0A> > > > =0A= > > > > I tested IPSec(tunnel mode) routing performance=0A> > > between 2 G= bE ports using packet generator(SMARTBIT)=0A> > > on ARM 500MHz with lates= t OCF patched on=0A> > > Openswan2.4.9 and I noticed the callback functions= =0A> > > are using workqueue.=0A> > > > Since RX was performed in NAPI mode= with higher=0A> > > priority then TX (in workqueue), the callback=0A> > > = function(in ipsec_ocf.c) was starved with zero=0A> > > routing.=0A> > > > T= he problem was solved after I switched to use=0A> > > tasklet instead of th= e workqueue.=0A> > > > Is there a room for updating next OCF release ?=0A> = > > =0A> > > Sure, send in a patch. This is against=0A> > > ocf-linux-2007= 0727 right ?=0A> > Yes.=0A> > Can you please estimate when next release wil= l be=0A> > ready?=0A> =0A> I can probably do one in about a week (offline n= ext week). I could more=0A> easily drop a diff since the last release if th= at helps you out.=0A> =0A> I have made a few small changes to your patch so= it should be safe on=0A> 2.4 systems yet still select tasklets on 2.6 auto= matically.=0A> =0A> Could you have a look at it ? I have done some basic t= esting here=0A> and it seems ok, haven't checked your performance increase= s yet ;-)=0A> =0ASorry for the late response.=0AIt seems to be ok. I will t= est it more intensely in the next few days.=0AThanks.=0A=0A> Thanks,=0A> Da= vidm=0A> =0A> -- =0A> David McCullough, david_mccullough@securecomputing.c= om, =0A> Ph:+61=0A> =0A 734352815=0A> Secure Computing - SnapGear =0A> htt= p://www.uCdot.org=0A> =0A http://www.cyberguard.com=0A> =0A> =0A> -----Inli= ne Attachment Follows-----=0A> =0A> Index: openswan/linux/include/openswan/= ipsec_rcv.h=0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> R= CS file: openswan/linux/include/openswan/ipsec_rcv.h,v=0A> retrieving revis= ion 1.13=0A> diff -u -r1.13 ipsec_rcv.h=0A> --- openswan/linux/include/open= swan/ipsec_rcv.h 26 Jun 2007=0A> 06:28:52=0A> =0A -0000 1.13=0A> +++ = openswan/linux/include/openswan/ipsec_rcv.h 26 Sep 2007=0A> 14:17:25=0A>= =0A -0000=0A> @@ -149,6 +149,9 @@=0A> =0A> #ifdef CONFIG_KLIPS_OCF=0A> = struct work_struct workq;=0A> +#ifdef DECLARE_TASKLET=0A> + struc= t tasklet_struct tasklet;=0A> +#endif=0A> #endif=0A> #ifndef NET_21=0A= > struct net_device *devp;=0A> Index: openswan/linux/include/openswan/= ipsec_xmit.h=0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> R= CS file: openswan/linux/include/openswan/ipsec_xmit.h,v=0A> retrieving revi= sion 1.9=0A> diff -u -r1.9 ipsec_xmit.h=0A> --- openswan/linux/include/open= swan/ipsec_xmit.h 26 Jun=0A> 2007=0A> =0A 05:26:25 -0000 1.9=0A> +++ = openswan/linux/include/openswan/ipsec_xmit.h 26 Sep=0A> 2007=0A> =0A 14:= 17:25 -0000=0A> @@ -140,6 +140,9 @@=0A> int next_state;=0A> #i= fdef CONFIG_KLIPS_OCF=0A> struct work_struct workq;=0A> +#ifdef DEC= LARE_TASKLET=0A> + struct tasklet_struct tasklet;=0A> +#endif=0A> #e= ndif=0A> #ifdef CONFIG_KLIPS_ALG=0A> struct ipsec_alg_auth *ixt_a;=0A= > Index: openswan/linux/net/ipsec/ipsec_ocf.c=0A> =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> RCS file: openswan/linux/net/ipsec/ipsec_oc= f.c,v=0A> retrieving revision 1.27=0A> diff -u -r1.27 ipsec_ocf.c=0A> --- o= penswan/linux/net/ipsec/ipsec_ocf.c 11 Jul 2007 00:35:01=0A> -0000=0A> = =0A 1.27=0A> +++ openswan/linux/net/ipsec/ipsec_ocf.c 26 Sep 2007 14:= 17:25 -0000=0A> @@ -56,7 +56,11 @@=0A> #define USE_BATCH 1 /* enable ba= tch mode */=0A> #define USE_CBIMM 1 /* enable immediate callbacks */=0A= > #define FORCE_QS 0 /* force use of queues for continuation=0A> of=0A= > =0A state machine */=0A> -=0A> +#ifdef DECLARE_TASKLET=0A> +#define USE_T= ASKLET 1 /* use tasklet for continuation of=0A> state=0A> =0A machine */= =0A> +#else=0A> +#define USE_TASKLET 0 /* don't use tasklet for continuati= on of=0A> state=0A> =0A machine */=0A> +#endif=0A> /*=0A> * Because some= OCF operations are synchronous (ie.,=0A> software=0A> =0A encryption)=0A> = * we need to protect ourselves from distructive re-entry. All we do=0A> = @@ -83,15 +87,21 @@=0A> (*sm)(arg); \=0A> })=0A> =0A> -#if F= ORCE_QS =3D=3D 0=0A> - #define PROCESS_NEXT(wq, wqsm, sm, arg) \=0A> +#i= f USE_TASKLET =3D=3D 1=0A> + #define PROCESS_NEXT(this, wqsm, sm) ({ \= =0A> + tasklet_init(&this->tasklet, \=0A> + (void (*)(uns= igned long)) sm, (unsigned long)this); \=0A> + tasklet_schedule(&thi= s->tasklet); \=0A> + })=0A> +#elif FORCE_QS =3D=3D 0=0A> + #defin= e PROCESS_NEXT(this, wqsm, sm) \=0A> if (in_interrupt()) { \=0A> -= PROCESS_LATER(wq, wqsm, arg); \=0A> + PROCESS_LATER(= this->workq, wqsm, this); \=0A> } else { \=0A> - PROCES= S_NOW(sm, arg); \=0A> + PROCESS_NOW(sm, this); \=0A> }= =0A> #else=0A> - #define PROCESS_NEXT(wq, wqsm, sm, arg) PROCESS_LATER(= wq,=0A> wqsm,=0A> =0A arg)=0A> + #define PROCESS_NEXT(this, wqsm, sm)=0A= > PROCESS_LATER(this->workq,=0A> =0A wqsm, this)=0A> #endif=0A> =0A> /*= =0A> @@ -218,6 +228,7 @@=0A> return 1;=0A> }=0A> =0A> +#if USE_TASKL= ET =3D=3D 0=0A> #if LINUX_VERSION_CODE >=3D KERNEL_VERSION(2,6,20)=0A> st= atic void=0A> ipsec_rsm_wq(struct work_struct *work)=0A> @@ -228,6 +239,7 = @@=0A> #else=0A> #define ipsec_rsm_wq ipsec_rsm=0A> #endif=0A> +#e= ndif /* USE_TASKLET */=0A> =0A> static int=0A> ipsec_ocf_rcv_cb(struct c= ryptop *crp)=0A> @@ -235,7 +247,6 @@=0A> struct ipsec_rcv_state *irs = =3D (struct=0A> ipsec_rcv_state=0A> =0A *)crp->crp_opaque;=0A> =0A> K= LIPS_PRINT(debug_rcv, "klips_debug:ipsec_ocf_rcv_cb\n");=0A> -=0A> if = (irs =3D=3D NULL) {=0A> KLIPS_PRINT(debug_rcv, "klips_debug:ipsec_= ocf_rcv_cb: "=0A> "NULL irs in callback\n");=0A> @@ -273,7= +284,7 @@=0A> crp =3D NULL;=0A> =0A> /* setup the rest of the p= rocessing now */=0A> - PROCESS_NEXT(irs->workq, ipsec_rsm_wq, ipsec_rsm,= irs);=0A> + PROCESS_NEXT(irs, ipsec_rsm_wq, ipsec_rsm);=0A> return= 0;=0A> }=0A> =0A> @@ -396,6 +407,7 @@=0A> return(IPSEC_RCV_PENDING)= ;=0A> }=0A> =0A> +#if USE_TASKLET =3D=3D 0=0A> #if LINUX_VERSION_CODE >= =3D KERNEL_VERSION(2,6,20)=0A> static void=0A> ipsec_xsm_wq(struct work_s= truct *work)=0A> @@ -406,6 +418,7 @@=0A> #else=0A> #define ipsec_xsm_w= q ipsec_xsm=0A> #endif=0A> +#endif /* USE_TASKLET */=0A> =0A> static = int=0A> ipsec_ocf_xmit_cb(struct cryptop *crp)=0A> @@ -445,7 +458,7 @@=0A>= crp =3D NULL;=0A> =0A> /* setup the rest of the processing now = */=0A> - PROCESS_NEXT(ixs->workq, ipsec_xsm_wq, ipsec_xsm, ixs);=0A> + = PROCESS_NEXT(ixs, ipsec_xsm_wq, ipsec_xsm);=0A> return 0;=0A> }=0A>= =0A> =0A> =0A=0A=0A=0A__________________________________________________= =0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protectio= n around =0Ahttp://mail.yahoo.com |
|
From: David M. <Dav...@se...> - 2007-11-05 03:34:45
|
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, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X