Re: using carp(4)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Nov 13, 2011 at 10:55:38PM +0100, Manuel Bouyer wrote:
> On Tue, Nov 01, 2011 at 07:29:28PM -0500, David Young wrote:
> > Is it ok to remove carp(4)?
> 
> I'm using it heavyly (and have even more usaeages in mind) at work.
> 
> >  I ask because it seems like a peculiar
> > function for the kernel to provide, it may already be bitrotten, and the
> > implementation will be difficult to maintain for the future.
> > 
> > The automated tests have recently detected a regression in carp(4),
> > possibly my fault, so I have been trying to figure out what this
> > creature is and how it works.
> > 
> > I learned from the carp(4) manual page that it is not a fish. I found a
> > more helpful description of carp(4) in an old email of Liam J. Foy's,
> > and now I think that I understand what it is trying to do.
> > 
> > I have reproduced the ATF test-case failure, and I have had a look at
> > the code, and experimented with it on a dev box of mine.  No kernel
> > but i386/ALL actually contains carp(4), and carp(4) is not built as a
> > module, so I had to add it to my GENERIC-derived kernel configuration
> > in order to begin experimenting.  The ATF test runs in the RUMP
> > environment, not the test-host environment.
> > 
> > During my experiments, I ran across a bug where 'ifconfig carp0 destroy'
> > causes a panic in callout_destroy().  That is not the same bug that ATF
> > trips over.  I have a hunch that it has been there for a long time, but
> > I don't see a PR for it.  That makes me wonder whether anyone is using
> > carp(4) on -current?  Is anyone using it at all?
> 
> Well, I don't destroy carp interfaces in regular use :)
> 
> > 
> > The code for carp(4) seems to have grown roots deep into the kernel.  I
> > see code that fiddles with ifnet internals and with routes, and I see
> > that carp(4) has its own protocol-switch entry.
> > I anticipate it causing trouble for developers who would try to keep it
> > up-to-date with changing/disappearing kernel APIs (such as they are) and
> > a more modular, more SMP-friendly network stack.
> > 
> > Considering the function of carp(4), I wonder why it is a kernel
> > function instead of a user daemon?  It seems that you could accomplish
> > the same thing with a daemon that runs the CARP protocol and
> > adds/removes a backup interface from a bridge(4) as it is necessary.
> 
> I'm not sure that's enough. The kernel would still consider this
> interface as up and running, which a carp in backup mode is not really.
> 
> Also there's some load balancing facilities in carp (I'm not using this
> right now, but it could be comming)

I also forgot to mention that I'm using the preempt mode.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--