From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by dpdk.org (Postfix) with ESMTP id DBFBB58DF for ; Mon, 22 Feb 2016 05:14:07 +0100 (CET) Received: by mail-pa0-f51.google.com with SMTP id fy10so83894860pac.1 for ; Sun, 21 Feb 2016 20:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Aq+v7IgYNRbovtY3fap6sSCOl5i7bx6iMuw/7L8ndyk=; b=KWDJKLFPcN8W1bi+dE3mIg85xKX/ax2ncFvNBX5X5ctl+K/2Cu2/JBnUaCzlKtl6SI J4fZ7K0ICqvLOj/f6yDrCWoY4QRezZ1uZJ3pJr7Km5jrMdEakrUAxo5wvg2dGB6T1+e9 4zljiXweOQSQatpVufHe/6/ub9Q3bOSKs0mRtDkpN2SdZOGm/MdCyWQ9Mw4q7KKkyIKh hpGSGA5bfTYvIPd656T7Yh9HeauWruxmis8/5iWZ8x7l4cIqkL8hkortstH+Vb1nDCMn hEWN2BFhrAKhSfn2Du0oWGTKfEPhLBxOaPFZq13ASEUcR37Rju7WVtJx+uE3HbGuZzhR Wp6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Aq+v7IgYNRbovtY3fap6sSCOl5i7bx6iMuw/7L8ndyk=; b=jDALOBmqMJkKyWoZ/WfHGtg/ozbiRxQzaMgwcnBEUaOJ7KDczkBt8ej3aSi4ggk2LJ yCVtIom7g8otL4MoN8Ae41Q1pxqrtRra/haRmWDJCCRAODiLGelzTEwUUaWY7m+78LhM gc8w5lk4MU416MPRxI4NbmLCY7F5AACXPbT7NmnKJYdF0lpAM8LFexJ5raFq3uGI8UPt ev6qqlBCozMIXH45PhBrVWO4IRUCcUGOS8w7xqgql5C6hTayqncF2ynpfY8Lh9YeWOK6 fgVJDC+VYIvAKkrVQfhmCXptGDno6s9AKtEmCscuI1U2x63FwSMGwYO4YMoOfdcXGN1W bOcg== X-Gm-Message-State: AG10YOSjsKzRc7swiDP0Y8uqMLnqxIwLqOMdD6slFUWZbkwjXOHUKPmYyh4dboiJX7wLAvZ5CC/G+RPxSS4eUPeO MIME-Version: 1.0 X-Received: by 10.66.55.73 with SMTP id q9mr35247902pap.50.1456114447220; Sun, 21 Feb 2016 20:14:07 -0800 (PST) Received: by 10.66.12.132 with HTTP; Sun, 21 Feb 2016 20:14:07 -0800 (PST) In-Reply-To: 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> Date: Mon, 22 Feb 2016 09:44:07 +0530 Message-ID: From: Santosh Shukla To: "Xie, Huawei" Content-Type: text/plain; charset=UTF-8 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 04:14:08 -0000 On Mon, Feb 22, 2016 at 7:33 AM, Xie, Huawei wrote: > On 2/19/2016 2:42 PM, Yuanhan Liu wrote: >> 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 >> > > This issue doesn't apply to virtio driver only but to all other PMDs, > unless they are assumed to run on only one arch. As we are close to > release, for the time being, i prefer to use RTE_MACHINE_CPUFLAG_. Later > we look for other elegant solutions, like moving different arch specific > optimizations into the arch directory under driver/virtio/ directory? > Other thoughts? > Creating arch specifics files in driver/virtio/: approach look okay to me. It look alike to my proposal except eal. I choose eal so that one api and its implementation stays in arch files, no ifdef clutter. I guess - Same doable in virtio directory too, create arch files and keep arch specific implementation their. so, +1 to approach. > >