Re: [PATCH] bonding: Always assign be16 value to vlan_proto

[Vladimir Oltean <olteanv@gmail.com>]

On Fri, Apr 21, 2023 at 09:01:34AM +0200, Simon Horman wrote:
> Hi Jay and Vladimir,
> 
> Thanks for your review.
> 
> Firstly, sorry for the distraction about the VLAN_N_VID math.  I agree it
> was incorrect. I had an out by one bug in my thought process which was
> about 0x0fff instead of 0x1000.
> 
> Secondly, sorry for missing the central issue that it is a bit weird
> to use a VID related value as a sentinel for a protocol field.
> I agree it would be best to chose a different value.
> 
> In reference to the list of EtherTypes [1]. I think 0 might be ok,
> but perhaps not ideal as technically it means a value of 0 for the
> IEEE802.3 Length Field (although perhaps it can never mean that in this
> context).
> 
> OTOH, 0xffff, is 'reserved' ([1] references RFC1701 [2]),
> so perhaps it is a good choice.
> 
> In any case, I'm open to suggestions.
> I'll probably hold off until the v6.5 cycle before reposting,
> unless -rc8 appears next week. I'd rather not rush this one
> given that I seem to have already got it wrong once.
> 
> [1] https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1
> [2] https://www.rfc-editor.org/rfc/rfc1701.html

Any value would work as long as it's not a valid VLAN protocol.
I would #define BOND_VLAN_PROTO_NONE htons(0xffff) and use that.