Re: [dpdk-dev] [PATCH 0/4] Support DMA-accelerated Tx operations for vhost-user PMD

[Maxime Coquelin <maxime.coquelin@redhat.com>]

Hi Jiayu,

On 3/19/20 12:47 PM, Hu, Jiayu wrote:

>>
>> Ok, so what about:
>>
>> Introducing a pair of callbacks in struct virtio_net for DMA enqueue and
>> dequeue.
>>
>> lib/librte_vhost/ioat.c which would implement dma_enqueue and
>> dma_dequeue callback for IOAT. As it will live in the vhost lib
>> directory, it will be easy to refactor the code to share as much as
>> possible and so avoid code duplication.
>>
>> In rte_vhost_enqueue/dequeue_burst, if the dma callback is set, then
>> call it instead of the SW datapath. It adds a few cycle, but this is
>> much more sane IMHO.
> 
> The problem is that current semantics of rte_vhost_enqueue/dequeue API
> are conflict with I/OAT accelerated data path. To improve the performance,
> the I/OAT works in an asynchronous manner, where the CPU just submits
> copy jobs to the I/OAT without waiting for its copy completion. For
> rte_vhost_enqueue_burst, users cannot reuse enqueued pktmbufs when it
> returns, as the I/OAT may still use them. For rte_vhost_dequeue_burst,
> users will not get incoming packets as the I/OAT is still performing packet
> copies. As you can see, when enabling I/OAT acceleration, the semantics of
> the two API are changed. If we keep the same API name but changing their
> semantic, this may confuse users, IMHO.

Ok, so it is basically the same as zero-copy for dequeue path, right?
If a new API is necessary, then it would be better to add it in Vhost
library for async enqueue/dequeue.
It could be used also for Tx zero-copy, and so the sync version would
save some cycles as we could remove the zero-copy support there.

What do you think?

I really object to implement vring handling into the Vhost PMD, this is
the role of the Vhost library.

Thanks,
Maxime