[dpdk-dev] [PATCH v8 1/6] ethdev: introduce Rx buffer split

[Slava Ovsiienko]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Friday, October 16, 2020 12:37
> To: Andrew Rybchenko <arybchenko at solarflare.com>; Slava Ovsiienko
> <viacheslavo at nvidia.com>
> Cc: dev at dpdk.org; stephen at networkplumber.org; ferruh.yigit at intel.com;
> olivier.matz at 6wind.com; jerinjacobk at gmail.com;
> maxime.coquelin at redhat.com; david.marchand at redhat.com
> Subject: Re: [PATCH v8 1/6] ethdev: introduce Rx buffer split
> 
> 16/10/2020 11:15, Slava Ovsiienko:
> > From: Andrew Rybchenko <arybchenko at solarflare.com>
> > > On 10/16/20 10:48 AM, Viacheslav Ovsiienko wrote:
> > > >  /**
> > > > + * Ethernet device Rx buffer segmentation capabilities.
> > > > + */
> > > > +__extension__
> > > > +struct rte_eth_rxseg_capa {
> > > > +	uint16_t max_seg; /**< Maximum amount of segments to split. */
> > >
> > > May be 'max_segs' to avoid confusing vs maximum segment length.
> > >
> > OK, max_nseg would be more appropriate.
> >
> > > > +	uint16_t multi_pools:1; /**< Supports receiving to multiple pools.*/
> > > > +	uint16_t offset_allowed:1; /**< Supports buffer offsets. */
> > > > +	uint16_t offset_align_log2:4; /**< Required offset alignment. */
> > >
> > > 4 bits are even insufficient to specify cache-line alignment.
> > > IMHO at least 8 bits are required.
> >
> > 4 bits seems to be quite sufficient. It is a log2, tells how many lsbs in offset
> should be zeroes.
> > 2^15 is 32K, it covers all reasonable alignments for uint16_t type.
> 
> bitfields with uint16_t is not standard I think, we could experience build issues.
> If I remember well uint32_t is safer.
> 
Agree, it is being replaced with uint32_t and embraces max_nseg as well.