On 1/22/21 9:02 PM, Maciej Żenczykowski wrote:
Why can't we get rid of the special case for 0 and simply make 1024 the
default value?
That would work too.
As for making it an RA option: it's not clear how that would work, the
use case I see for this is for example two connections to the internet,
of which one is clearly better (higher throughput, lower latency, lower
packet loss, etc) then the other.
The upstream routers would have to somehow coordinate with each other
the metric values... that seems impossible to achieve in practice -
unless they do something like report expected down/up
bandwidth, latency, etc... While some sort of policy on the machine
itself seems much more feasible (for example wired interface > wireless
interface > cell interface or something like that)
I was thinking the admin of the network controls the RAs and knows which
paths are preferred over the admin of the node receiving the RA (not
practical for a mobile setup with cell vs wifi, but is for a DC which is
the driving use case).
But it takes an extension to IPv6/ndisc to add metric as an RA option,
so not realistic in a reasonable time frame.
On Fri, 22 Jan 2021 22:16:41 -0700 David Ahern wrote:
On 1/22/21 9:02 PM, Maciej Żenczykowski wrote:
quoted
Why can't we get rid of the special case for 0 and simply make 1024 the
default value?
That would work too.
Should we drop it then? Easier to bring it back than to change the
interpretation later. It doesn't seem to serve any clear purpose right
now.
(Praveen if you post v4 please take a look at the checkpatch --strict
warnings and address the ones which make sense, e.g. drop the brackets
around comparisons, those are just noise, basic grasp of C operator
precedence can be assumed in readers of kernel code).
On 1/23/21 1:00 PM, Jakub Kicinski wrote:
On Fri, 22 Jan 2021 22:16:41 -0700 David Ahern wrote:
quoted
On 1/22/21 9:02 PM, Maciej Żenczykowski wrote:
quoted
Why can't we get rid of the special case for 0 and simply make 1024 the
default value?
That would work too.
Should we drop it then? Easier to bring it back than to change the
interpretation later. It doesn't seem to serve any clear purpose right
now.
(Praveen if you post v4 please take a look at the checkpatch --strict
warnings and address the ones which make sense, e.g. drop the brackets
around comparisons, those are just noise, basic grasp of C operator
precedence can be assumed in readers of kernel code).
let's do a v4.
Praveen: set the initial value to IP6_RT_PRIO_USER, do not allow 0,
remove the checks on value and don't forget to update documentation.
Oh and cc me on the next otherwise the review depends on me finding time
to scan netdev.
On Jan 23, 2021, at 5:13 PM, David Ahern [off-list ref] wrote:
On 1/23/21 1:00 PM, Jakub Kicinski wrote:
quoted
On Fri, 22 Jan 2021 22:16:41 -0700 David Ahern wrote:
quoted
On 1/22/21 9:02 PM, Maciej Żenczykowski wrote:
quoted
Why can't we get rid of the special case for 0 and simply make 1024 the
default value?
That would work too.
Should we drop it then? Easier to bring it back than to change the
interpretation later. It doesn't seem to serve any clear purpose right
now.
(Praveen if you post v4 please take a look at the checkpatch --strict
warnings and address the ones which make sense, e.g. drop the brackets
around comparisons, those are just noise, basic grasp of C operator
precedence can be assumed in readers of kernel code).
let's do a v4.
Praveen: set the initial value to IP6_RT_PRIO_USER, do not allow 0,
remove the checks on value and don't forget to update documentation.
Sure, I will respin V4, with above mentioned changes. Also, I will address checkpatch --strict warnings.
I wanted to set initial value to IP6_RT_PRIO_USER in v1, but avoided till review for 2 simple coding reasons:
1.) IP6_RT_PRIO_USER must be exposed in net/ipv6/addrconf.c by including include/uapi/linux/ipv6_route.h.
2.) If rt6_add_dflt_router() will be called from other files in future, IP6_RT_PRIO_USER should be included in all those files as well, because caller will pass most probably default value.
Oh and cc me on the next otherwise the review depends on me finding time
to scan netdev.
Sure, I will cc you and will add “Reviewed by” as well. I will also send you the lkml link to v4.
Thanks Jakub and you for reviewing this over the weekend.