From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2756A2B88 for ; Fri, 24 Feb 2017 14:33:30 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57FCD1293; Fri, 24 Feb 2017 13:33:31 +0000 (UTC) Received: from ktraynor.remote.csb (ovpn-117-111.ams2.redhat.com [10.36.117.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1894F2D5C0; Fri, 24 Feb 2017 13:33:29 +0000 (UTC) To: Bruce Richardson References: <1487926101-4637-1-git-send-email-zhiyong.yang@intel.com> <1487926101-4637-5-git-send-email-zhiyong.yang@intel.com> <22266556-4d0e-5db1-6a90-eebcecbe5283@redhat.com> <20170224130429.GA88332@bricha3-MOBL3.ger.corp.intel.com> Cc: Zhiyong Yang , dev@dpdk.org, yuanhan.liu@linux.intel.com, maxime.coquelin@redhat.com From: Kevin Traynor Organization: Red Hat Message-ID: <413fb2ba-9d36-7403-8e74-7cd4af814d9f@redhat.com> Date: Fri, 24 Feb 2017 13:33:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170224130429.GA88332@bricha3-MOBL3.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 24 Feb 2017 13:33:31 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 4/5] net/vhost: remove limit of vhost TX burst size X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:33:31 -0000 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@linux.intel.com >>> Cc: maxime.coquelin@redhat.com >>> >>> Signed-off-by: Zhiyong Yang >>> --- >>> 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 >