On Thu, Jul 18, 2019 at 03:09:10PM -0700, Stephen Hemminger wrote: > Tell users about upcoming changes to rte_ether_addr and > rte_ether_header. > > Signed-off-by: Stephen Hemminger <step...@networkplumber.org> > --- > doc/guides/rel_notes/deprecation.rst | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index a7796f49b9fe..9c20a47b3e4c 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -82,3 +82,12 @@ Deprecation Notices > to set new power environment if power environment was already initialized. > In this case the function will return -1 unless the environment is unset > first > (using ``rte_power_unset_env``). Other function usage scenarios will not > change. > + > +* net: the Ethernet address and header defintions will change attributes. > + The Ethernet address struct will no longer be marked as packed since > + since the packed attribute is meaningless on a byte array. > + The Etherne header will be marked as aligned on a 2 byte boundary (and > + no longer packed). This allows for efficient access on all CPU's. > + These changes should not impact normal usage drivers naturally > + align the Ethernet header on receive, and almost every encapsulation > + preserves the alignment. > -- > 2.17.1
More comprehensive deprecation notice than mine, so: Acked-by: Bruce Richardson <bruce.richard...@intel.com> One suggested change, rather than "almost every encapsulation" can we put it down as "all known encapsulations". If there is even a single public spec, in-real-use encapsulation that is used that does not preserve alignment, we should not do this. Saying "almost every" implies that we know of ones that don't, which I don't believe is the case. /Bruce
