On Tue, Jul 24, 2018 at 8:14 AM David Ahern <dsahern@xxxxxxxxx> wrote: > > On 7/19/18 11:12 AM, Cong Wang wrote: > > On Thu, Jul 19, 2018 at 9:16 AM David Ahern <dsahern@xxxxxxxxx> wrote: > >> > >> Chatting with Nikolay about this and he brought up a good corollary - ip > >> fragmentation. It really is a similar problem in that memory is consumed > >> as a result of packets received from an external entity. The ipfrag > >> sysctls are per namespace with a limit that non-init_net namespaces can > >> not set high_thresh > the current value of init_net. Potential memory > >> consumed by fragments scales with the number of namespaces which is the > >> primary concern with making neighbor tables per namespace. > > > > Nothing new, already discussed: > > https://marc.info/?l=linux-netdev&m=140391416215988&w=2 > > > > :) > > > > Neighbor tables, bridge fdbs, vxlan fdbs and ip fragments all consume > local memory resources due to received packets. bridge and vxlan fdb's > are fairly straightforward analogs to neighbor entries; they are per > device with no limits on the number of entries. Fragments have memory > limits per namespace. So neighbor tables are the only ones with this > strict limitation and concern on memory consumption. > > I get the impression there is no longer a strong resistance against > moving the tables to per namespace, but deciding what is the right > approach to handle backwards compatibility. Correct? Changing the > accounting is inevitably going to be noticeable to some use case(s), but > with sysctl settings it is a simple runtime update once the user knows > to make the change. This question definitely should go to Eric Biederman who was against my proposal. Let's add Eric into CC. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
