Adding IPv6 support to IPVS: some general questions about kernel development

Adding IPv6 support to IPVS: some general questions about kernel development

[Julius Volz]

Hi,

I was redirected here from lvs-devel for a particular question. As
part of an internship at Google, I am currently looking at porting the
IPVS (IP virtual server) kernel part of LVS to support IPv6. First
off, I am neither a real specialist in any of the involved areas yet
(IPv6, load balancing) nor do I have much experience writing kernel
code (mainly reading it for some time now), but I will try to learn as
much as I can each day. Do expect lots of newbie questions though ;)

One question I had on lvs-devel that people here might know more
about: IPVS is currently sitting at "net/ipv4/ipvs/..." in the kernel.
A lot of this code would probably be the same for an IPv6 version, so
the code would have to be refactored somehow and partially moved to a
location where it can be used by both the IPv4 and IPv6 code. Are
there any special rules for this and what do I have to think of? For
example, could I just move the common code to a directory "net/ipvs"
(or even all of the code, for both IPv4 and IPv6) or would people
object?

I'm also not sure yet on how to best begin coding in such a manner
that the whole thing will be manageable with small, separate patches
that each have a chance of being accepted (would that mean that each
small patch would have to be useful on its own in a way? That seems
difficult). This is just because I also don't have a lot of experience
patching other people's projects in this manner.

If any of you could offer some advice on these issues, I would greatly
appreciate it!

Kind Regards,
Julius Volz

-- 
Google Switzerland GmbH

Re: Adding IPv6 support to IPVS: some general questions about kernel development

[Patrick McHardy]

Julius Volz wrote:
> I was redirected here from lvs-devel for a particular question. As
> part of an internship at Google, I am currently looking at porting the
> IPVS (IP virtual server) kernel part of LVS to support IPv6. First
> off, I am neither a real specialist in any of the involved areas yet
> (IPv6, load balancing) nor do I have much experience writing kernel
> code (mainly reading it for some time now), but I will try to learn as
> much as I can each day. Do expect lots of newbie questions though ;)
> 
> One question I had on lvs-devel that people here might know more
> about: IPVS is currently sitting at "net/ipv4/ipvs/..." in the kernel.
> A lot of this code would probably be the same for an IPv6 version, so
> the code would have to be refactored somehow and partially moved to a
> location where it can be used by both the IPv4 and IPv6 code. Are
> there any special rules for this and what do I have to think of? For
> example, could I just move the common code to a directory "net/ipvs"
> (or even all of the code, for both IPv4 and IPv6) or would people
> object?

net/ipvs or net/netfilter/ipvs sound fine. The second is probably
better since at some point we should try to merge the duplicated
conntrack functionality if possible.

Re: Adding IPv6 support to IPVS: some general questions about kernel development

[Julius Volz]

On Mon, Mar 31, 2008, Patrick McHardy <kaber@trash.net> wrote:
>  net/ipvs or net/netfilter/ipvs sound fine. The second is probably
>  better since at some point we should try to merge the duplicated
>  conntrack functionality if possible.

Sure, since IPVS is basically a netfilter extension, that sounds good
to me. Could all the IPv4- and IPv6-specific functionality (as opposed
to the commonly used code) also end up in there or would that still
have to reside under ipv[4,6]/...?

Does it seem wise to do this move as the first thing in this process?
That would probably be a good starter exercise to get to know the
whole process!

Thanks so much for helping!

Kind Regards,
Julius

-- 
Google Switzerland GmbH

Re: Adding IPv6 support to IPVS: some general questions about kernel development

[Simon Horman]

On Mon, Mar 31, 2008 at 08:29:30PM +0200, Julius Volz wrote:
> On Mon, Mar 31, 2008, Patrick McHardy <kaber@trash.net> wrote:
> >  net/ipvs or net/netfilter/ipvs sound fine. The second is probably
> >  better since at some point we should try to merge the duplicated
> >  conntrack functionality if possible.
> 
> Sure, since IPVS is basically a netfilter extension, that sounds good
> to me. Could all the IPv4- and IPv6-specific functionality (as opposed
> to the commonly used code) also end up in there or would that still
> have to reside under ipv[4,6]/...?
> 
> Does it seem wise to do this move as the first thing in this process?
> That would probably be a good starter exercise to get to know the
> whole process!

I think that sounds like an excellent idea. net/netfilter/ipvs sounds
fine to me, though think that IPVS is fairly loosely tied to nefilter,
so if it was only up to me I would go for net/ipvs.

-- 
Horms

Re: Adding IPv6 support to IPVS: some general questions about kernel development

[Julius Volz]

On Tue, Apr 1, 2008, Simon Horman wrote:
> On Mon, Mar 31, 2008 at 08:29:30PM +0200, Julius Volz wrote:
>  > On Mon, Mar 31, 2008, Patrick McHardy <kaber@trash.net> wrote:
>  > >  net/ipvs or net/netfilter/ipvs sound fine. The second is probably
>  > >  better since at some point we should try to merge the duplicated
>  > >  conntrack functionality if possible.
>  >
>  > Sure, since IPVS is basically a netfilter extension, that sounds good
>  > to me. Could all the IPv4- and IPv6-specific functionality (as opposed
>  > to the commonly used code) also end up in there or would that still
>  > have to reside under ipv[4,6]/...?
>  >
>  > Does it seem wise to do this move as the first thing in this process?
>  > That would probably be a good starter exercise to get to know the
>  > whole process!
>
>  I think that sounds like an excellent idea. net/netfilter/ipvs sounds
>  fine to me, though think that IPVS is fairly loosely tied to nefilter,
>  so if it was only up to me I would go for net/ipvs.

Ok, I will do this soon then! I will go for net/netfilter/ipvs (I
don't really care though) unless anyone complains.

Julius

-- 
Google Switzerland GmbH