From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B37099E3 for ; Tue, 23 Aug 2016 16:35:15 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 23 Aug 2016 07:35:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,566,1464678000"; d="scan'208";a="1019065441" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga001.jf.intel.com with ESMTP; 23 Aug 2016 07:35:13 -0700 Date: Tue, 23 Aug 2016 22:45:01 +0800 From: Yuanhan Liu To: Maxime Coquelin Cc: dev@dpdk.org Message-ID: <20160823144501.GQ30752@yliu-dev.sh.intel.com> References: <1471939839-29778-1-git-send-email-yuanhan.liu@linux.intel.com> <1471939839-29778-7-git-send-email-yuanhan.liu@linux.intel.com> <373f1d24-f5a5-eed1-e342-87fc6c7cc3cb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <373f1d24-f5a5-eed1-e342-87fc6c7cc3cb@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 6/6] examples/vhost: add an option to enable Tx zero copy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:35:16 -0000 On Tue, Aug 23, 2016 at 04:14:44PM +0200, Maxime Coquelin wrote: > > /* Specify timeout (in useconds) between retries on RX. */ > > static uint32_t burst_rx_delay_time = BURST_RX_WAIT_US; > >@@ -297,6 +298,17 @@ port_init(uint8_t port) > > > > rx_ring_size = RTE_TEST_RX_DESC_DEFAULT; > > tx_ring_size = RTE_TEST_TX_DESC_DEFAULT; > >+ > >+ /* > >+ * When Tx zero copy is enabled, guest Tx used vring will be updated > >+ * only when corresponding mbuf is freed. Thus, the nb_tx_desc > >+ * (tx_ring_size here) must be small enough so that the driver will > >+ * hit the free threshold easily and free mbufs timely. Otherwise, > >+ * guest Tx vring would be starved. > >+ */ > >+ if (tx_zero_copy) > >+ tx_ring_size = 64; > > I have a concern about more complex applications, where the mbufs might > not be consumed sequentially. > If one mbuf gets stuck for a while, whereas all others are consumed, > we would face starvation. I guess that exactly belongs to the worst case I mentioned in another email. That's why I think we should not break the loop when a head mbuf is not consumed. --yliu > For example, the packet is to be routed to a VM, which is paused, > and the routing thread keeps retrying to enqueue the packet for a while. > > Anyway, this feature is optional and off by default, so having the > feature applied is not a blocker. > > Thanks! > Maxime