netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fan Du <fan.du@windriver.com>
To: David Miller <davem@davemloft.net>
Cc: <nicolas.dichtel@6wind.com>, <netdev@vger.kernel.org>
Subject: Re: [DISCUSSION] rt6i_genid
Date: Fri, 19 Jul 2013 15:50:20 +0800	[thread overview]
Message-ID: <51E8EFBC.6040902@windriver.com> (raw)
In-Reply-To: <20130718.203100.1960741588589171145.davem@davemloft.net>



On 2013年07月19日 11:31, David Miller wrote:
> From: Fan Du<fan.du@windriver.com>
> Date: Fri, 19 Jul 2013 11:28:51 +0800
>
>> On 2013年07月19日 11:18, David Miller wrote:
>>> Although it's a correct change, it is of almost no value.  %99.9999999
>>> of users will be running kernels with CONFIG_XFRM enabled.
>>
>> Thanks. Good to know %99.99999999 users protect their networking with
>> IPsec.
>
> That is not what I said.
>
> I said that nearly every user will be running a kernel with that
> config option enabled, I did not say that they will actually be
> using IPSEC.
>
> Distributions enable all options, so that users may use any facility
> that they want.
>
> So optimizing for things like this are almost pointless.
>

I've understood the situation/point you're trying to describe.
No problem, I will drop this almost-pointless patch :)

The original commit is targeted for XFRM policy inserting/removing,
but it uses net genid shared by both IPv4 and IPv6, the side effect is
add/delete IPv4 address will invalidate IPv6 dst in all.

We *do* need to bump genid when add/delete IPv6 address in scenario I
described here: http://www.spinics.net/lists/netdev/msg243398.html,
but definitely not from add/delete IPv4 address. Moreover test shows
that DCCP still push thousands of packets on wire after delete its IPv6
address in the same scenario I describe before.

The impulse to bump genid for IPv6 is much more stronger after this
commit even do it unintentionally.

So am I missing some thing more important inside IPv6, Dave?

-- 
浮沉随浪只记今朝笑

--fan

  reply	other threads:[~2013-07-19  7:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18  3:22 [DISCUSSION] rt6i_genid Fan Du
2013-07-18  9:13 ` Nicolas Dichtel
2013-07-18  9:28   ` Fan Du
2013-07-18 15:12     ` Nicolas Dichtel
2013-07-19  0:01       ` Fan Du
2013-07-19  3:18         ` David Miller
2013-07-19  3:28           ` Fan Du
2013-07-19  3:31             ` David Miller
2013-07-19  7:50               ` Fan Du [this message]
2013-07-19  9:33                 ` David Miller
2013-07-22  5:43                   ` [RFC PATCH net-next] net: split rt_genid for ipv4 and ipv6 Fan Du
2013-07-22 10:53                     ` Steffen Klassert
2013-07-22 20:40                     ` Nicolas Dichtel

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=51E8EFBC.6040902@windriver.com \
    --to=fan.du@windriver.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).