All of lore.kernel.org
 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 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.