From: "Pádraig Brady" <P@draigBrady•com>
To: Ani Sinha <ani@arista•com>, David Miller <davem@davemloft•net>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>
Subject: Re: route/max_size sysctl in ipv4
Date: Tue, 06 Jan 2015 12:41:51 +0000 [thread overview]
Message-ID: <54ABD80F.7070602@draigBrady.com> (raw)
In-Reply-To: <CAOxq_8OysjN8OrvhM13t3YUuyh5O=KM_mptR=NHieq146mqZ8g@mail.gmail.com>
On 06/01/15 00:56, Ani Sinha wrote:
> On Mon, Jan 5, 2015 at 4:51 PM, David Miller <davem@davemloft•net> wrote:
>> From: Ani Sinha <ani@arista•com>
>> Date: Mon, 5 Jan 2015 16:43:30 -0800
>>
>>> On Mon, Jan 5, 2015 at 4:36 PM, David Miller <davem@davemloft•net> wrote:
>>>> From: Ani Sinha <ani@arista•com>
>>>> Date: Mon, 5 Jan 2015 15:48:11 -0800
>>>>
>>>>> I am looking at the code and it looks like since the route cache for
>>>>> ipv4 was removed from the kernel, this sysctl parameter no longer
>>>>> serves the same purpose. It does not look like it is even used in the
>>>>> ipv4/route.c module. Is there an equivalent sysctl parameter limiting
>>>>> the number of route entries in the kernel? Or is there now no
>>>>> mechanism to limit the number of route entries?
>>>>
>>>> There is nothing to limit, since the cache was removed.
>>>
>>> Shouldn't the documentation be updated to reflect that? Also what's
>>> the point of having a dummy variable that does nothing? Should we not
>>> simply remove it?
>>
>> There is nothing to update, the behavior is completely transparent.
>> Absolutely no cache entries exist, therefore the limit cannot be
>> reached.
>
> I disagree. You are advertising a feature in an official documentation
> that simply does not exist for ipv4. This is very confusing. If I did
> not dig into the code, I wouldn't know that this particular knob is a
> noop since the time the route cache was removed.
You can't change APIs with impunity.
>> The sysctl is kept so that scripts reading it don't suddenly stop
>> working. We can't just remove sysctl values.
Perhaps /proc/sys/net/ipv4/route/max_size should always return 0 when read,
and discard written values?
thanks,
Pádraig
next prev parent reply other threads:[~2015-01-06 12:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-05 23:48 route/max_size sysctl in ipv4 Ani Sinha
2015-01-06 0:36 ` David Miller
2015-01-06 0:43 ` Ani Sinha
2015-01-06 0:51 ` David Miller
2015-01-06 0:56 ` Ani Sinha
2015-01-06 12:41 ` Pádraig Brady [this message]
2015-01-06 17:11 ` Ani Sinha
2015-01-06 18:09 ` Eric Dumazet
2015-01-06 20:05 ` Ani Sinha
2015-01-07 1:56 ` Ani Sinha
2015-01-08 1:25 ` Ani Sinha
2015-01-08 2:19 ` Eric Dumazet
2015-01-08 3:40 ` Ani Sinha
2015-01-08 5:41 ` Eric Dumazet
2015-01-08 18:39 ` Ani Sinha
2015-01-08 19:03 ` Eric Dumazet
2015-01-08 20:13 ` Ani Sinha
2015-01-08 20:18 ` Eric Dumazet
2015-01-09 18:47 ` Cong Wang
2015-01-09 19:08 ` Ani Sinha
2015-01-09 19:37 ` Cong Wang
2015-01-09 21:23 ` Ani Sinha
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=54ABD80F.7070602@draigBrady.com \
--to=p@draigbrady$(echo .)com \
--cc=ani@arista$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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