Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 May 2006 14:12:27 +0100
From:      Bruce M Simpson <bms@spc.org>
To:        Stephen Clark <Stephen.Clark@seclark.us>
Cc:        freebsd-net@freebsd.org, Robert Watson <rwatson@FreeBSD.org>, pavlin@icir.org, atanu@icir.org
Subject:   Re: IP_MAX_MEMBERSHIPS story.
Message-ID:  <20060512131227.GD79277@spc.org>
In-Reply-To: <4463FD1D.9010600@seclark.us>
References:  <20060509122801.GA65297@spc.org> <20060509131517.GB79277@spc.org> <20060512030152.X20138@fledge.watson.org> <4463FD1D.9010600@seclark.us>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 11, 2006 at 11:12:29PM -0400, Stephen Clark wrote:
> >I'm loosely of the opinion that the membership array should be 
> >variable length, and that we should default it to 20, but have a 
> >significantly larger maximum.  It's not horribly efficient, but also 
> >wouldn't be so particularly terrible either.
>
> I think it should be tunable other than going in a changing the source 
> code, which I have to do every time I do a cvsup.

This is the express intention of such a change.

The problem the user(s) are having is because each imo_membership member's
cardinality of relationship is 1:1 with respect to each multicast group
membership and each ifnet interface upon which the membership is
established.

Therefore, joining the same group 20 times on different interfaces
would exceed IP_MAX_MEMBERSHIPS.

Fixing this in any way would still break the ip_mroute_kmod ABI and
as such is a HEAD change.

Based on Robert's feedback I would therefore make a change such that
imo_membership is dynamically sized at runtime, rather than making
IP_MAX_MEMBERSHIPS a load-time tunable. Based on reading of the code it
looks like it may be best that imo_moptions becomes a pointer, not an
array.

I am happier with this kind of change because it is less invasive to
other parts of netinet, and also because it fits in with the lazy
allocation which already exists viz ip_findmoptions(). It is also
much simpler -- the complexity belongs in ip_findmoptions() and
ip_freemoptions().

Further feedback hoped for.  I will post patches soon.

Regards,
BMS



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