From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id D62E6C4B2 for ; Fri, 19 Feb 2016 07:41:44 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 18 Feb 2016 22:41:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,469,1449561600"; d="scan'208";a="906605480" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by fmsmga001.fm.intel.com with ESMTP; 18 Feb 2016 22:41:42 -0800 Date: Fri, 19 Feb 2016 14:42:20 +0800 From: Yuanhan Liu To: Santosh Shukla , "Xie, Huawei" Message-ID: <20160219064220.GQ21426@yliu-dev.sh.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Fri, 19 Feb 2016 06:41:45 -0000 On Fri, Feb 19, 2016 at 10:16:42AM +0530, Santosh Shukla wrote: > On Tue, Feb 16, 2016 at 8:35 AM, Yuanhan Liu > wrote: > > On Mon, Feb 15, 2016 at 04:48:36PM +0530, Santosh Shukla wrote: > >> Hi Yuanhan, > >> > >> On Mon, Feb 15, 2016 at 4:27 PM, Yuanhan Liu > >> wrote: > >> > On Mon, Feb 15, 2016 at 03:22:11PM +0530, Santosh Shukla wrote: > >> >> Hi Yuanhan, > >> >> > >> >> I guess you are back from vacation. > >> >> > >> >> Can you pl. review this patch, Except this patch, rest of patches > >> >> received ack-by: > >> > > >> > I had a quick glimpse of the comments from Thomas: he made a good point. > >> > I will have a deeper thought tomorrow, to see what I can do to fix it. > >> > > >> > >> I agree to what Thomas pointed out about runtime mode switch (vectored > >> vs non-vectored). I have a proposal in my mind and Like to know you > >> opinion: > >> > >> - need for apis like is_arch_support_vec(). > >> > >> if (is_arch_support_vec()) > >> simpple_xxxx = 1 /* Switch code path to vector mode */ > >> else > >> simple_xxxx = 0 /* Switch code path to non-vector mode */ > >> > >> That api should reside to arch file. i.e.. arch like i686/arm{for > >> implementation not exist so say no supported} will return 0 and for > >> x86_64 = 1 > > > > I was thinking that Thomas meant to something like below (like what > > we did at rte_memcpy.h): > > > > #ifdef RTE_MACHINE_CPUFLAG_SSE (or whatever) > > > > /* with vec here */ > > > > #else > > > > /* without vec here */ > > > > #endif > > > > I mean, you have to bypass the build first; otherwise, you can't > > go that further to runtime, right? > > > > I meant: move virtio_recv_pkt_vec() implementation in > lib/libeal_rte/xx/include/arch/xx/virtio_vec.h. virtio driver to check > for CPUFLAG supported or not and then use _recv_pkt() call back > function from arch files. This approach will avoid #ifdef ARCH > clutter. Moving virtio stuff to eal looks wrong to me. Huawei, please comment on this. --yliu