From: Brodie Greenfield <[email protected]> Date: Fri, 26 Jul 2019 08:42:28 +1200
> We want to have some more space in our queue for processing incoming > multicast packets, so we can process more of them without dropping > them prematurely. It is useful to be able to increase this limit on > higher-spec platforms that can handle more items. > > For the particular use case here at Allied Telesis, we have linux > running on our switches and routers, with support for the number of > multicast groups being increased. Basically, this queue length affects > the time taken to fully learn all of the multicast streams. > > Changes in v3: > - Corrected a v4 to v6 typo. As others have voiced, I think it's dangerous to let every netns increase this so readily. We need to either put in a non-initns limit or simply not allow non-init namespaces to change this. But really socket queue limits are a better place to enforce this.
