Hi Chenbo and Maxime,
> -----Original Message-----
> From: Wang, YuanX <yuanx.w...@intel.com>
> Sent: Wednesday, August 24, 2022 12:36 AM
> To: maxime.coque...@redhat.com; Xia, Chenbo <chenbo....@intel.com>;
> dev@dpdk.org
> Cc: Hu, Jiayu <jiayu...@intel.com>; He, Xingguang
> <xingguang...@intel.com>; Jiang, Cheng1 <cheng1.ji...@intel.com>; Wang,
> YuanX <yuanx.w...@intel.com>; Ma, WenwuX <wenwux...@intel.com>
> Subject: [PATCH v3] net/vhost: support asynchronous data path
>
> Vhost asynchronous data-path offloads packet copy from the CPU to the
> DMA engine. As a result, large packet copy can be accelerated by the DMA
> engine, and vhost can free CPU cycles for higher level functions.
>
> In this patch, we enable asynchronous data-path for vhostpmd.
> Asynchronous data path is enabled per tx/rx queue, and users need to
> specify the DMA device used by the tx/rx queue. Each tx/rx queue only
> supports to use one DMA device, but one DMA device can be shared among
> multiple tx/rx queues of different vhostpmd ports.
>
> Two PMD parameters are added:
> - dmas: specify the used DMA device for a tx/rx queue.
> (Default: no queues enable asynchronous data path)
> - dma-ring-size: DMA ring size.
> (Default: 4096).
>
> Here is an example:
> --vdev
> 'eth_vhost0,iface=./s0,dmas=[txq0@0000:00.01.0;rxq0@0000:00.01.1],dma-
> ring-size=4096'
>
> Signed-off-by: Jiayu Hu <jiayu...@intel.com>
> Signed-off-by: Yuan Wang <yuanx.w...@intel.com>
> Signed-off-by: Wenwu Ma <wenwux...@intel.com>
> ---
>
> static uint16_t
> eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs) { @@ -
> 403,7 +469,7 @@ eth_vhost_rx(void *q, struct rte_mbuf **bufs, uint16_t
> nb_bufs)
> uint16_t nb_receive = nb_bufs;
>
> if (unlikely(rte_atomic32_read(&r->allow_queuing) == 0))
> - return 0;
> + goto tx_poll;
>
> rte_atomic32_set(&r->while_queuing, 1);
>
> @@ -411,19 +477,36 @@ eth_vhost_rx(void *q, struct rte_mbuf **bufs,
> uint16_t nb_bufs)
> goto out;
>
> /* Dequeue packets from guest TX queue */
> - while (nb_receive) {
> - uint16_t nb_pkts;
> - uint16_t num = (uint16_t)RTE_MIN(nb_receive,
> - VHOST_MAX_PKT_BURST);
> -
> - nb_pkts = rte_vhost_dequeue_burst(r->vid, r->virtqueue_id,
> - r->mb_pool, &bufs[nb_rx],
> - num);
> -
> - nb_rx += nb_pkts;
> - nb_receive -= nb_pkts;
> - if (nb_pkts < num)
> - break;
> + if (!r->async_register) {
> + while (nb_receive) {
> + uint16_t nb_pkts;
> + uint16_t num = (uint16_t)RTE_MIN(nb_receive,
> +
> VHOST_MAX_PKT_BURST);
> +
> + nb_pkts = rte_vhost_dequeue_burst(r->vid, r-
> >virtqueue_id,
> + r->mb_pool, &bufs[nb_rx],
> + num);
> +
> + nb_rx += nb_pkts;
> + nb_receive -= nb_pkts;
> + if (nb_pkts < num)
> + break;
> + }
> + } else {
> + while (nb_receive) {
> + uint16_t nb_pkts;
> + uint16_t num = (uint16_t)RTE_MIN(nb_receive,
> VHOST_MAX_PKT_BURST);
> + int nr_inflight;
> +
> + nb_pkts = rte_vhost_async_try_dequeue_burst(r-
> >vid, r->virtqueue_id,
> + r->mb_pool, &bufs[nb_rx],
> num, &nr_inflight,
> + r->dma_id, 0);
> +
> + nb_rx += nb_pkts;
> + nb_receive -= nb_pkts;
> + if (nb_pkts < num)
> + break;
> + }
> }
>
> r->stats.pkts += nb_rx;
> @@ -444,6 +527,17 @@ eth_vhost_rx(void *q, struct rte_mbuf **bufs,
> uint16_t nb_bufs)
> out:
> rte_atomic32_set(&r->while_queuing, 0);
>
> +tx_poll:
> + /**
> + * Poll and free completed packets for the virtqueue of Tx queue.
> + * Note that we access Tx queue's virtqueue, which is protected
> + * by vring lock.
> + */
> + if (!async_tx_poll_completed && r->txq->async_register) {
> + vhost_tx_free_completed(r->vid, r->txq->virtqueue_id, r-
> >txq->dma_id,
> + r->cmpl_pkts, VHOST_MAX_PKT_BURST);
> + }
> +
For Tx queue's rte_vhost_poll_enqueue_completed function, there are two place
to call it. One is the TX path, the other is the RX path. Calling it in the RX
path can
make the front-end receive the last burst of TX packets when there are no more
TX
operations, but it also potentially causes more DMA contentions between lcores.
For example, testpmd has 2 lcores, one NIC port and one vhost PMD port with
one queue. The RXQ and TXQ of vhost PMD port use dedicated DMA devices. So
the traffic flow is like below:
lcore0: NIC RXQ -> vhost TXQ
lcore1: vhost RXQ -> NIC TXQ
Calling rte_vhost_poll_enqueue_completed function in the vhost RX path will
cause
lcore1 contend the DMA device used by the vhost TXQ while operating the vhost
RXQ.
Performance degradation depends on different cases. In the 4-core 2-queue PVP
case,
testpmd throughput degradation is ~10%.
Calling it in the TX path can avoid the DMA contention case above, but the
front-end
cannot receive the last burst of TX packets if there is no more TX operations
for the
same TXQ.
In the current implementation, we select the first design, but users can enable
vhost
PMD to call rte_vhost_poll_enqueue_completed in the TX path by the testpmd
command
during runtime. So the DMA contention above can be avoided in testpmd.
I wonder if you have any comments on the design?
Thanks,
Jiayu
> return nb_rx;
> }
>
