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.richard...@intel.com> wrote: > > From: Kevin Laatz <[2]kevin.la...@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
