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
