Ulf Samuelsson wrote: > > 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.
We try providing "good solution" if you have less than gc_thresh1 entries only. Otherwise, we try hard to protect ourselves. > 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.try pr > > 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? We reclaim neighbor entries as much as possible to protect ourselves if the number is below gc_thresh1. We could stop purging entries, but the idea was rejected AFAIK. That is our design. Again, you should increase gc_thresh1, first. -- Hideaki Yoshifuji <hideaki.yoshif...@miraclelinux.com> Technical Division, MIRACLE LINUX CORPORATION -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
