From owner-freebsd-net@FreeBSD.ORG Mon May 4 16:04:13 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB765106566B; Mon, 4 May 2009 16:04:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id ADCA48FC18; Mon, 4 May 2009 16:04:13 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1F46D339F93; Mon, 4 May 2009 12:04:13 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 04 May 2009 12:04:13 -0400 X-Sasl-enc: LLIfzfuvjoU2klz0KREzTg1S3m0tIDkCLtO7kC12t5Lr 1241453052 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 ESMTPSA id C7D5D2B42F; Mon, 4 May 2009 12:04:10 -0400 (EDT) Message-ID: <49FF11F7.6090108@incunabulum.net> Date: Mon, 04 May 2009 17:04:07 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Will Andrews References: <2aada3410904212216o128e1fdfx8c299b3531adc694@mail.gmail.com> <49EF11E8.508@FreeBSD.org> <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> In-Reply-To: <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: CARP as a module; followup thoughts 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, 04 May 2009 16:04:14 -0000 Will Andrews wrote: > Thank you very much for your feedback. I have implemented your > suggestion as follows: > > http://firepipe.net/patches/carp-as-module-20090503-2.diff > Great stuff. Overall this does make things that much cleaner. > This version doesn't reinvent the wheel as far as registering the > protocol goes. Personally, I think that notwithstanding your other > objection, this should get committed, since it is a step in the right > direction (perhaps minus the netinet6/in6_proto.c change that adds > spacers). One step at a time! > Yeah, I wouldn't worry about it too much for now. It is something which would be nice to have -- some NICs will perfect hash in hardware on more than one MAC address -- but I believe we've got other issues in this area to do with per-AF locking, which would probably be touched by exactly the issues you raise in the last part of your post... well spotted... > carp_encapcheck() is simplistic, but probably suffices (maybe also > check to see if the vh MAC matches). This patch does work fine with > my test setup, one system using GENERIC+if_carp and the other using a > static build without the patch. > I'll have to take your word for that as I'm not using CARP just at the moment. I had to touch the mcast setup for the IPv6 SSM implementation. All compiles OK, but I haven't tested the code other than loading it. Only IPv6 multicast group setup should be affected. Does your patch apply against these revisions OK? > I also found a "memory leak" in the original code, where it calls > free(cif, M_IFADDR), which is wrong, it should be free(cif, M_CARP), > since the original malloc uses M_CARP -- this fix is also included in > the patch above. > Great stuff. Can this bug fix be merged separately, i.e. before other code is committed? That way it can get merged back to -STABLE more quickly, once RELENG_7 is unfrozen. > ... > > Another way would be to have a separate list/hash table for virtual > lladdr's (ifnet.ifvirt_lladdrhead?). I considered that but it seems > better and more general to simply upgrade ifnet.if_addrhead. > It would be good to have a more general code path for stuff like this to benefit from using the perfect hash filters in modern NICs, the main thing is that everything continues to work with no regressions :-) Thanks for the effort you've put into this, it will certainly help a lot of folk to be able to ship a CARP-capable GENERIC kernel. cheers, BMS