All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Julius Volz <juliusv@google.com>
Cc: netdev@vger.kernel.org, lvs-devel@vger.kernel.org,
	kaber@trash.net, vbusam@google.com,
	Sven Wegener <sven.wegener@stealer.net>
Subject: Re: [PATCH RFC 00/24] IPVS: Add first IPv6 support to IPVS
Date: Wed, 27 Aug 2008 15:59:26 +1000	[thread overview]
Message-ID: <20080827055924.GA3816@verge.net.au> (raw)
In-Reply-To: <f4845fc0808211501y188b0ae9ie7aacb2f52c3dcd8@mail.gmail.com>

On Fri, Aug 22, 2008 at 12:01:19AM +0200, Julius Volz wrote:
> On Thu, Aug 21, 2008 at 11:29 PM, Simon Horman <horms@verge.net.au> wrote:
> > On Thu, Aug 21, 2008 at 11:59:44AM +0200, Julius Volz wrote:
> >> There shouldn't be any fundamental restrictions, it's just a piece of
> >> the puzzle that I could easily leave out of the picture for now.
> >>
> >> I haven't studied the sync daemon closely yet, but one thing I was
> >> briefly wondering about was whether we should just blow up the
> >> addresses in struct ip_vs_sync_conn to be of type union nf_inet_addr
> >> (probably not acceptable, wasting too much bandwidth for v4 entries)
> >> or how to send differently sized entries based on the IP version in a
> >> clean way. But it sounds like you'd want to redesign a lot of that
> >> anyways? I'm glad to help with anything, I just don't know this code
> >> as well as you or Sven, but I'll study it more. Maybe you can share
> >> some ideas on the extensibility you want to see?
> >
> > What I was thinking is that any change
> 
> Hm, I think you forgot to finish this sentence ;)
> 
> > Here are a few thoughts I have had in my breif overview of the code so far
> > - mainly just simple style things. If any of my comments are obviously
> > stupid, please just say so as I haven't got to the end of the series yet
> > and I'm sure some of my questions are answered in the code.
> 
> Thanks for looking at this, no problem. I know it's a bit much to
> digest, but I think there is no smaller part that I could post that is
> useful in itself already.
> 
> > [PATCH RFC 01/24] IPVS: Add genetlink interface definitions to ip_vs.h
> > [PATCH RFC 02/24] IPVS: Add genetlink interface implementation
> >
> > * Already in lvs-2.6. Are there any changes?
> 
> No, those are just exactly what I sent you before. I included them
> because I was basing it on net-2.6.
> 
> Btw., David just announced that he opened net-next-2.6, so perhaps he
> could pull the changes from your tree into that now?

Yes, I hope so.

> > [PATCH RFC 02/24] IPVS: Add genetlink interface implementation
> >
> > * What is IP_VS = IPV6 ?
> 
> (IPV6 = y || IP_VS = IPV6) means that this option will only be visible
> if either CONFIG_IPV6 is set to Y or if both CONFIG_IPV6 and
> CONFIG_IP_VS are modules (if both are off, the whole submenu will be
> hidden). So CONFIG_IPV6 has to be set at least as high as CONFIG_IP_VS
> for this option to be visible.

Thanks, that was confusing me.

> > [PATCH RFC 04/24] IPVS: Change IPVS data structures to support IPv6 addresses
> >
> > * Indentation of af in struct ip_vs_conn seems inconsistent with other
> >  elements.
> 
> Yeah, it's broken like this in the original and I kept it like that so
> that things would still line up (because I didn't want to add noise by
> touching the neighboring lines just for whitespace fixes). I could
> just send a small whitespace fix to you before.

Ok

> > [PATCH RFC 05/24] IPVS: Add general v4/v6 helper functions / data structures
> >
> > * Use of p ? a : b construct in ip_vs_addr_equal() seems a bit aquard.
> >  How about
> >
> > static inline int ip_vs_addr_equal(int af, const union nf_inet_addr *a,
> >                                   const union nf_inet_addr *b)
> > {
> > #ifdef CONFIG_IP_VS_IPV6
> >        if (af == AF_INET)
> >                return ipv6_addr_equal(&a->in6, &b->in6);
> > #endif
> >        return a->ip == b->ip;
> > }
> 
> Right, that is nicer! With AF_INET6 in that if-condition, of course.

Yeah, of course, I meant AF_INET6.

  reply	other threads:[~2008-08-27  5:59 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-20 16:15 [PATCH RFC 00/24] IPVS: Add first IPv6 support to IPVS Julius Volz
2008-08-20 16:15 ` [PATCH RFC 01/24] IPVS: Add genetlink interface definitions to ip_vs.h Julius Volz
2008-08-20 16:15 ` [PATCH RFC 02/24] IPVS: Add genetlink interface implementation Julius Volz
2008-08-20 16:15 ` [PATCH RFC 03/24] IPVS: Add CONFIG_IP_VS_IPV6 option for IPv6 support Julius Volz
2008-08-20 16:15 ` [PATCH RFC 04/24] IPVS: Change IPVS data structures to support IPv6 addresses Julius Volz
2008-08-20 16:15 ` [PATCH RFC 05/24] IPVS: Add general v4/v6 helper functions / data structures Julius Volz
2008-08-20 16:15 ` [PATCH RFC 06/24] IPVS: Add debug macros for v4 and v6 address output Julius Volz
2008-08-20 16:15 ` [PATCH RFC 07/24] IPVS: Convert existing debug uses to use new macros Julius Volz
2008-08-20 16:15 ` [PATCH RFC 08/24] IPVS: Make protocol handler functions support IPv6 Julius Volz
2008-08-21 13:29   ` Brian Haley
2008-08-21 13:52     ` Julius Volz
2008-08-21 14:08       ` Brian Haley
2008-08-21 14:55         ` Julius Volz
2008-08-21 15:12           ` Brian Haley
2008-08-21 15:28             ` Julius Volz
2008-08-20 16:15 ` [PATCH RFC 09/24] IPVS: Add IPv6 Netfilter hooks and add/modify support functions Julius Volz
2008-08-20 16:15 ` [PATCH RFC 10/24] IPVS: Extend scheduling functions for IPv6 support Julius Volz
2008-08-27  6:28   ` Simon Horman
2008-08-27 16:02     ` Julius Volz
2008-08-20 16:15 ` [PATCH RFC 11/24] IPVS: Add IPv6 xmit functions Julius Volz
2008-08-20 16:15 ` [PATCH RFC 12/24] IPVS: Extend functions for getting/creating connections Julius Volz
2008-08-20 16:15 ` [PATCH RFC 13/24] IPVS: Add IPv6 support to ip_vs_conn_hashkey() Julius Volz
2008-08-20 16:15 ` [PATCH RFC 14/24] IPVS: Turn off FTP application helper for IPv6 Julius Volz
2008-08-20 16:15 ` [PATCH RFC 15/24] IPVS: Add support for IPv6 entry output in procfs files Julius Volz
2008-08-20 16:15 ` [PATCH RFC 16/24] IPVS: Add function to determine if IPv6 address is local Julius Volz
2008-08-20 16:15 ` [PATCH RFC 17/24] IPVS: Make proc/net files output IPv6 entries correctly Julius Volz
2008-08-20 16:15 ` [PATCH RFC 18/24] IPVS: Convert dest/service lookup functions Julius Volz
2008-08-20 16:15 ` [PATCH RFC 19/24] IPVS: Add IPv6 support flag to schedulers Julius Volz
2008-08-21  1:48   ` Simon Horman
2008-08-21 10:21     ` Julius Volz
2008-08-21 13:23       ` Simon Horman
2008-08-20 16:15 ` [PATCH RFC 20/24] IPVS: Add validity checks when adding/editing v6 services Julius Volz
2008-08-20 16:15 ` [PATCH RFC 21/24] IPVS: Only expose IPv4 entries through sockopt interface Julius Volz
2008-08-20 16:15 ` [PATCH RFC 22/24] IPVS: Add IPv6 support to genetlink interface Julius Volz
2008-08-20 16:15 ` [PATCH RFC 23/24] IPVS: Small address/af usage fixups Julius Volz
2008-08-20 16:15 ` [PATCH RFC 24/24] IPVS: Add notes about IPv6 changes Julius Volz
2008-08-21  1:17 ` [PATCH RFC 00/24] IPVS: Add first IPv6 support to IPVS Simon Horman
2008-08-21  9:59   ` Julius Volz
2008-08-21 21:29     ` Simon Horman
2008-08-21 22:01       ` Julius Volz
2008-08-27  5:59         ` Simon Horman [this message]
2008-08-21 22:05       ` Simon Horman
2008-08-22  9:56         ` Julius Volz
2008-08-22 10:05           ` Graeme Fowler
2008-08-22 10:49             ` Julius Volz
2008-08-22 11:23               ` Sven Wegener
2008-08-22 12:14                 ` Julius Volz
2008-08-23  9:20                   ` Graeme Fowler
2008-08-23 15:22                     ` Joseph Mack NA3T
2008-08-23 16:31                       ` Graeme Fowler
2008-08-24  2:13                         ` Joseph Mack NA3T
2008-08-23 23:07                       ` Julius Volz
2008-08-24  1:40                         ` Joseph Mack NA3T
2008-08-27  6:09                   ` Simon Horman
2008-08-27 15:24                     ` Julius Volz
2008-08-27 23:49                       ` Simon Horman
2008-08-27  7:17       ` Simon Horman
2008-08-27 15:09         ` Julius Volz
2008-08-27 23:48           ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080827055924.GA3816@verge.net.au \
    --to=horms@verge.net.au \
    --cc=juliusv@google.com \
    --cc=kaber@trash.net \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sven.wegener@stealer.net \
    --cc=vbusam@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.