From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 8E9108DAC for ; Tue, 22 Sep 2015 11:30:01 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 22 Sep 2015 02:30:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,572,1437462000"; d="scan'208";a="810287298" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2015 02:29:59 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 22 Sep 2015 17:29:58 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.75]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.92]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 17:29:56 +0800 From: "Xie, Huawei" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [RFC PATCH] virtio: virtio ring layout optimization and vectorization rx Thread-Index: AdD1GT4ZpJlrEVzoTWKiXvXTBE/O+g== Date: Tue, 22 Sep 2015 09:29:56 +0000 Message-ID: References: <1442506651-16279-1-git-send-email-huawei.xie@intel.com> <4527609.XBoLQSHpyv@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 09:30:02 -0000 On 9/22/2015 4:38 PM, Thomas Monjalon wrote:=0A= > 2015-09-18 00:17, Huawei Xie:=0A= >> --- a/config/common_linuxapp=0A= >> +++ b/config/common_linuxapp=0A= >> @@ -241,6 +241,7 @@ CONFIG_RTE_LIBRTE_ENIC_DEBUG=3Dn=0A= >> # Compile burst-oriented VIRTIO PMD driver=0A= >> #=0A= >> CONFIG_RTE_LIBRTE_VIRTIO_PMD=3Dy=0A= >> +CONFIG_RTE_VIRTIO_SIMPLE=3Dy=0A= >> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=3Dn=0A= >> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=3Dn=0A= >> CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=3Dn=0A= > -1=0A= >=0A= >> @@ -1150,6 +1158,14 @@ rx_func_get(struct rte_eth_dev *eth_dev)=0A= >> eth_dev->rx_pkt_burst =3D &virtio_recv_mergeable_pkts;=0A= >> else=0A= >> eth_dev->rx_pkt_burst =3D &virtio_recv_pkts;=0A= >> +=0A= >> +#ifdef RTE_VIRTIO_SIMPLE=0A= >> + if (!vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {=0A= >> + printf("use simple rxtx\n");=0A= >> + eth_dev->rx_pkt_burst =3D &virtio_recv_pkts_simple;=0A= >> + eth_dev->tx_pkt_burst =3D &virtio_xmit_pkts_simple;=0A= >> + }=0A= >> +#endif=0A= > I thought it was clear we must avoid #ifdef for configuration.=0A= > Please check how to add a runtime flag.=0A= > Or better: keep only one path which works everywhere and well optimized.= =0A= >=0A= >=0A= Thomas, i have this in mind when i am developing this feature and i plan=0A= to discuss this with you. In theory, the best solution would be using=0A= run time flag and the result would be normally we always choose the=0A= optimized path.=0A= The situation in real world is, in my mind, this feature isn't mature=0A= enough(Of course this doesn't mean it has known issues). One good=0A= solution in kernel community is experimental features.=0A= Could we also have experimental/development tag? I would like to put=0A= this as experimental/development feature temporarily, turn it off by=0A= default and continue to improve it.=0A= The advantage is we have it in tree and every developers could pull it=0A= and help improve it. Also, it is the base for continuous vhost=0A= optimization. We should have a performance optimized driver for the=0A= device side optimization.=0A= Cced some developers to see their opinion.=0A= Thoughts?=0A=