From: Ulf Samuelsson <netdev@emagii•com>
To: David Miller <davem@davemloft•net>
Cc: netdev@vger•kernel.org
Subject: Re: [PATCH] neighbour.c: Avoid GC directly after state change
Date: Wed, 18 Mar 2015 00:33:56 +0100 [thread overview]
Message-ID: <5508B9E4.1060507@emagii.com> (raw)
In-Reply-To: <20150312.142621.1128728353472907283.davem@davemloft.net>
Den 2015-03-12 19:26, David Miller skrev:
> I hate changes like this.
>
> By making this a Kconfig options it cannot be dynamic, and every
> distribution is going to have to scratch their head and decide
> what to set this to.
>
> That's seriously suboptimal.
>
> If you want to change behavior based upon whether userspace is
> managing the damn table, make it so the user doing so has to
> ask for the new behavior at _RUN TIME_ via the netlink interface
> or similar.
>
> Picking the guard time itself at compile time is also undesirable.
>
> And you don't even want a damn timer, what you want is for the
> state of the entry to be frozen and for the user to "release"
> it by either adjusting the state to something else or marking
> in some other way to allow it to be unfrozen and released again.
>
> Why put it to chance with some timeout? Make things explicit.
>
> I'm not applying this patch.
>
> --
> 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
Sounds reasonable comments to me.
Would this approach work?
2 new message types are defined, to enable/disable the garbage
collection functionality.
RTM_ENANEIGHGC
RTM_DISANEIGHGC
When the functionality is disabled, the stack will not garbage collect,
and the external application will have to send netlink messages
to delete unwanted entries.
1 new message is defined to move an entry from STALE to DELAY.
RTM_NEIGHRECOVER
Will have to discuss internally to see if this works.
BR
Ulf Samuelsson
next prev parent reply other threads:[~2015-03-17 23:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 21:01 [PATCH] neighbour.c: Avoid GC directly after state change Ulf Samuelsson
2015-03-12 18:26 ` David Miller
2015-03-17 23:33 ` Ulf Samuelsson [this message]
2015-03-18 1:56 ` YOSHIFUJI Hideaki/吉藤英明
2015-04-10 8:26 ` Ulf Samuelsson
2015-04-15 13:40 ` Ulf Samuelsson
2015-04-16 5:16 ` YOSHIFUJI Hideaki
2015-04-17 8:03 ` Ulf Samuelsson
2015-04-20 2:33 ` YOSHIFUJI Hideaki
2015-04-20 12:48 ` Ulf Samuelsson
2015-04-21 3:58 ` YOSHIFUJI Hideaki
2015-04-22 7:42 ` Ulf Samuelsson
2015-04-22 10:46 ` YOSHIFUJI Hideaki
2015-04-22 11:49 ` Ulf Samuelsson
2015-05-08 9:39 ` Ulf Samuelsson
-- strict thread matches above, loose matches on Subject: below --
2015-03-11 20:28 Ulf Samuelsson
2015-03-15 8:27 ` YOSHIFUJI Hideaki
2015-03-15 19:34 ` Ulf Samuelsson
2015-03-16 4:57 ` YOSHIFUJI Hideaki/吉藤英明
2015-03-16 19:55 ` Ulf Samuelsson
2015-03-17 12:31 ` YOSHIFUJI Hideaki
2015-03-17 23:27 ` Ulf Samuelsson
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=5508B9E4.1060507@emagii.com \
--to=netdev@emagii$(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