From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 19F17A2F for ; Mon, 22 Feb 2016 03:04:17 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 21 Feb 2016 18:04:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,483,1449561600"; d="scan'208";a="918096489" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga002.jf.intel.com with ESMTP; 21 Feb 2016 18:04:15 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 21 Feb 2016 18:03:49 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 21 Feb 2016 18:03:49 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.249]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.112]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 10:03:47 +0800 From: "Xie, Huawei" To: Yuanhan Liu , Santosh Shukla Thread-Topic: [PATCH v7 2/4] virtio: Introduce config RTE_VIRTIO_INC_VECTOR Thread-Index: AdFtFUND1+vJR3jXQg+X8Vm+Elm7dw== Date: Mon, 22 Feb 2016 02:03:46 +0000 Message-ID: References: <1454853068-14621-1-git-send-email-sshukla@mvista.com> <1454853068-14621-3-git-send-email-sshukla@mvista.com> <2395124.Wzh8l6ZlGf@xps13> <20160215105743.GB21426@yliu-dev.sh.intel.com> <20160216030548.GE21426@yliu-dev.sh.intel.com> <20160219064220.GQ21426@yliu-dev.sh.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.4.80] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dpdk Subject: Re: [dpdk-dev] [PATCH v7 2/4] virtio: Introduce config RTE_VIRTIO_INC_VECTOR 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 Feb 2016 02:04:18 -0000 On 2/19/2016 2:42 PM, Yuanhan Liu wrote:=0A= > On Fri, Feb 19, 2016 at 10:16:42AM +0530, Santosh Shukla wrote:=0A= >> On Tue, Feb 16, 2016 at 8:35 AM, Yuanhan Liu=0A= >> wrote:=0A= >>> On Mon, Feb 15, 2016 at 04:48:36PM +0530, Santosh Shukla wrote:=0A= >>>> Hi Yuanhan,=0A= >>>>=0A= >>>> On Mon, Feb 15, 2016 at 4:27 PM, Yuanhan Liu=0A= >>>> wrote:=0A= >>>>> On Mon, Feb 15, 2016 at 03:22:11PM +0530, Santosh Shukla wrote:=0A= >>>>>> Hi Yuanhan,=0A= >>>>>>=0A= >>>>>> I guess you are back from vacation.=0A= >>>>>>=0A= >>>>>> Can you pl. review this patch, Except this patch, rest of patches=0A= >>>>>> received ack-by:=0A= >>>>> I had a quick glimpse of the comments from Thomas: he made a good poi= nt.=0A= >>>>> I will have a deeper thought tomorrow, to see what I can do to fix it= .=0A= >>>>>=0A= >>>> I agree to what Thomas pointed out about runtime mode switch (vectored= =0A= >>>> vs non-vectored). I have a proposal in my mind and Like to know you=0A= >>>> opinion:=0A= >>>>=0A= >>>> - need for apis like is_arch_support_vec().=0A= >>>>=0A= >>>> if (is_arch_support_vec())=0A= >>>> simpple_xxxx =3D 1 /* Switch code path to vector mode */=0A= >>>> else=0A= >>>> simple_xxxx =3D 0 /* Switch code path to non-vector mode */= =0A= >>>>=0A= >>>> That api should reside to arch file. i.e.. arch like i686/arm{for=0A= >>>> implementation not exist so say no supported} will return 0 and for=0A= >>>> x86_64 =3D 1=0A= >>> I was thinking that Thomas meant to something like below (like what=0A= >>> we did at rte_memcpy.h):=0A= >>>=0A= >>> #ifdef RTE_MACHINE_CPUFLAG_SSE (or whatever)=0A= >>>=0A= >>> /* with vec here */=0A= >>>=0A= >>> #else=0A= >>>=0A= >>> /* without vec here */=0A= >>>=0A= >>> #endif=0A= >>>=0A= >>> I mean, you have to bypass the build first; otherwise, you can't=0A= >>> go that further to runtime, right?=0A= >>>=0A= >> I meant: move virtio_recv_pkt_vec() implementation in=0A= >> lib/libeal_rte/xx/include/arch/xx/virtio_vec.h. virtio driver to check= =0A= >> for CPUFLAG supported or not and then use _recv_pkt() call back=0A= >> function from arch files. This approach will avoid #ifdef ARCH=0A= >> clutter.=0A= > Moving virtio stuff to eal looks wrong to me.=0A= >=0A= > Huawei, please comment on this.=0A= >=0A= > --yliu=0A= >=0A= =0A= This issue doesn't apply to virtio driver only but to all other PMDs,=0A= unless they are assumed to run on only one arch. As we are close to=0A= release, for the time being, i prefer to use RTE_MACHINE_CPUFLAG_. Later=0A= we look for other elegant solutions, like moving different arch specific=0A= optimizations into the arch directory under driver/virtio/ directory?=0A= Other thoughts?=0A= =0A= =0A= =0A=