[PATCH] ipv6: remove the unnecessary statement in find_match()

[PATCH] ipv6: remove the unnecessary statement in find_match()

[Duan Jiong]

After reading the function rt6_check_neigh(), we can
know that the RT6_NUD_FAIL_SOFT can be returned only
when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
so in function find_match(), there is no need to execute
the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).

Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
 net/ipv6/route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f54e3a1..708685f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -619,7 +619,7 @@ static struct rt6_info *find_match(struct rt6_info *rt, int oif, int strict,
 		goto out;
 
 	m = rt6_score_route(rt, oif, strict);
-	if (m == RT6_NUD_FAIL_SOFT && !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF)) {
+	if (m == RT6_NUD_FAIL_SOFT) {
 		match_do_rr = true;
 		m = 0; /* lowest valid score */
 	} else if (m < 0) {
-- 
1.8.3.1

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Hannes Frederic Sowa]

On Wed, Oct 30, 2013 at 03:39:26PM +0800, Duan Jiong wrote:
> 
> After reading the function rt6_check_neigh(), we can
> know that the RT6_NUD_FAIL_SOFT can be returned only
> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
> so in function find_match(), there is no need to execute
> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).

It should be constant folded away. But I agree, we can remove this:

Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>

Thanks,

  Hannes

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[David Miller]

From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Wed, 30 Oct 2013 15:39:26 +0800

> 
> After reading the function rt6_check_neigh(), we can
> know that the RT6_NUD_FAIL_SOFT can be returned only
> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
> so in function find_match(), there is no need to execute
> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
> 
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>

Applied to net-next, thanks.

CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
removal.  I know we've had several bugs that only apply when
this option is on vs. off.  We're maintaining two different
code paths, for really no good reason.

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Hannes Frederic Sowa]

On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Wed, 30 Oct 2013 15:39:26 +0800
> 
> > 
> > After reading the function rt6_check_neigh(), we can
> > know that the RT6_NUD_FAIL_SOFT can be returned only
> > when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
> > so in function find_match(), there is no need to execute
> > the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
> > 
> > Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> 
> Applied to net-next, thanks.
> 
> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
> removal.  I know we've had several bugs that only apply when
> this option is on vs. off.  We're maintaining two different
> code paths, for really no good reason.

I agree and actually thought about that yesterday. Do you think a sysctl
is a good option?

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[David Miller]

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 30 Oct 2013 22:11:57 +0100

> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>> 
>> > 
>> > After reading the function rt6_check_neigh(), we can
>> > know that the RT6_NUD_FAIL_SOFT can be returned only
>> > when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>> > so in function find_match(), there is no need to execute
>> > the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>> > 
>> > Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> 
>> Applied to net-next, thanks.
>> 
>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>> removal.  I know we've had several bugs that only apply when
>> this option is on vs. off.  We're maintaining two different
>> code paths, for really no good reason.
> 
> I agree and actually thought about that yesterday. Do you think a sysctl
> is a good option?

Every distribution ships with the Kconfig option on, and no sysctl
exists currently to control it.

So I'd say it's not necessary at all, or at the very least let's have
someone come forward with a real rather than theoretical use case for
such a feature before adding it.

Actually, if RFC 4191 has the usual language like "there SHOULD be
an administrative mechanism to disable blah blah blah" I could
be convinced to add it now.  Can someone take a look?

Either way it'd probably be a per-inet6_dev option, right?

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Duan Jiong]

于 2013年10月31日 12:22, David Miller 写道:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 30 Oct 2013 22:11:57 +0100
> 
>> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>>>
>>>>
>>>> After reading the function rt6_check_neigh(), we can
>>>> know that the RT6_NUD_FAIL_SOFT can be returned only
>>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>>>> so in function find_match(), there is no need to execute
>>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>>>>
>>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> Applied to net-next, thanks.
>>>
>>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>>> removal.  I know we've had several bugs that only apply when
>>> this option is on vs. off.  We're maintaining two different
>>> code paths, for really no good reason.
>>
>> I agree and actually thought about that yesterday. Do you think a sysctl
>> is a good option?
> 
> Every distribution ships with the Kconfig option on, and no sysctl
> exists currently to control it.
> 
> So I'd say it's not necessary at all, or at the very least let's have
> someone come forward with a real rather than theoretical use case for
> such a feature before adding it.
> 
> Actually, if RFC 4191 has the usual language like "there SHOULD be
> an administrative mechanism to disable blah blah blah" I could
> be convinced to add it now.  Can someone take a look?

It seems that there is no such an administrative mechanism in RFC 4191.

By the way, if the sysctl is used, we are still maintaining two different
code paths, isn't it? so i think David's idea is good.

Thanks,
  Duan


> 
> Either way it'd probably be a per-inet6_dev option, right?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Hannes Frederic Sowa]

On Thu, Oct 31, 2013 at 02:02:11PM +0800, Duan Jiong wrote:
> 于 2013年10月31日 12:22, David Miller 写道:
> > From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> > Date: Wed, 30 Oct 2013 22:11:57 +0100
> > 
> >> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
> >>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>> Date: Wed, 30 Oct 2013 15:39:26 +0800
> >>>
> >>>>
> >>>> After reading the function rt6_check_neigh(), we can
> >>>> know that the RT6_NUD_FAIL_SOFT can be returned only
> >>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
> >>>> so in function find_match(), there is no need to execute
> >>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
> >>>>
> >>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>
> >>> Applied to net-next, thanks.
> >>>
> >>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
> >>> removal.  I know we've had several bugs that only apply when
> >>> this option is on vs. off.  We're maintaining two different
> >>> code paths, for really no good reason.
> >>
> >> I agree and actually thought about that yesterday. Do you think a sysctl
> >> is a good option?
> > 
> > Every distribution ships with the Kconfig option on, and no sysctl
> > exists currently to control it.
> > 
> > So I'd say it's not necessary at all, or at the very least let's have
> > someone come forward with a real rather than theoretical use case for
> > such a feature before adding it.
> > 
> > Actually, if RFC 4191 has the usual language like "there SHOULD be
> > an administrative mechanism to disable blah blah blah" I could
> > be convinced to add it now.  Can someone take a look?
> 
> It seems that there is no such an administrative mechanism in RFC 4191.
> 
> By the way, if the sysctl is used, we are still maintaining two different
> code paths, isn't it? so i think David's idea is good.

Makes life easier, no objections from me.

Greetings,

  Hannes

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Duan Jiong]

于 2013年10月31日 16:45, Hannes Frederic Sowa 写道:
> On Thu, Oct 31, 2013 at 02:02:11PM +0800, Duan Jiong wrote:
>> 于 2013年10月31日 12:22, David Miller 写道:
>>> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>> Date: Wed, 30 Oct 2013 22:11:57 +0100
>>>
>>>> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>>>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>>>>>
>>>>>>
>>>>>> After reading the function rt6_check_neigh(), we can
>>>>>> know that the RT6_NUD_FAIL_SOFT can be returned only
>>>>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>>>>>> so in function find_match(), there is no need to execute
>>>>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>>>>>>
>>>>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>>>
>>>>> Applied to net-next, thanks.
>>>>>
>>>>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>>>>> removal.  I know we've had several bugs that only apply when
>>>>> this option is on vs. off.  We're maintaining two different
>>>>> code paths, for really no good reason.
>>>>
>>>> I agree and actually thought about that yesterday. Do you think a sysctl
>>>> is a good option?
>>>
>>> Every distribution ships with the Kconfig option on, and no sysctl
>>> exists currently to control it.
>>>
>>> So I'd say it's not necessary at all, or at the very least let's have
>>> someone come forward with a real rather than theoretical use case for
>>> such a feature before adding it.
>>>
>>> Actually, if RFC 4191 has the usual language like "there SHOULD be
>>> an administrative mechanism to disable blah blah blah" I could
>>> be convinced to add it now.  Can someone take a look?
>>
>> It seems that there is no such an administrative mechanism in RFC 4191.
>>
>> By the way, if the sysctl is used, we are still maintaining two different
>> code paths, isn't it? so i think David's idea is good.
> 
> Makes life easier, no objections from me.
> 

Removing CONFIG_IPV6_ROUTER_PREF means that the Router Preference is always
on, is this understanding right?

If that's is correct,  i think compatibility issues will arise. For example, when the
CONFIG_IPV6_ROUTER_PREF option is on, the kernel should not do round-robin during
default router selection, but when the CONFIG_IPV6_ROUTER_PREF option is off, the
kernel should do it.

Thanks,
  Duan

> Greetings,
> 
>   Hannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[Hannes Frederic Sowa]

On Thu, Oct 31, 2013 at 07:09:56PM +0800, Duan Jiong wrote:
> 于 2013年10月31日 16:45, Hannes Frederic Sowa 写道:
> > On Thu, Oct 31, 2013 at 02:02:11PM +0800, Duan Jiong wrote:
> >> 于 2013年10月31日 12:22, David Miller 写道:
> >>> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >>> Date: Wed, 30 Oct 2013 22:11:57 +0100
> >>>
> >>>> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
> >>>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>>> Date: Wed, 30 Oct 2013 15:39:26 +0800
> >>>>>
> >>>>>>
> >>>>>> After reading the function rt6_check_neigh(), we can
> >>>>>> know that the RT6_NUD_FAIL_SOFT can be returned only
> >>>>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
> >>>>>> so in function find_match(), there is no need to execute
> >>>>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
> >>>>>>
> >>>>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>>>
> >>>>> Applied to net-next, thanks.
> >>>>>
> >>>>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
> >>>>> removal.  I know we've had several bugs that only apply when
> >>>>> this option is on vs. off.  We're maintaining two different
> >>>>> code paths, for really no good reason.
> >>>>
> >>>> I agree and actually thought about that yesterday. Do you think a sysctl
> >>>> is a good option?
> >>>
> >>> Every distribution ships with the Kconfig option on, and no sysctl
> >>> exists currently to control it.
> >>>
> >>> So I'd say it's not necessary at all, or at the very least let's have
> >>> someone come forward with a real rather than theoretical use case for
> >>> such a feature before adding it.
> >>>
> >>> Actually, if RFC 4191 has the usual language like "there SHOULD be
> >>> an administrative mechanism to disable blah blah blah" I could
> >>> be convinced to add it now.  Can someone take a look?
> >>
> >> It seems that there is no such an administrative mechanism in RFC 4191.
> >>
> >> By the way, if the sysctl is used, we are still maintaining two different
> >> code paths, isn't it? so i think David's idea is good.
> > 
> > Makes life easier, no objections from me.
> > 
> 
> Removing CONFIG_IPV6_ROUTER_PREF means that the Router Preference is always
> on, is this understanding right?

If we drop support for one of the routing scoring algorithms it will be the
other one. So yes, it will always be on.

> If that's is correct,  i think compatibility issues will arise. For example, when the
> CONFIG_IPV6_ROUTER_PREF option is on, the kernel should not do round-robin during
> default router selection, but when the CONFIG_IPV6_ROUTER_PREF option is off, the
> kernel should do it.

Exactly, but all people use ROUTER_PREF activated given it is enabled
by default by most distributions. I also know about no best practices
or IX-policies where they want a router to deliberately turned router
preference support off.

We can talk about doing RR in the same preference level, I'll have to do more
research on this.

But given that someone wants RR, it is better done by using ECMP routes.

Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

[David Miller]

From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Thu, 31 Oct 2013 19:09:56 +0800

> Removing CONFIG_IPV6_ROUTER_PREF means that the Router Preference is
> always on, is this understanding right?
> 
> If that's is correct, i think compatibility issues will arise. For
> example, when the CONFIG_IPV6_ROUTER_PREF option is on, the kernel
> should not do round-robin during default router selection, but when
> the CONFIG_IPV6_ROUTER_PREF option is off, the kernel should do it.

Everyone is essentially getting it enabled right now anyways, since
%99.999999 of users run distribution kernels.  Nobody has asked
for a run-time knob for this, which therefore means that %99.999999
of users simply do not care.

Yes there are people who build their own kernels, but to tell you
the truth I doubt anyone really turns this off explicitly to turn
off router preference handling.

But I'm willing to cater to them _iff_ the RFC tells us we should
provide should a capability.