On 3/5/18 5:29 AM, Stefano Brivio wrote:
> On Sun, 4 Mar 2018 18:11:41 -0700
> David Ahern wrote:
>
>> On 3/4/18 4:12 PM, Stefano Brivio wrote:
>>> On Sat, 3 Mar 2018 12:22:36 +0100
>>> Stefano Brivio wrote:
>>>
> And please codify the above expectation as a test under
> tools/testing
From: Stefano Brivio
Date: Mon, 5 Mar 2018 13:29:56 +0100
> And about corner cases, from Documentation/dev-tools/kselftest.rst:
>
> These are intended to be small tests to exercise individual code
> paths in the kernel. Tests are intended to be run after building,
> installing
>
On Sun, 4 Mar 2018 18:11:41 -0700
David Ahern wrote:
> On 3/4/18 4:12 PM, Stefano Brivio wrote:
> > On Sat, 3 Mar 2018 12:22:36 +0100
> > Stefano Brivio wrote:
> >
> >>> And please codify the above expectation as a test under
> >>> tools/testing/selftests/net
> >>
> >> And this, along wit
On 3/4/18 4:12 PM, Stefano Brivio wrote:
> On Sat, 3 Mar 2018 12:22:36 +0100
> Stefano Brivio wrote:
>
>>> And please codify the above expectation as a test under
>>> tools/testing/selftests/net
>>
>> And this, along with v2.
>
> On a second thought: I start thinking it doesn't make much sense
On Sat, 3 Mar 2018 12:22:36 +0100
Stefano Brivio wrote:
> > And please codify the above expectation as a test under
> > tools/testing/selftests/net
>
> And this, along with v2.
On a second thought: I start thinking it doesn't make much sense,
especially given the current context of self-tests
On Fri, 2 Mar 2018 15:39:03 -0700
David Ahern wrote:
> On 3/2/18 8:36 AM, Stefano Brivio wrote:
> > Currently, administrative MTU changes on a given netdevice are
> > not reflected on route exceptions for MTU-less routes, with a
> > set PMTU value, for that device:
> >
> > # ip -6 route get 300
Hi Maciej,
On Fri, 2 Mar 2018 10:54:36 -0800
Maciej Żenczykowski wrote:
> I spend a significant fraction of my time making sure we never rely on PMTUD.
Thanks for your comments.
I see your point, but here we are not blindly relying on PMTUD,
rather reflecting an MTU administrative change on th
On 3/2/18 8:36 AM, Stefano Brivio wrote:
> Currently, administrative MTU changes on a given netdevice are
> not reflected on route exceptions for MTU-less routes, with a
> set PMTU value, for that device:
>
> # ip -6 route get 3000::b
> 3000::b from :: dev vti_a proto kernel src 3000::a metric 2
Conceptually this is right.
And I'm 100% fine with dev mtu change triggering pmtu decrease.
I'm not so sold on the pmtu increase.
PMTUD is one of those things that never ever works right in practice.
There's too many icmp blackholes, rate limits, overloaded management
cpus in switches,
misconfig
Currently, administrative MTU changes on a given netdevice are
not reflected on route exceptions for MTU-less routes, with a
set PMTU value, for that device:
# ip -6 route get 3000::b
3000::b from :: dev vti_a proto kernel src 3000::a metric 256 pref medium
# ping6 -c 1 -q -s1 3000::b > /de
10 matches
Mail list logo