From: Fan Du <firstname.lastname@example.org>
To: David Miller <email@example.com>
Cc: <firstname.lastname@example.org>, <email@example.com>
Subject: Re: [DISCUSSION] rt6i_genid
Date: Fri, 19 Jul 2013 15:50:20 +0800 [thread overview]
Message-ID: <51E8EFBC.firstname.lastname@example.org> (raw)
On 2013年07月19日 11:31, David Miller wrote:
> From: Fan Du<email@example.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
> 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?
next prev parent 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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).