From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 0C1323239 for ; Mon, 22 Aug 2016 16:07:00 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 22 Aug 2016 07:07:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,560,1464678000"; d="scan'208";a="524214" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga005.fm.intel.com with ESMTP; 22 Aug 2016 07:06:59 -0700 Date: Mon, 22 Aug 2016 22:16:36 +0800 From: Yuanhan Liu To: Rich Lane Cc: dev@dpdk.org, Huawei Xie , "Wang, Zhihong" Message-ID: <20160822141636.GC30752@yliu-dev.sh.intel.com> References: <1471291224-12755-1-git-send-email-rich.lane@bigswitch.com> <20160816023715.GL30752@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] vhost: add back support for concurrent enqueue 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, 22 Aug 2016 14:07:01 -0000 On Thu, Aug 18, 2016 at 11:27:06AM -0700, Rich Lane wrote: > On Mon, Aug 15, 2016 at 7:37 PM, Yuanhan Liu > wrote: > > On Mon, Aug 15, 2016 at 01:00:24PM -0700, Rich Lane wrote: > > Concurrent enqueue is an important performance optimization when the > number > > of cores used for switching is different than the number of vhost queues. > > I've observed a 20% performance improvement compared to a strategy that > > binds queues to cores. > > > > The atomic cmpset is only executed when the application calls > > rte_vhost_enqueue_burst_mp. Benchmarks show no performance impact > > when not using concurrent enqueue. > > > > Mergeable RX buffers aren't supported by concurrent enqueue to minimize > > code complexity. > > I think that would break things when Mergeable rx is enabled (which is > actually enabled by default). > > > Would it be reasonable to return -ENOTSUP in this case, and restrict concurrent > enqueue > to devices where VIRTIO_NET_F_MRG_RXBUF is disabled? > > I could also add back concurrent enqueue support for mergeable RX, but I was > hoping to avoid > that since the mergeable codepath is already complex and wouldn't be used in > high performance > deployments. Another note is that, you might also have noticed, Zhihong made a patch set [0] to optimize the enqueue code path (mainly on mergeable path). It basically does a rewrite from scatch, which removes the desc buf reservation, meaning it would be harder to do concurrent enqueue support based on that. [0]: Aug 19 Zhihong Wang ( 68) ├─>[PATCH v3 0/5] vhost: optimize enqueue --yliu