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.pa...@intel.com/ Although commented out , it should still provide an idea of its usage. Thanks and regards, Sunil
