[RFC] ethdev: introduce protocol type based header split

[Stephen Hemminger]

On Fri, 4 Mar 2022 09:58:11 +0000
"Zhang, Qi Z" <qi.z.zhang at intel.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger <stephen at networkplumber.org>
> > Sent: Friday, March 4, 2022 12:16 AM
> > To: Ding, Xuan <xuan.ding at intel.com>
> > Cc: thomas at monjalon.net; Yigit, Ferruh <ferruh.yigit at intel.com>;
> > andrew.rybchenko at oktetlabs.ru; dev at dpdk.org; viacheslavo at nvidia.com;
> > Zhang, Qi Z <qi.z.zhang at intel.com>; Yu, Ping <ping.yu at intel.com>; Wang,
> > YuanX <yuanx.wang at intel.com>
> > Subject: Re: [RFC] ethdev: introduce protocol type based header split
> > 
> > On Thu,  3 Mar 2022 06:01:36 +0000
> > xuan.ding at 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.