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

Slava Ovsiienko viacheslavo at nvidia.com
Thu Oct 15 09:43:43 CEST 2020


Hi, Jerin

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Wednesday, October 14, 2020 21:57
> To: Slava Ovsiienko <viacheslavo at nvidia.com>
> Cc: dpdk-dev <dev at dpdk.org>; NBU-Contact-Thomas Monjalon
> <thomas at monjalon.net>; Stephen Hemminger
> <stephen at networkplumber.org>; Ferruh Yigit <ferruh.yigit at intel.com>;
> Olivier Matz <olivier.matz at 6wind.com>; Maxime Coquelin
> <maxime.coquelin at redhat.com>; David Marchand
> <david.marchand at redhat.com>; Andrew Rybchenko
> <arybchenko at solarflare.com>
> Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split
> 
> On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko
> <viacheslavo at nvidia.com> wrote:
> >
> > The DPDK datapath in the transmit direction is very flexible.
> > An application can build the multi-segment packet and manages almost
> > all data aspects - the memory pools where segments are allocated from,
> > the segment lengths, the memory attributes like external buffers,
> > registered for DMA, etc.
> >

[..snip..]

> > For example, let's suppose we configured the Rx queue with the
> > following segments:
> >     seg0 - pool0, len0=14B, off0=2
> >     seg1 - pool1, len1=20B, off1=128B
> >     seg2 - pool2, len2=20B, off2=0B
> >     seg3 - pool3, len3=512B, off3=0B
> 
> 
> Sorry for chime in late. This API lookout looks good to me.
> But, I am wondering how the application can know the capability or "limits" of
> struct rte_eth_rxseg structure for the specific PMD. The other descriptor limit,
> it's being exposed with struct rte_eth_dev_info::rx_desc_lim; If PMD can
> support a specific pattern rather than returning the blanket error, the
> application should know the limit.
> IMO, it is better to add
> struct rte_eth_rxseg *rxsegs;
> unint16_t nb_max_rxsegs
> in rte_eth_dev_info structure to express the capablity.
> Where the en and offset can define the max offset.
> 
> Thoughts?

Moreover, there might be implied a lot of various limitations - offsets might be not supported at all or
have some requirements for alignment, the similar requirements might be applied to segment size
(say, ask for some granularity). Currently it is not obvious how to report all nuances, and it is supposed
the limitations of this kind must be documented in PMD chapter. As for mlx5 - it has no special
limitations besides common requirements to the regular segments.

One more point - the split feature might be considered as just one of possible cases of using
these segment descriptions, other features might impose other (unknown for now) limitations.
If we see some of the features of such kind or other PMDs adopts the split feature - we'll try to find
the common root and consider the way how to report it.

With best regards, Slava



More information about the dev mailing list