From owner-freebsd-net@FreeBSD.ORG Mon Jan 9 21:50:40 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF64C1065672 for ; Mon, 9 Jan 2012 21:50:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id B36018FC08 for ; Mon, 9 Jan 2012 21:50:39 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B1A5021F88 for ; Mon, 9 Jan 2012 16:50:38 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Jan 2012 16:50:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=a418uAtsFL/FvxujFGD3UY HvBRE=; b=Lw4Et94W2g83JQe9qcu0dHZeJKsQYjnmCrWSXBtyhreHBHKy8VOVlD 024uppRL4cIN32sIc3QgCRS8+BRh6hgmhHACmR1bg7XrTsM2kwTaIWlgEsN9DHgq 5jDeS4q4638LgjZ8XmPAEwK9tN/8Kxjk2+fITQ8yPHyEwBrGkRW54= X-Sasl-enc: bB9KMaL1ECwtxf6b/9X3Q1bRv/rxwi5ZVR5Ku8XfiC11 1326145838 Received: from [192.168.1.64] (94-192-87-254.zone6.bethere.co.uk [94.192.87.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 31E5648251C; Mon, 9 Jan 2012 16:50:38 -0500 (EST) Message-ID: <4F0B6169.5030704@incunabulum.net> Date: Mon, 09 Jan 2012 21:51:37 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Baldwin References: <201112221115.10239.jhb@freebsd.org> <4F0B0684.8040609@incunabulum.net> <201201091128.10193.jhb@freebsd.org> In-Reply-To: <201201091128.10193.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Deferring inp_freemoptions() to an asychronous task 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: Mon, 09 Jan 2012 21:50:40 -0000 John, I'm glad there are people, outside of finance and broadcast, who understand the teething pains of multicast. I might be able to spare cycles to test patches, so if someone steps up to the plate in the meantime, I'm happy to look where I can. We now have a FreeBSD testbed at work, having started a FreeBSD-based project with no infrastructure. "Of course it runs ZFS." John Baldwin wrote: > On Monday, January 09, 2012 10:23:48 am Bruce Simpson wrote: >> You've also stumbled on the behaviour specific to how BSD has >> traditionally dealt with broadcast/multicast sockets. The pcbinfo >> structure can't really be disentangled from this. >> >> Of course, it doesn't help that we have historically required these >> sockets to be bound to INADDR_ANY. It might be useful to break reception >> out using a separate hash/tree, rather than walking all sockets as is >> currently done, but legacy usage needs to be supported. >> > The other fun part in this case is that if it is going to take a long time, a > driver should probably be enabling reception of all multicast (equivalent of > IFF_ALLMULTI) while it reprograms the table to avoid dropping packets for > already-joined groups. I'm not currently doing this as we are using a different > hack, but I think that is something drivers should probably be doing. I couldn't agree more re IFF_ALLMULTI. One change which I would have liked to have made, during the IGMPv3/SSM project, was to re-do the join operation so we could do things like this a little more easily. Another would have been to add a limited wrapper around IFF_PROMISC (let's call that one IFF_SOFTMULTI), in situations where cards were known to have broken IFF_ALLMULTI. This would extend their useful lifetime into the IPv6 era, as well as making it possible to use them for ISO protocols, historic (CLNP) and useful (IS-IS), which like to have working link-layer multicast. The chances are that if you're doing any of these things, you are probably using non-broken hardware, or a vendor already lugging patches around for these things (in which case, please share). Or you are using pcap directly and feeling the suck of having to write everything userland at layer 2. I don't have much free time for development outside of work at the moment, otherwise I would be rattling off more diffs. As it is, I have Git to look forward to. Bruce