Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Mar 2006 10:39:33 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        current@FreeBSD.org, Nik <nikruzhan@gmail.com>
Subject:   Re: multicast group memberships exceeded in FreeBSD 6-Prerelease
Message-ID:  <20060307103522.M30247@fledge.watson.org>
In-Reply-To: <20060307102505.GA77106@comp.chem.msu.su>
References:  <60ffc71f0603060759r34f02878ha38a7a275dc0aa6c@mail.gmail.com> <20060306230528.GC61210@comp.chem.msu.su> <60ffc71f0603061531g3c6995d2s54704022fe7ba1f@mail.gmail.com> <20060306235024.GA65709@comp.chem.msu.su> <60ffc71f0603061637j27ebe520r329e88bbc3141746@mail.gmail.com> <20060307012605.C79905@fledge.watson.org> <20060307102505.GA77106@comp.chem.msu.su>

next in thread | previous in thread | raw e-mail | index | archive | help

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 Watson



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307103522.M30247>