>-----Original Message----- >From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> >Sent: Friday, July 1, 2022 2:57 PM >To: Sriram R (QUIC) <quic_srirrama@xxxxxxxxxxx>; nbd@xxxxxxxx >Cc: linux-wireless@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 0/3] Mesh Fast xmit support > >WARNING: This email originated from outside of Qualcomm. Please be wary of >any links or attachments, and do not enable macros. > >> Initially it was set it to a default size of 50 when RFC was sent. >> There was a suggestion to >> make it configurable where users could configure this cache size >> proportional to the required/anticipated network capacity. > >Oh, right, I missed that this was in the discussion earlier. > >The question is what are you afraid of? I mean, even setting it to 500 wouldn't >be a huge amount of memory use (~50k), and probably mostly sufficient >regardless of the network? And if you never see all those nodes, then it wouldn't >use all that memory either. > >Timing out old entries will also keep memory usage down. > >So are you worried about worst-case behaviour in attacks, e.g. somebody >attempting to join the mesh? But then if you're worried about that I guess you >have bigger problems (and should be using secure mesh), such as the number of >station entries? > >Or an attacker mutating their Ethernet address behind some gateway? But they >still need to convince the station to even want to send traffic there... > >But even then, setting a much higher limit than 50 should cope with these cases, >while giving enough breathing room for the real usage? > Hi Johannes, The only concern/reason is to not silently increase the memory requirement of Mesh support with this patch. So was skeptical on having a higher cache size(like 250 or 500 max). Hence had a value of 50 and left the configuration part for devices which needed higher cache. But as you mentioned, this is only runtime max memory and not default. So we should be fine to set some high limit, If above is not a concern could we stick to an upper limit of ~150-200 ? Apart from that, though the points you mentioned are quite possible, the cache Management logic will ensure to cleanup stale entries and in worst case will use regular header generation process if cache is full. So I feel that should ensure things work as normal even under attack. Thanks, Sriram.R
