[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170629131758.GE9307@breakpoint.cc>
Date: Thu, 29 Jun 2017 15:17:58 +0200
From: Florian Westphal <fw@...len.de>
To: Ilan Tayari <ilant@...lanox.com>
Cc: Florian Westphal <fw@...len.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Yossi Kuperman <yossiku@...lanox.com>,
Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache
Ilan Tayari <ilant@...lanox.com> wrote:
> > -----Original Message-----
> > From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> > Subject: [RFC net-next 9/9] xfrm: add a small xdst pcpu cache
> >
> > retain last used xfrm_dst in a pcpu cache.
> > On next request, reuse this dst if the policies are the same.
> >
> > UDP tests used 64byte packets, tests ran for one minute each,
> > value is average over ten iterations.
>
> Hi Florian,
>
> I want to give this a go with hw-offload and see the impact on performance.
> It may take us a few days to do that.
Sure, take your time, thanks for testing!
> > +void xfrm_policy_dev_unreg(void)
>
> Maybe name it xfrm_policy_cache_flush() or something similar, and call it from some places where xfrm_garbage_collect() used to be called?
>
> Such as from xfrm_policy_flush()
> And maybe even from xfrm_flush_sa() as well
>
> This would allow to unload esp4 and/or esp4_offload (or other algo module) after 'ip x s f' (or the swan equivalent)
Good point. I did not consider module unload just device removal.
Powered by blists - more mailing lists