On Fri, 4 Mar 2022 09:58:11 +0000
"Zhang, Qi Z" <qi.z.zh...@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger <step...@networkplumber.org>
> > Sent: Friday, March 4, 2022 12:16 AM
> > To: Ding, Xuan <xuan.d...@intel.com>
> > Cc: tho...@monjalon.net; Yigit, Ferruh <ferruh.yi...@intel.com>;
> > andrew.rybche...@oktetlabs.ru; dev@dpdk.org; viachesl...@nvidia.com;
> > Zhang, Qi Z <qi.z.zh...@intel.com>; Yu, Ping <ping...@intel.com>; Wang,
> > YuanX <yuanx.w...@intel.com>
> > Subject: Re: [RFC] ethdev: introduce protocol type based header split
> >
> > On Thu, 3 Mar 2022 06:01:36 +0000
> > xuan.d...@intel.com wrote:
> >
> > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > > c2d1f9a972..6743648c22 100644
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1202,7 +1202,8 @@ struct rte_eth_rxseg_split {
> > > struct rte_mempool *mp; /**< Memory pool to allocate segment from.
> > */
> > > uint16_t length; /**< Segment data length, configures split point. */
> > > uint16_t offset; /**< Data offset from beginning of mbuf data buffer. */
> > > - uint32_t reserved; /**< Reserved field. */
> > > + uint16_t proto;
> > > + uint16_t reserved; /**< Reserved field. */
> > > };
> >
> > This feature suffers from a common bad design pattern.
> > You can't just start using reserved fields unless the previous versions
> > enforced
> > that the field was a particular value (usually zero).
>
> Yes, agree, that's a mistake there is no document for the reserved field in
> the previous release, and usually, it should be zero,
> And I think one of the typical purposes of the reserved field is to make life
> easy for new feature adding without breaking ABI.
> So, should we just take the risk as I guess it might not be a big deal in
> real cases?
There is a cost/benefit tradeoff here. Although HW vendors would like to enable
more features, it really is not that much of an impact to wait until next LTS
for users.
Yes, the API/ABI rules are restrictive, but IMHO it is about learning how to
handle SW upgrades in a more user friendly manner. It was hard for the Linux
kernel to learn how to do this, but after 10 years they mostly have it right.
If this were a bug (especially a security bug), then the rules could be lifted.
