On Tue, Sep 21, 2021 at 9:05 PM Pai G, Sunil <sunil.pa...@intel.com> wrote:
>
> Hi Jerin,
>
> <snipped>
>
> > > > > 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()
>
> The exact version can be found here :
> http://patchwork.ozlabs.org/project/openvswitch/patch/20210907120021.4093604-2-sunil.pa...@intel.com/
> Unfortunately, both versions are not same in our case because of the SW
> fallback we have for ring full scenario's.
> For a packet with 8 nb_segs, if the ring has only space for 4 , we would
> avoid this packet with app_enqueue_v1
> while going ahead with an enqueue with app_enqueue_v2, resulting in a mix of
> DMA and CPU copies for a packet which we would want to avoid.
Thanks for RFC link. Usage is clear now, Since you are checking the
space in the completion handler, I am not sure, what is hard to get
the remaining space,
Will following logic work to find the empty space. If not, please
discuss the issue with this approach. I am trying to avoid yet another
fastpath API
and complication in driver as there is element checking space in the
submit queue and completion queue at least in our hardware.
max_count = nb_desc; (power of 2)
mask = max_count - 1;
for (i = 0; I < n; i++) {
submit_idx = rte_dma_copy();
}
rc = rte_dma_completed(…, &completed_idx..);
space_in_queue = mask - ((submit_idx – completed_idx) & mask);
>
> <snipped>
>
> Thanks and regards,
> Sunil
>
