[dpdk-dev] [PATCH v3 2/8] dmadev: add burst capacity API

[Bruce Richardson]

On Wed, Sep 08, 2021 at 11:47:59PM +0530, Jerin Jacob wrote:
>    On Tue, 7 Sep 2021, 10:25 pm Bruce Richardson,
>    <[1]bruce.richardson at intel.com> wrote:
> 
>      From: Kevin Laatz <[2]kevin.laatz at intel.com>
>      Add a burst capacity check API to the dmadev library. This API is
>      useful to
>      applications which need to how many descriptors can be enqueued in
>      the
>      current batch. For example, it could be used to determine whether
>      all
>      segments of a multi-segment packet can be enqueued in the same batch
>      or not
>      (to avoid half-offload of the packet).
> 
>     #Could you share more details on the use case with vhost?
>    # Are they planning to use this in fast path if so it need to move as
>    fast path function pointer?

I believe the intent is to use it on fastpath, but I would assume only once
per burst, so the penalty for non-fastpath may be acceptable. As you point
out - for an app that really doesn't want to have to pay that penalty,
tracking ring use itself is possible.

The desire for fast-path use is also why I suggested having the space as an
optional return parameter from the submit API call. It could logically also
be a return value from the "completed" call, which might actually make more
sense.

>    # Assume the use case needs N rte_dma_copy to complete a logical copy
>    at vhost level. Is the any issue in half-offload, meaning when N th one
>    successfully completed then only the logical copy is completed. Right?

Yes, as I understand it, the issue is for multi-segment packets, where we
only want to enqueue the first segment if we know we will success with the
final one too.

>    # There is already nb_desc with which a dma_queue is configured. So if
>    the application does its accounting properly, it knows how many desc it
>    has used up and how many completions it has processed.

Agreed. It's just more work for the app, and for simplicity and
completeness I think we should add this API. Because there are other
options I think it should be available, but not as a fast-path fn (though
again, the difference is likely very small for something not called for
every enqueue).

>    Would like to understand more details on this API usage.
> 
Adding Sunil and Jiayu on CC who are looking at this area from the OVS and
vhost sides.

/Bruce