LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [RFC PATCH 0/4] IPVS: Backup Adding Ipv6 and Persistence support

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [RFC PATCH 0/4] IPVS: Backup Adding Ipv6 and Persistence support
Cc: Hans Schillstrom <hans.schillstrom@xxxxxxxxxxxx>, "wensong@xxxxxxxxxxxx" <wensong@xxxxxxxxxxxx>, "lvs-devel@xxxxxxxxxxxxxxx" <lvs-devel@xxxxxxxxxxxxxxx>, Daniel Lezcano <daniel.lezcano@xxxxxxx>
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Sat, 30 Oct 2010 14:22:14 +0900
On Fri, Oct 29, 2010 at 12:07:30AM +0300, Julian Anastasov wrote:
> 
>       Hello,
> 
> On Thu, 28 Oct 2010, Simon Horman wrote:
> 
> >As it stands a little more than 256 bytes may be needed for
> >pe_data (+ pe_name_length + pe_name). This could be resolved by
> >shortening the maximum pe_data length. Or perhaps we could use 16 bytes for
> >Option length, which should ensure its never too small.
> >
> >The 256 byte limit that I made for pe_data was arbitrarily chosen.
> 
>       Yes, this is a problem.
> 
> >>>We can have a better fine tuning of options in this way.
> >>
> >>    Yes, that is exactly my idea. I more like the name
> >>"Parameter" instead of "Option", i.e. we have additional
> >>parameters that can be mandatory (usually) but also can be
> >>optional. For now I don't have idea for any optional
> >>parameters but allocating 1 bit for this does not look
> >>fatal.
> >
> >I'm not sure I understand the motivation for optional parameters.
> >I think its important to allow for backwards compatibility. But
> >I don't see that there will be multiple independent implementations
> >of the synchronisation daemon in the near future. So the use-case
> >isn't clear to me.
> 
>       If we want to support optional parameters they
> must have some known length field, 16 bits if needed.

At this point I see no strong reason to support optional parameters.

> But if we don't want such optional parameters then
> we can just use single octet for parameter type
> which can imply the length of the following data. Types that have
> data with variable length should provide
> 1 or 2 octets after the parameter type for their length.
>
> So, the parsing should be per-type. If one day
> we need optional parameters we can just add 1 octet for
> type and 2 for length before data.
> 
>       For example, ip_vs_sync_conn_options if implemented
> as parameter can be coded with 1 octet for type and the
> following data structure. OTOH, PE params can use 1 octet
> for type, 2 for length (read with get_unaligned_be16) and
> then data.

Agreed.

With such a scheme it would be possible to have pe_data and pe_name
as a single type - but two types is also fine by me.
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>