On Tue, Sep 21, 2021 at 7:46 PM Pai G, Sunil <sunil.pa...@intel.com> wrote:
>
> Hi Jerin,
Hi Sunil,
>
> > > > > > 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.
> > > >
> > > > 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.
> >
> >
> > Hi Jiayu, Sunil,
> >
> > > The fact is that it's very hard for apps to calculate the available
> > > space of a
> > DMA ring.
> >
> > Yes, I agree.
> >
> > My question is more why to calculate the space per burst and introduce yet
> > another fastpath API.
> > For example, the application needs to copy 8 segments to complete a logical
> > copy in the application perspective.
> > In case, when 8th copy is completed then only the application marks the
> > logical copy completed.
> > i.e why to check per burst, 8 segments are available or not? Even it is
> > available, there may be multiple reasons why any of the segment copies can
> > fail. So the application needs to track all the jobs completed or not
> > anyway.
> > Am I missing something in terms of vhost or OVS usage?
> >
>
> For the packets that do not entirely fit in the DMA ring , we have a SW copy
> fallback in place.
> So, we would like to avoid scenario caused because of DMA ring full where few
> parts of the packet are copied through DMA and other parts by CPU.
> Besides, this API would also help improve debuggability/device introspection
> to check the occupancy rather than the app having to manually track the state
> of every DMA device in use.
To understand it better, Could you share more details on feedback
mechanism on your application enqueue
app_enqueue_v1(.., nb_seg)
{
/* Not enough space, Let application handle it by
dropping or resubmitting */
if (rte_dmadev_burst_capacity() < nb_seg)
return -ENOSPC;
do rte_dma_op() in loop without checking error;
return 0; // Success
}
vs
app_enqueue_v2(.., nb_seg)
{
int rc;
rc |= rte_dma_op() in loop without checking error;
return rc; // return the actual status to application if
Not enough space, Let application handle it by dropping or
resubmitting */
}
Is app_enqueue_v1() and app_enqueue_v2() logically the same from
application PoV. Right?
If not, could you explain, the version you are planning to do for app_enqueue()
> Copying from other thread:
>
> > What are those scenarios, could you share some descriptions of them.
> > What if the final or any segment fails event the space is available.
> > So you have to take care of that anyway. RIght?
>
> I think this is app dependent no? The application can choose not to take
> care of such scenarios and treat the packets as dropped.
> Ring full scenarios(-ENOSPC from rte_dma_copy) could be avoided with this API
> but other errors mean a failure which unfortunately cannot be avoided.
>
> >
> > > For DSA, the available space is decided by three factors: the number
> > > of available slots in SW ring, the max batching size of a batch
> > > descriptor, and if there are available batch descriptors. The first
> > > one is configured by SW, and apps can calculate it. But the second depends
> > on DSA HW, and the third one is hided in DSA driver which is not visible to
> > apps.
> > > Considering the complexity of different DMA HW, I think the best way
> > > is to hide all details inside DMA dev and provide this check capacity API
> > > for
> > apps.
> > >
> > > Thanks,
> > > Jiayu
> > >
> > > >
> > > > >
> > > > > > # 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.
> > > >
> > > >
> > > > >
> > > > > /Bruce
