Should we move IPVS out of net/ipv4 now?

Should we move IPVS out of net/ipv4 now?

[Julius Volz]

Hi,

Since IPVS now does partial IPv6, should we finally move it from
"net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
long time ago, but that was before any of the actual v6 features, so
there was probably no interest.

Also, the tunables in /proc/sys/net/ipv4/vs/... apply to both v4 and
v6. Should we just duplicate them into /proc/sys/net/ipv6/vs? Or will
people be confused that setting a value in one directory changes the
value in the other and affects both IP versions?

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1

Re: Should we move IPVS out of net/ipv4 now?

[Chris Snook]

Julius Volz wrote:
> Since IPVS now does partial IPv6, should we finally move it from
> "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
> long time ago, but that was before any of the actual v6 features, so
> there was probably no interest.

Whatever the netfilter people want is fine with me.

> Also, the tunables in /proc/sys/net/ipv4/vs/... apply to both v4 and
> v6. Should we just duplicate them into /proc/sys/net/ipv6/vs? Or will
> people be confused that setting a value in one directory changes the
> value in the other and affects both IP versions?

If we do any duplication of sysctl tunables under net.ipv4 into net.ipv6, we 
need to follow the same policy for all of them.  Since the tcp tunables in 
net.ipv4 are among the most documented and used, and have been for a decade, we 
need to be conservative with that.  Having two different writable tunables for 
the same variable is certain to confuse.  Having read-only aliases under 
net.ipv6 wouldn't terrify me, but the last time I went to do tcp tuning, and saw 
that the tunables in net.ipv4 weren't duplicated under net.ipv6, it was obvious 
what was going on at first glance, without needing to do an ls -l to figure out 
what was going on.  People who prefer to use sysctl rather than manually 
tweaking pseudofiles might not notice the permissions right away.  By the 
principle of least confusion, I think omitting them entirely is probably the way 
to go.

-- Chris

Re: Should we move IPVS out of net/ipv4 now?

[David Miller]

From: Chris Snook <csnook@redhat.com>
Date: Wed, 17 Sep 2008 14:37:33 -0400

> Julius Volz wrote:
> > Since IPVS now does partial IPv6, should we finally move it from
> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
> > long time ago, but that was before any of the actual v6 features, so
> > there was probably no interest.
> 
> Whatever the netfilter people want is fine with me.

I think, especially in the long term, putting IPVS under net/netfilter/
is the right thing to do.

Re: Should we move IPVS out of net/ipv4 now?

[Simon Horman]

On Wed, Sep 17, 2008 at 02:37:33PM -0400, Chris Snook wrote:
> Julius Volz wrote:
>> Since IPVS now does partial IPv6, should we finally move it from
>> "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
>> long time ago, but that was before any of the actual v6 features, so
>> there was probably no interest.
>
> Whatever the netfilter people want is fine with me.
>
>> Also, the tunables in /proc/sys/net/ipv4/vs/... apply to both v4 and
>> v6. Should we just duplicate them into /proc/sys/net/ipv6/vs? Or will
>> people be confused that setting a value in one directory changes the
>> value in the other and affects both IP versions?
>
> If we do any duplication of sysctl tunables under net.ipv4 into net.ipv6, 
> we need to follow the same policy for all of them.  Since the tcp 
> tunables in net.ipv4 are among the most documented and used, and have 
> been for a decade, we need to be conservative with that.  Having two 
> different writable tunables for the same variable is certain to confuse.  
> Having read-only aliases under net.ipv6 wouldn't terrify me, but the last 
> time I went to do tcp tuning, and saw that the tunables in net.ipv4 
> weren't duplicated under net.ipv6, it was obvious what was going on at 
> first glance, without needing to do an ls -l to figure out what was going 
> on.  People who prefer to use sysctl rather than manually tweaking 
> pseudofiles might not notice the permissions right away.  By the  
> principle of least confusion, I think omitting them entirely is probably 
> the way to go.

If thats a standard practice, than that sounds reasonable to me.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: Should we move IPVS out of net/ipv4 now?

[Julius Volz]

On Wed, Sep 17, 2008 at 10:14 PM, David Miller wrote:
> From: Chris Snook <csnook@redhat.com>
> Date: Wed, 17 Sep 2008 14:37:33 -0400
>
>> Julius Volz wrote:
>> > Since IPVS now does partial IPv6, should we finally move it from
>> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
>> > long time ago, but that was before any of the actual v6 features, so
>> > there was probably no interest.
>>
>> Whatever the netfilter people want is fine with me.
>
> I think, especially in the long term, putting IPVS under net/netfilter/
> is the right thing to do.

Ok thanks, I'll send the patch for that once lvs-next-2.6 or
net-next-2.6 builds for ARCH=um again (there seems to be some breakage
at the moment)...

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1

Re: Should we move IPVS out of net/ipv4 now?

[Julius Volz]

On Thu, Sep 18, 2008 at 6:24 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Sep 17, 2008 at 02:37:33PM -0400, Chris Snook wrote:
>> Julius Volz wrote:
>>> Since IPVS now does partial IPv6, should we finally move it from
>>> "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
>>> long time ago, but that was before any of the actual v6 features, so
>>> there was probably no interest.
>>
>> Whatever the netfilter people want is fine with me.
>>
>>> Also, the tunables in /proc/sys/net/ipv4/vs/... apply to both v4 and
>>> v6. Should we just duplicate them into /proc/sys/net/ipv6/vs? Or will
>>> people be confused that setting a value in one directory changes the
>>> value in the other and affects both IP versions?
>>
>> If we do any duplication of sysctl tunables under net.ipv4 into net.ipv6,
>> we need to follow the same policy for all of them.  Since the tcp
>> tunables in net.ipv4 are among the most documented and used, and have
>> been for a decade, we need to be conservative with that.  Having two
>> different writable tunables for the same variable is certain to confuse.
>> Having read-only aliases under net.ipv6 wouldn't terrify me, but the last
>> time I went to do tcp tuning, and saw that the tunables in net.ipv4
>> weren't duplicated under net.ipv6, it was obvious what was going on at
>> first glance, without needing to do an ls -l to figure out what was going
>> on.  People who prefer to use sysctl rather than manually tweaking
>> pseudofiles might not notice the permissions right away.  By the
>> principle of least confusion, I think omitting them entirely is probably
>> the way to go.
>
> If thats a standard practice, than that sounds reasonable to me.

Ok, so no change for now.

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1

Re: Should we move IPVS out of net/ipv4 now?

[Simon Horman]

On Thu, Sep 18, 2008 at 10:04:28PM +0200, Julius Volz wrote:
> On Wed, Sep 17, 2008 at 10:14 PM, David Miller wrote:
> > From: Chris Snook <csnook@redhat.com>
> > Date: Wed, 17 Sep 2008 14:37:33 -0400
> >
> >> Julius Volz wrote:
> >> > Since IPVS now does partial IPv6, should we finally move it from
> >> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
> >> > long time ago, but that was before any of the actual v6 features, so
> >> > there was probably no interest.
> >>
> >> Whatever the netfilter people want is fine with me.
> >
> > I think, especially in the long term, putting IPVS under net/netfilter/
> > is the right thing to do.
> 
> Ok thanks, I'll send the patch for that once lvs-next-2.6 or
> net-next-2.6 builds for ARCH=um again (there seems to be some breakage
> at the moment)...

Once net-next-2.6 is working again, let me know and I'll pull it
into lvs-next-2.6.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: Should we move IPVS out of net/ipv4 now?

[David Miller]

From: Simon Horman <horms@verge.net.au>
Date: Fri, 19 Sep 2008 09:52:22 +1000

> On Thu, Sep 18, 2008 at 10:04:28PM +0200, Julius Volz wrote:
> > On Wed, Sep 17, 2008 at 10:14 PM, David Miller wrote:
> > > From: Chris Snook <csnook@redhat.com>
> > > Date: Wed, 17 Sep 2008 14:37:33 -0400
> > >
> > >> Julius Volz wrote:
> > >> > Since IPVS now does partial IPv6, should we finally move it from
> > >> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
> > >> > long time ago, but that was before any of the actual v6 features, so
> > >> > there was probably no interest.
> > >>
> > >> Whatever the netfilter people want is fine with me.
> > >
> > > I think, especially in the long term, putting IPVS under net/netfilter/
> > > is the right thing to do.
> > 
> > Ok thanks, I'll send the patch for that once lvs-next-2.6 or
> > net-next-2.6 builds for ARCH=um again (there seems to be some breakage
> > at the moment)...
> 
> Once net-next-2.6 is working again, let me know and I'll pull it
> into lvs-next-2.6.

I can't fix this if people don't tell me what the problem is.

Is there some upstream fix and cures this and all I need to do is
sync net-next-2.6 up with Linus's tree?  Is there some external
fix?

It's totally stupid to stall development because of an issue like this
yet give no direction or diagnostics we can use as a path to resolve
it.

Re: Should we move IPVS out of net/ipv4 now?

[Julius Volz]

On Fri, Sep 19, 2008 at 2:00 AM, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Fri, 19 Sep 2008 09:52:22 +1000
>
>> On Thu, Sep 18, 2008 at 10:04:28PM +0200, Julius Volz wrote:
>> > On Wed, Sep 17, 2008 at 10:14 PM, David Miller wrote:
>> > > From: Chris Snook <csnook@redhat.com>
>> > > Date: Wed, 17 Sep 2008 14:37:33 -0400
>> > >
>> > >> Julius Volz wrote:
>> > >> > Since IPVS now does partial IPv6, should we finally move it from
>> > >> > "net/ipv4/ipvs" to "net" or to "net/netfilter"? I posted that patch a
>> > >> > long time ago, but that was before any of the actual v6 features, so
>> > >> > there was probably no interest.
>> > >>
>> > >> Whatever the netfilter people want is fine with me.
>> > >
>> > > I think, especially in the long term, putting IPVS under net/netfilter/
>> > > is the right thing to do.
>> >
>> > Ok thanks, I'll send the patch for that once lvs-next-2.6 or
>> > net-next-2.6 builds for ARCH=um again (there seems to be some breakage
>> > at the moment)...
>>
>> Once net-next-2.6 is working again, let me know and I'll pull it
>> into lvs-next-2.6.
>
> I can't fix this if people don't tell me what the problem is.

Sorry, I sent this from an environment where I didn't have the
information and just wanted to give a quick ACK on the IPVS move
decision.

The build with ARCH=um seems to have a problem with the
architecture-specific headers:

net/core/skb_dma_map.c: In function 'skb_dma_map':
net/core/skb_dma_map.c:20: error: implicit declaration of function
'dma_mapping_error'

The bad commit that introduces the skb_dma_map.c file (and this error)
is a40c24a1336. Previous versions build fine.

> Is there some upstream fix and cures this and all I need to do is
> sync net-next-2.6 up with Linus's tree?  Is there some external
> fix?

Linus' linux-2.6 (he doesn't have a linux-next-2.6, right?) works, but
that doesn't even contain the file that has the build problem.

> It's totally stupid to stall development because of an issue like this
> yet give no direction or diagnostics we can use as a path to resolve
> it.

Yes, I'll give a better report next time.

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1

Re: Should we move IPVS out of net/ipv4 now?

[David Miller]

From: "Julius Volz" <juliusv@google.com>
Date: Fri, 19 Sep 2008 11:47:13 +0200

> The build with ARCH=um seems to have a problem with the
> architecture-specific headers:
> 
> net/core/skb_dma_map.c: In function 'skb_dma_map':
> net/core/skb_dma_map.c:20: error: implicit declaration of function
> 'dma_mapping_error'
> 
> The bad commit that introduces the skb_dma_map.c file (and this error)
> is a40c24a1336. Previous versions build fine.

I'll commit the following to net-next-2.6, let me know if it doesn't
take care of the problem:

net: Fix build with ARCH=um

If UM is going to claim that it supports DMA by setting
HAS_DMA, it should provide a dma_mapping_error() implementation.

Based upon a report by Julius Volz.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 include/asm-um/dma-mapping.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/asm-um/dma-mapping.h b/include/asm-um/dma-mapping.h
index f0ee4fb..90fc708 100644
--- a/include/asm-um/dma-mapping.h
+++ b/include/asm-um/dma-mapping.h
@@ -118,4 +118,11 @@ dma_cache_sync(struct device *dev, void *vaddr, size_t size,
 	BUG();
 }
 
+static inline int
+dma_mapping_error(struct device *dev, dma_addr_t dma_handle)
+{
+	BUG();
+	return 0;
+}
+
 #endif
-- 
1.5.6.5

Re: Should we move IPVS out of net/ipv4 now?

[Julius Volz]

On Fri, Sep 19, 2008 at 9:45 PM, David Miller <davem@davemloft.net> wrote:
> From: "Julius Volz" <juliusv@google.com>
> Date: Fri, 19 Sep 2008 11:47:13 +0200
>
>> The build with ARCH=um seems to have a problem with the
>> architecture-specific headers:
>>
>> net/core/skb_dma_map.c: In function 'skb_dma_map':
>> net/core/skb_dma_map.c:20: error: implicit declaration of function
>> 'dma_mapping_error'
>>
>> The bad commit that introduces the skb_dma_map.c file (and this error)
>> is a40c24a1336. Previous versions build fine.
>
> I'll commit the following to net-next-2.6, let me know if it doesn't
> take care of the problem:
>
> net: Fix build with ARCH=um
>
> If UM is going to claim that it supports DMA by setting
> HAS_DMA, it should provide a dma_mapping_error() implementation.
>
> Based upon a report by Julius Volz.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  include/asm-um/dma-mapping.h |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/asm-um/dma-mapping.h b/include/asm-um/dma-mapping.h
> index f0ee4fb..90fc708 100644
> --- a/include/asm-um/dma-mapping.h
> +++ b/include/asm-um/dma-mapping.h
> @@ -118,4 +118,11 @@ dma_cache_sync(struct device *dev, void *vaddr, size_t size,
>        BUG();
>  }
>
> +static inline int
> +dma_mapping_error(struct device *dev, dma_addr_t dma_handle)
> +{
> +       BUG();
> +       return 0;
> +}
> +
>  #endif
> --

Thanks, that got rid of the problem!

Julius

-- 
Julius Volz - Corporate Operations - SysOps

Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1