Hello On Thursday 28 October 2010 13:35:12 Simon Horman wrote: > On Wed, Oct 27, 2010 at 10:58:31PM +0300, Julian Anastasov wrote: > > > > Hello, > > > > On Wed, 27 Oct 2010, Hans Schillstrom wrote: > > > > >>A New Spec of Type field: > > >> > > >>Bit 7 6 . . . 2 1 0 > > >> +----------+--------------------------+-------------+-------+ > > >> | Opt.Data | Spare | Packed IPv6 | IPv6 | > > >> +----------+--------------------------+-------------+-------+ > > > > > >I can see a better usage of it in Option Type so Type will look like this > > > +-------------------------------------+-------------+-------+ > > > | Spare | Packed IPv6 | IPv6 | > > > +-------------------------------------+-------------+-------+ > > > > > >And "Option Type" in option field would look like this > > > > > >Bit 7 6 . . . 0 7 0 > > > +----------+----------------------+---------------------------+ > > > | Optional | Option type | Option length | > > > +----------+----------------------+---------------------------+ > > 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. > I have PE_NAME and PE_DATA ass different options so the limit is actually 255 bytes. #define IPVS_OPT_SEQ_DATA 1 #define IPVS_OPT_PE_DATA 2 #define IPVS_OPT_PE_NAME 3 How ever they are not independant of each other. - PE_NAME never goes alone, only if there is PE_DATA. - In the receiving path, PE_NAME must have PE_DATA to be valid. > > >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. Backward compatibility is "one way only" a new backup daemon can listen to an old one not the other way around. > > That said, I agree that allocating 1 bit isn't a show-stopper. > > -- Regards Hans Schillstrom <hans.schillstrom@xxxxxxxxxxxx> -- 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
