From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS. Date: Wed, 18 Jun 2008 10:57:03 +0200 Message-ID: <4858CDDF.4050306@trash.net> References: <20080613062621.GA10474@verge.net.au> <48528EED.7090307@trash.net> <485652EA.2020004@trash.net> <4857A58E.6080304@trash.net> <20080617171840.GB4064@google.com> <485819A8.1090004@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Simon Horman , Vince Busam , Ben Greear , lvs-devel@vger.kernel.org, netdev@vger.kernel.org To: Julius Volz Return-path: In-Reply-To: Sender: lvs-devel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Julius Volz wrote: > On Tue, Jun 17, 2008 at 10:08 PM, Patrick McHardy wrote: > >> IPVS_LIST_ELEM - NLA_NESTED >> >> for list elements of every kind. Since you can only put one >> kind of element in the lists anyway (I think), different >> types don't allow any increased flexibility and the LIST >> naming is more clear in my opinion. >> > > However, since these container attributes (for daemons, services and > dests) also appear as single elements outside of lists, it might be > better to reuse the same names inside the list? > I didn't realize that. Yes, agreed. >>> IPVS_SVC_ATTR_FLAGS - NLA_U32 >>> >> As I mentioned above, you usually want a MASK in combination >> with flags to allow to unset them. This is best done using >> a structure. >> > > Hm, I'm not sure if I understand exactly what this struct is supposed > to look like. Could you give an example? > struct { u32 flags; u32 mask; } flags; and then: obj->flags = (obj->flags & ~flags->mask) | (flags->flags | flags->mask); >>> IPVS_SVC_ATTR_TIMEOUT - NLA_U32 >>> IPVS_SVC_ATTR_NETMASK - NLA_U32 >>> >> Shouldn't this also be able to carry IPv6 masks? >> > > We only need the prefix length for IPv6, for which we reused the > netmask field. This (only slightly) changes the semantics of the field > between address families. Acceptable or better have a separate field > for the prefix length? > I guess thats fine. >>> IPVS_SVC_ATTR_NUM_DESTS - NLA_U32 >>> >> Is this number related to the IPVS_ENTRY_ATTR_DESTS list? >> If so, it shouldn't be contained as seperate attribute, >> that just allows for potential inconsistency. >> > > Yes, but this count is only returned from commands that do not at the > same time return the list of destinations, so there is no > inconsistency within a message. However, I'm pretty sure the count was > only used in the old interface to allocate enough memory for the > destination list, so it can probably be deleted anyways. > You're probably right, this looks similar to iptables.