From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=YPRzS2rl2i82uPR7wqICtpaSqn3UoPCBV/kH7OeDDeg=; b=Ezevcco5zsteuFT3OVBRbg3adVYmTmCKJOh5V5/qcN2kVLa9JWDnKvoP9TAY1XKgln sycLbI5WTF0LF/sCux3rRSO9PAbM8h7x4GJpT6WkUs2zJRYpXjlb2X+dBJz8xmMHgiRI NzMsNQeCdQO93+T1Ya4LCr1FJB9o1sf4wfIgyTn0UQ+VHoHtnB9QH1XMbSkboMNXS67+ malpqtochysq94m7M3k3OvZUuPyD1tCNzQX3Y+AZzTChN2zGeUCXOWV7OTY+eioNh08Z RSObWZwofRok8daJuXtFwDg0j2faVQyE0COYS0T+kWQrtR/6khMovq/ntZAjGoIMWl0y lOjw== X-Gm-Message-State: ALoCoQkKrp1kJPhrnKioVfRns2myH5EpE626kUtwFWHCqVSBAum049uEwcwT/lnGE+gSxNJKxsjE X-Received: by 10.68.191.200 with SMTP id ha8mr7682397pbc.72.1442962512013; Tue, 22 Sep 2015 15:55:12 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id lc9sm4205964pbc.52.2015.09.22.15.55.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 15:55:11 -0700 (PDT) Date: Tue, 22 Sep 2015 15:55:23 -0700 From: Stephen Hemminger To: Thomas Monjalon Message-ID: <20150922155523.5f6fab96@urahara> In-Reply-To: <4377815.VgSsvvaXDb@xps13> 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" Subject: Re: [dpdk-dev] [RFC PATCH] virtio: virtio ring layout optimization and vectorization rx 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, 22 Sep 2015 22:55:13 -0000 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.