netdev - Re: [PATCH] neighbour.c: Avoid GC directly after state change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <553750CC.8010003@ericsson.com>
Date:	Wed, 22 Apr 2015 09:42:04 +0200
From:	Ulf Samuelsson <ulf.samuelsson@...csson.com>
To:	YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>,
	<netdev@...gii.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: [PATCH] neighbour.c: Avoid GC directly after state change


On 04/21/2015 05:58 AM, YOSHIFUJI Hideaki wrote:
> Ulf Samuelsson wrote:
>>> How many neighbors do you want to maintain?
>>> I guess you have to increase the number of gc_thresh1.
>> The current use cases have up to 2048 entries.
>> This is expected to grow in the future.
>> The 3.4 kernel used in the system today is limited to 1024,
>> but that has been raised to about 10k.
>>
>> The gc_thresh1 test is not implemented in 3.4 but can be backported,
>> but still not convinced it is a good idea.
> Why?
>
A good solution makes sure that:
* equipment which is connected NEVER IS garbage collected
* equipment which is disconnected IS garbage collected.

The threshold idea does not meet the criteria for a good solution.

With this solution you keep unnecessary entries in the table.
If you ever pass the limit, then equipment which should not
be garbage collected may be.
It relies on someone keeping track of traffic loss,
so needs more maintenance by the SysOp.

The ARP probes should be considered to be NECESSARY traffic
to maintain a quality link.
Obviously not everyone would want to make this trade-off.


>> To complicate things, one requirement is that for some interfaces
>> you always want to keep things alive, if connected, but
>> for other interfaces you want things to be removed
>> to conserve memory.
>> Actually you would want to do this selection on a subnet level.
> If you want to introduce per-interface parameter, I am okay with it.
>
>> Internal discussions resulted in a proposal to change the patch,
>> so that you have a "keepalive" flag which is tested after
>> it has been decided to exit the REACHABLE state.
>>
>> if the "keepalive" flag is set, you always go to DELAY state from REACHABLE.
> No.
>
And why is it a bad idea to have a high quality connection?

Best Regards,
Ulf Samuelsson

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