[dpdk-dev] [PATCH 4/5] net/vhost: remove limit of vhost TX burst size

[Kevin Traynor]

On 02/24/2017 01:04 PM, Bruce Richardson wrote:
> On Fri, Feb 24, 2017 at 11:08:56AM +0000, Kevin Traynor wrote:
>> On 02/24/2017 08:48 AM, Zhiyong Yang wrote:
>>> vhost removes limit of TX burst size(32 pkts) and supports to make
>>> an best effort to transmit pkts.
>>>
>>> Cc: yuanhan.liu at linux.intel.com
>>> Cc: maxime.coquelin at redhat.com
>>>
>>> Signed-off-by: Zhiyong Yang <zhiyong.yang at intel.com>
>>> ---
>>>  drivers/net/vhost/rte_eth_vhost.c | 24 ++++++++++++++++++++++--
>>>  1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
>>> index e98cffd..1e1fa34 100644
>>> --- a/drivers/net/vhost/rte_eth_vhost.c
>>> +++ b/drivers/net/vhost/rte_eth_vhost.c
>>> @@ -52,6 +52,7 @@
>>>  #define ETH_VHOST_QUEUES_ARG		"queues"
>>>  #define ETH_VHOST_CLIENT_ARG		"client"
>>>  #define ETH_VHOST_DEQUEUE_ZERO_COPY	"dequeue-zero-copy"
>>> +#define VHOST_MAX_PKT_BURST 32
>>>  
>>>  static const char *valid_arguments[] = {
>>>  	ETH_VHOST_IFACE_ARG,
>>> @@ -434,8 +435,27 @@ eth_vhost_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
>>>  		goto out;
>>>  
>>>  	/* Enqueue packets to guest RX queue */
>>> -	nb_tx = rte_vhost_enqueue_burst(r->vid,
>>> -			r->virtqueue_id, bufs, nb_bufs);
>>> +	if (likely(nb_bufs <= VHOST_MAX_PKT_BURST))
>>> +		nb_tx = rte_vhost_enqueue_burst(r->vid, r->virtqueue_id,
>>> +						bufs, nb_bufs);
>>> +	else {
>>> +		uint16_t nb_send = nb_bufs;
>>> +
>>> +		while (nb_send) {
>>> +			uint16_t nb_pkts;
>>> +			uint16_t num = (uint16_t)RTE_MIN(nb_send,
>>> +					VHOST_MAX_PKT_BURST);
>>> +
>>> +			nb_pkts = rte_vhost_enqueue_burst(r->vid,
>>> +							  r->virtqueue_id,
>>> +							  &bufs[nb_tx], num);
>>> +
>>> +			nb_tx += nb_pkts;
>>> +			nb_send -= nb_pkts;
>>> +			if (nb_pkts < num)
>>> +				break;
>>> +		}
>>
>> In the code above,
>> - if the VM does not service the queue, this will spin forever
> I don't think that is the case. As soon as the enqueue stops sending a
> full burst of (presumably 32) pkts, it will hit the break condition and
> quit. If it does send the full burst, it makes good forward progress
> until it runs out of packets to send and then quits.
> 
>> - if the queue is almost full, it will be very slow
> Again, should not be the case. As soon as a full burst is not full
> enqueued the logic quits the loop.
> 

My bad - you are of course correct. In that case it makes sense, as the
retries are just enough to allow all packets a chance to be sent but not
to retry when packets fail to send.

thanks,
Kevin.

> /Bruce
>