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

[Pai G, Sunil]

Hi Jerin,  

<snipped>

> > >      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.

Yes, this is true. We want to avoid scenarios where only parts of packets could be enqueued.

> 
> Sorry for the delay in reply.
> 
> If so, why do we need this API. We can mark a logical transaction completed
> IFF final segment is succeeded. Since this fastpath API, I would like to really
> understand the real use case for it, so if required then we need to
> implement in an optimized way.
> Otherwise driver does not need to implement this to have generic solution
> for all the drivers.
> 
> >
> > >    # 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.
> 
> See above.
> 
> Sunil. Jiayu, Could you share the details on the usage and why it is needed.

Here is an example of how the burst capacity API will be potentially used in the app(OVS):
http://patchwork.ozlabs.org/project/openvswitch/patch/20210907120021.4093604-2-sunil.pai.g@intel.com/
Although commented out , it should still provide an idea of its usage.

Thanks and regards,
Sunil