From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [PATCH v7 2/4] virtio: Introduce config
	RTE_VIRTIO_INC_VECTOR
Date: Fri, 19 Feb 2016 14:42:20 +0800
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>
 <CAAyOgsZmig3ZSoAi1Ho5=mGNdokb5Lu-cD1ASMGB04SBm4ZQ7A@mail.gmail.com>
 <CAAyOgsZO+6+kFZZZM203fPR3AmVYB0v7j3-f+DawZOCuR-AVvQ@mail.gmail.com>
 <20160215105743.GB21426@yliu-dev.sh.intel.com>
 <CAAyOgsaT5TcsPfum8x6yzAJAz=5N+c5QebEn7KCyJn7oK=VMsw@mail.gmail.com>
 <20160216030548.GE21426@yliu-dev.sh.intel.com>
 <CAAyOgsZNZtMGhk2qmnj-RjPKQDp-gQhCHnYpr918ESqgk0YDWg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dpdk <dev@dpdk.org>
To: Santosh Shukla <sshukla@mvista.com>, "Xie, Huawei" <huawei.xie@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id D62E6C4B2
 for <dev@dpdk.org>; Fri, 19 Feb 2016 07:41:44 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <CAAyOgsZNZtMGhk2qmnj-RjPKQDp-gQhCHnYpr918ESqgk0YDWg@mail.gmail.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Feb 19, 2016 at 10:16:42AM +0530, Santosh Shukla wrote:
> On Tue, Feb 16, 2016 at 8:35 AM, Yuanhan Liu
> <yuanhan.liu@linux.intel.com> 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
> >> <yuanhan.liu@linux.intel.com> 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