From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 7DA8A2C22 for ; Mon, 7 Mar 2016 07:12:16 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP; 06 Mar 2016 22:12:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,549,1449561600"; d="scan'208";a="931109403" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by fmsmga002.fm.intel.com with ESMTP; 06 Mar 2016 22:12:13 -0800 Date: Mon, 7 Mar 2016 14:14:24 +0800 From: Yuanhan Liu To: "Xie, Huawei" Message-ID: <20160307061424.GZ14300@yliu-dev.sh.intel.com> References: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com> <1455803352-5518-1-git-send-email-yuanhan.liu@linux.intel.com> <1455803352-5518-2-git-send-email-yuanhan.liu@linux.intel.com> <20160304021705.GT14300@yliu-dev.sh.intel.com> <20160307024838.GY14300@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Michael S. Tsirkin" , "dev@dpdk.org" , Victor Kaplansky Subject: Re: [dpdk-dev] [PATCH v2 1/7] vhost: refactor rte_vhost_dequeue_burst 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: Mon, 07 Mar 2016 06:12:16 -0000 On Mon, Mar 07, 2016 at 02:59:55AM +0000, Xie, Huawei wrote: > On 3/7/2016 10:47 AM, Yuanhan Liu wrote: > > On Mon, Mar 07, 2016 at 02:32:46AM +0000, Xie, Huawei wrote: > >> On 3/4/2016 10:15 AM, Yuanhan Liu wrote: > >>> On Thu, Mar 03, 2016 at 04:30:42PM +0000, Xie, Huawei wrote: > >>>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote: > >>>> We could always allocate the head mbuf before the loop, then we save the > >>>> following branch and make the code more streamlined. > >>>> It reminds me that this change prevents the possibility of mbuf bulk > >>>> allocation, one solution is we pass the head mbuf from an additional > >>>> parameter. > >>> Yep, that's also something I have thought of. > >>> > >>>> Btw, put unlikely before the check of mbuf_avail and checks elsewhere. > >>> I don't think so. It would benifit for the small packets. What if, > >>> however, when TSO or jumbo frame is enabled that we have big packets? > >> Prefer to favor the path that packet could fit in one mbuf. > > Hmmm, why? While I know that TSO and mergeable buf is disable by default > > in our vhost example vhost-switch, they are enabled by default in real > > life. > > mergable is only meaningful in RX path. > If you mean big packets in TX path, Sorry, and yes, I meant that. > i personally favor the path that > packet fits in one mbuf. Sorry, that will not convince me. --yliu