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....@linux.intel.com
>>> Cc: maxime.coque...@redhat.com
>>>
>>> Signed-off-by: Zhiyong Yang <zhiyong.y...@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
>
