Date: Fri, 02 Oct 2009 13:53:37 +0100 From: Bruce Simpson <bms@FreeBSD.org> To: Philip Romanov <philip_romanov@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: IGMPv3 implementation Message-ID: <4AC5F7D1.5010404@FreeBSD.org> In-Reply-To: <951619.7835.qm@web52307.mail.re2.yahoo.com> References: <951619.7835.qm@web52307.mail.re2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
A bit more technical detail, as I may be taking a break quite soon:
IGMPv3 state changes happen on a group-by-group basis. IGMPv3 state
change reports, however, are issued on a per-link basis.
If the state for a group changes, the pending state change is
computed and enqueued to a per-group state-change queue. This involves
an RB-tree walk of the source list for the group. Per source counters
are not used here -- if a state change happens at t1 *before* a new
report is issued, the group's queue will get blown away and the group's
state change recomputed.
In practice the RB-tree should perform reasonably well,.and for most
use cases, this shouldn't present a problem. If a more scalable solution
is needed, that's up to the user.
The igmp_v3_merge_state_changes() function will cherry-pick from the
group's queue, and bundle it into the outgoing per-link queue. To break
out from under the locks, a software interrupt is used to actually
transmit the outgoing state-change report.
There is always room for improvement, though. The main thrust of the
project was to get IGMPv3 into the tree in an SMPng compatible way, and
time was sadly limited.
thanks,
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AC5F7D1.5010404>