From owner-freebsd-current@FreeBSD.ORG Fri Oct 2 12:53:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3011065670 for ; Fri, 2 Oct 2009 12:53:40 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 328438FC1B for ; Fri, 2 Oct 2009 12:53:39 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 93E35833B1; Fri, 2 Oct 2009 08:53:39 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 02 Oct 2009 08:53:39 -0400 X-Sasl-enc: +pnTUw5aNBGrfGzD23ZDkZcH5uGI4SIHVY/OgqjHFwkC 1254488019 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0308047E66; Fri, 2 Oct 2009 08:53:38 -0400 (EDT) Message-ID: <4AC5F7D1.5010404@FreeBSD.org> Date: Fri, 02 Oct 2009 13:53:37 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (X11/20091001) MIME-Version: 1.0 To: Philip Romanov References: <951619.7835.qm@web52307.mail.re2.yahoo.com> In-Reply-To: <951619.7835.qm@web52307.mail.re2.yahoo.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: IGMPv3 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 12:53:40 -0000 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