On Tue, 7 Mar 2006, Yar Tikhiy wrote: > On Tue, Mar 07, 2006 at 01:26:28AM +0000, Robert Watson wrote: >> 5B>> On Tue, 7 Mar 2006, Nik wrote: >> >>> Thanks bro. Really appreciate that, I'll give a try after this then I'll >>> let you know the result. >> >> We might want to consider increasing the maximum to a larger number, given >> that 20 does sound a bit small these days. > > I'm afraid that with folks running hundreds of vlan interfaces per host out > there, any reasonable default would be too small to fit every case. When I > faced the problem, I took a quick look at if it would be possible to make it > a sysctl, but it seemed to me not so easy, so I just bumped the define that > time becuase had to make my routers work ASAP. The task of making it a > sysctl may need a re-examination... And given that these are static array lengths, hanging them off every multicast socket seems bad. We probably need to simply support growable arrays of addresses, with an administrative limit that is very high. Now the basic locking for multicast lists on the inpcb is done, this should be possible to do without too much trouble -- we can add an ip_findmoptions() variant that knows that it needs imo_num_memberships + 1 slots, and if there isn't room, perform the array extension and copying the same way it does the basic malloc now. Starting with a default of 20 and then growing in multiples of two isn't a bad approach, which would let us have an administrative limit in the thousands without consuming that much memory all the time. If worried, we could require privilege to exceed a lower administrative limit. I don't have time to work on this now, but once my current socket work is done in a month or so, I can take a look if no one has gotten to it first. Robert N M WatsonReceived on Tue Mar 07 2006 - 09:39:24 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:53 UTC