From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC PATCH] virtio: virtio ring layout optimization and vectorization rx Date: Tue, 22 Sep 2015 15:55:23 -0700 Message-ID: <20150922155523.5f6fab96@urahara> References: <1442506651-16279-1-git-send-email-huawei.xie@intel.com> <4527609.XBoLQSHpyv@xps13> <4377815.VgSsvvaXDb@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" To: Thomas Monjalon Return-path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by dpdk.org (Postfix) with ESMTP id 090125A89 for ; Wed, 23 Sep 2015 00:55:13 +0200 (CEST) Received: by pacbt3 with SMTP id bt3so3390738pac.3 for ; Tue, 22 Sep 2015 15:55:12 -0700 (PDT) In-Reply-To: <4377815.VgSsvvaXDb@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 22 Sep 2015 15:37:13 +0200 Thomas Monjalon wrote: > 2015-09-22 09:29, Xie, Huawei: > > On 9/22/2015 4:38 PM, Thomas Monjalon wrote: > > > I thought it was clear we must avoid #ifdef for configuration. > > > Please check how to add a runtime flag. > > > Or better: keep only one path which works everywhere and well optimized. > > > > Thomas, i have this in mind when i am developing this feature and i plan > > to discuss this with you. In theory, the best solution would be using > > run time flag and the result would be normally we always choose the > > optimized path. > > The situation in real world is, in my mind, this feature isn't mature > > enough(Of course this doesn't mean it has known issues). One good > > solution in kernel community is experimental features. > > Could we also have experimental/development tag? I would like to put > > this as experimental/development feature temporarily, turn it off by > > default and continue to improve it. > > I think it is a rework, not an experimental feature. > > > The advantage is we have it in tree and every developers could pull it > > and help improve it. Also, it is the base for continuous vhost > > optimization. We should have a performance optimized driver for the > > device side optimization. > > If there are some acceptance problem, it can be solved on the list. > If there are some bugs after integration, it can be fixed before the release, > as there are some validation and non-regression tests. > > If the new Rx/Tx code can replace the old one, please replace it. > If the use cases are different, please use a runtime flag. > It it is not ready, please do more tests and re-submit later. > > By the way, thanks for your work. Agree with Thomas. Any feature should be always on, and negotiated by existing virtio feature bits.