> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Friday, October 16, 2020 12:37
> To: Andrew Rybchenko <arybche...@solarflare.com>; Slava Ovsiienko
> <viachesl...@nvidia.com>
> Cc: dev@dpdk.org; step...@networkplumber.org; ferruh.yi...@intel.com;
> olivier.m...@6wind.com; jerinjac...@gmail.com;
> maxime.coque...@redhat.com; david.march...@redhat.com
> Subject: Re: [PATCH v8 1/6] ethdev: introduce Rx buffer split
>
> 16/10/2020 11:15, Slava Ovsiienko:
> > From: Andrew Rybchenko <arybche...@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.
