On Thu, Oct 15, 2020 at 1:13 PM Slava Ovsiienko <viachesl...@nvidia.com> wrote: > > Hi, Jerin
Hi Slava, > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: Wednesday, October 14, 2020 21:57 > > To: Slava Ovsiienko <viachesl...@nvidia.com> > > Cc: dpdk-dev <dev@dpdk.org>; NBU-Contact-Thomas Monjalon > > <tho...@monjalon.net>; Stephen Hemminger > > <step...@networkplumber.org>; Ferruh Yigit <ferruh.yi...@intel.com>; > > Olivier Matz <olivier.m...@6wind.com>; Maxime Coquelin > > <maxime.coque...@redhat.com>; David Marchand > > <david.march...@redhat.com>; Andrew Rybchenko > > <arybche...@solarflare.com> > > Subject: Re: [PATCH v6 1/6] ethdev: introduce Rx buffer split > > > > On Wed, Oct 14, 2020 at 11:42 PM Viacheslav Ovsiienko > > <viachesl...@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. Reporting the limitation in the documentation will not help for the generic applications. > > 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. My only concern with that approach will be ABI break again if something needs to exposed over rte_eth_dev_info(). IMO, if we featured needs to completed only when its capabilities are exposed in a programmatic manner. As of mlx5, if there not limitation then info rte_eth_dev_info::rxsegs[x].len, offset etc as UINT16_MAX so that application is aware of the state. > > With best regards, Slava >
