From: Fan Du <fan.du@windriver.com>
To: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Timo Teras <timo.teras@iki.fi>,
Eric Dumazet <eric.dumazet@gmail.com>, <davem@davemloft.net>,
<netdev@vger.kernel.org>
Subject: Re: [PATCHv4 net-next] xfrm: Namespacify xfrm_policy_sk_bundles
Date: Fri, 10 Jan 2014 17:23:40 +0800 [thread overview]
Message-ID: <52CFBC1C.7010809@windriver.com> (raw)
In-Reply-To: <20140109123803.GZ31491@secunet.com>
On 2014年01月09日 20:38, Steffen Klassert wrote:
> On Tue, Jan 07, 2014 at 10:43:38AM +0800, Fan Du wrote:
>> >
>> > Yes, I tested sk policy with udp, when transmit, dst will be cached into sk
>> > by sk_dst_set. Let's leave current implementation as it is.
>> >
>> > Please kindly review if there is any concern about v4.
> Why do you want to keep the current implementation? We don't
> use the cached bundles. I'd remove this caching with the patch
> below during the next development cycle if nobody has a good
> reason why we should keep it.
>
>
> Subject: [PATCH RFC] xfrm: Remove caching of xfrm_policy_sk_bundles
>
> We currently cache socket policy bundles at xfrm_policy_sk_bundles.
> These cached bundles are never used. Instead we create and cache
> a new one whenever xfrm_lookup() is called on a socket policy.
>
> Most protocols cache the used routes to the socket, so let's
> remove the unused caching of socket policy bundles in xfrm.
Honestly speaking, I cannot think of any other obvious reason
to retain sk bundle cache for what I know about XFRM so far, though
this mysterious ancient code still puzzles me.
Acked-by: Fan Du <fan.du@windriver.com>
> Signed-off-by: Steffen Klassert<steffen.klassert@secunet.com>
--
浮沉随浪只记今朝笑
--fan
next prev parent reply other threads:[~2014-01-10 9:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 3:34 [PATCHv2 ipsec-next] xfrm: Namespacify xfrm_policy_sk_bundles Fan Du
2013-12-18 4:50 ` Eric Dumazet
2013-12-18 5:33 ` Fan Du
2013-12-18 5:44 ` Eric Dumazet
2013-12-18 5:33 ` Cong Wang
2013-12-19 1:35 ` Fan Du
2013-12-19 2:15 ` Eric Dumazet
2013-12-19 3:17 ` [PATCHv3 net-next] " Fan Du
2013-12-19 3:44 ` Eric Dumazet
2013-12-19 7:47 ` Fan Du
2013-12-20 3:34 ` [PATCHv4 " Fan Du
2013-12-24 1:12 ` Fan Du
2013-12-24 5:31 ` David Miller
2013-12-24 5:39 ` Fan Du
2013-12-24 9:50 ` Steffen Klassert
2013-12-24 9:56 ` Fan Du
2013-12-24 17:54 ` David Miller
2013-12-24 10:35 ` Steffen Klassert
2013-12-25 6:40 ` Fan Du
2013-12-25 8:11 ` Timo Teras
2013-12-25 8:44 ` Fan Du
2014-01-06 10:35 ` Steffen Klassert
2014-01-07 2:43 ` Fan Du
2014-01-09 12:38 ` Steffen Klassert
2014-01-10 9:23 ` Fan Du [this message]
2013-12-19 3:48 ` [PATCHv3 " Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CFBC1C.7010809@windriver.com \
--to=fan.du@windriver.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=timo.teras@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.