On Tue, Oct 09, 2018 at 10:28:28AM +0000, Ashvin Lakshmikantha wrote: > In this specific case, it appears that the original design of > the data structure is inconsistent with RFC 4861. The RFC 4861 mandates the > ND message to be of the following type: > > > > [cid:[email protected]] > > > > > > Continuing, the options field have the following data structure: > > > > [cid:[email protected]] > > > > > > However, if we look at the ovs_nd_key data structure, it appears like this: > > > > struct ovs_key_nd { > > __be32 nd_target[4]; > > __u8 nd_sll[ETH_ALEN]; > > __u8 nd_tll[ETH_ALEN]; > > }; > > > > A ND message DOES NOT have both ND_SLL and ND_TLL fields. It most commonly > has only one of them. Also, a ND message has a RESERVED field (4 Bytes) and > Type/Length of Options (2 Bytes). > > > > In the original design, the author has removed RESERVED/Type/Length fields > from ovs_nd_key and replaced it with an extra ND_TLL field. This is incorrect. > > > > Our proposal fixes the original design and in addition provides a new > capability to modify RESERVED field and Type Field.
The "key" structures do not exactly mirror the headers themselves. No matter what you want, you can't break the existing ABI. Period. Find another way. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
