Date: Mon, 4 May 2009 15:48:09 -0600 From: Will Andrews <will@firepipe.net> To: Bruce Simpson <bms@incunabulum.net> Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" <bms@freebsd.org> Subject: Re: CARP as a module; followup thoughts Message-ID: <2aada3410905041448o18722207m9f9d124573b39d54@mail.gmail.com> In-Reply-To: <49FF11F7.6090108@incunabulum.net> References: <2aada3410904212216o128e1fdfx8c299b3531adc694@mail.gmail.com> <49EF11E8.508@FreeBSD.org> <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> <49FF11F7.6090108@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 4, 2009 at 10:04 AM, Bruce Simpson <bms@incunabulum.net> wrote: > 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? It should. I am using git to develop these patches. I just did another sync (to r191794) and the diff from svn to my local git branch is the same as the patch I posted last night, so I presume it will apply to a fresh svn checkout of -current as of that revision. > 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. Yes, I can generate a separate patch for that one. If I were able to commit it myself, I'd certainly be doing it the way you suggest. I'd also suggest a more aggressive MFC timing for the free() bug fix than for the module feature (perhaps 3 days vs. 1-2 months, as 7.2R is now out). I am going to backport this patch to RELENG_7. Because of the way it is implemented, I believe it should be safe to MFC. > 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. Indeed, regressions will be difficult to prevent. I'm planning to work on virtual lladdrs for a bit to see if I can find a suitable solution for the problem. If nothing else, I think it provides a reasonable method for getting rid of carp_forus(), and possibly for implementing carpdev. Thanks, --Will.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2aada3410905041448o18722207m9f9d124573b39d54>