From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 19:43:03 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E6DC16A402 for ; Sat, 17 Mar 2007 19:43:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 57C4713C44C for ; Sat, 17 Mar 2007 19:43:03 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 0402A1F84F4 for ; Sat, 17 Mar 2007 15:43:02 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Sat, 17 Mar 2007 15:43:02 -0400 X-Sasl-enc: RII7RimqyZZ18L8IEPQYCsG7LJLQJu+oDz4EYScXMdlI 1174160583 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 203432A8FC for ; Sat, 17 Mar 2007 15:43:02 -0400 (EDT) Message-ID: <45FC44C5.1090007@incunabulum.net> Date: Sat, 17 Mar 2007 19:43:01 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.9 (X11/20070125) MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPv4, IPv6 and link-layer multicast refcounting in bms_netdev X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 19:43:03 -0000 I have just committed reference counting for multicast structures in p4. Change list number is 116036. This should fix the problems with pfsync and carp since the scalability fixes for IPv4 multicast last September. A further cumulative fix for pfsync is present in this branch. Basic testing with the stock IPv4 and Ethernet code have been performed. Further testing would be much appreciated before the code is merged to HEAD. The refcounting has been implemented in a way so as not to break the 6.x ABI so that it may be merged to STABLE. It would be great to have feedback on how these patches may affect vlan(4) which is the only other consumer of the in_delmulti() KPI. My experience working on this suggests IFF_NEEDSGIANT is a real headache for dealing with ifnets which may potentially go away during the lifetime of the system. Regards, BMS