RE: [PATCH v3] net/vhost: support asynchronous data path

["Xia, Chenbo" <chenbo.xia@intel.com>]

> -----Original Message-----
> From: Hu, Jiayu <jiayu.hu@intel.com>
> Sent: Monday, October 10, 2022 1:17 PM
> To: maxime.coquelin@redhat.com; Xia, Chenbo <chenbo.xia@intel.com>
> Cc: He, Xingguang <xingguang.he@intel.com>; Jiang, Cheng1
> <cheng1.jiang@intel.com>; Ma, WenwuX <wenwux.ma@intel.com>; Wang, YuanX
> <yuanx.wang@intel.com>; dev@dpdk.org
> Subject: RE: [PATCH v3] net/vhost: support asynchronous data path
> 
> Hi Chenbo and Maxime,
> 
> > -----Original Message-----
> > From: Wang, YuanX <yuanx.wang@intel.com>
> > Sent: Wednesday, August 24, 2022 12:36 AM
> > To: maxime.coquelin@redhat.com; Xia, Chenbo <chenbo.xia@intel.com>;
> > dev@dpdk.org
> > Cc: Hu, Jiayu <jiayu.hu@intel.com>; He, Xingguang
> > <xingguang.he@intel.com>; Jiang, Cheng1 <cheng1.jiang@intel.com>; Wang,
> > YuanX <yuanx.wang@intel.com>; Ma, WenwuX <wenwux.ma@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.hu@intel.com>
> > Signed-off-by: Yuan Wang <yuanx.wang@intel.com>
> > Signed-off-by: Wenwu Ma <wenwux.ma@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?

I now will prefer the current design:

1. Make the packet finish by calling it in RX.
2. Still leave one testpmd option to avoid performance issue/tx-only issue to
   get best perf and make tx-only work.

As vhost PMD is targeted for mainly testing now, make sure functionality works
well and also leave one way to get some reference performance number (which will
be useful for real production-level APP like OVS to refer). That's good for
vhost PMD IMHO.

Maxime, any different opinion?

Thanks,
Chenbo

> 
> Thanks,
> Jiayu
> 
> >  	return nb_rx;
> >  }
> >