From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 3BBF13F9 for ; Mon, 22 Feb 2016 11:24:15 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id a4so155437070wme.1 for ; Mon, 22 Feb 2016 02:24:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=LkF3qcscmA2kBhwPHqxkyh35te1NmNOigg6okMMFevE=; b=sjtRBFGbxnXDwlKOvW9IDn/Vfojxk9YEiq8rxSNTk33ixnfO9k9TcgajC1RI14ZiKe M4iuK3A70LKCEyyV3+jc8JKlpLYKKXSpFcU+kg/uFu8n7qHZSSvr3DLNch3hMl3M5oDx 4todtxhizj/1EGm5OmcMaUksaWYwqCY12JcveUalCPh8UKwTeQzOTpTQ+KZLiqaaflPU rc3UEi4AI/9wA8CfccilHCmyYlJa+ZTIYkCH3pYVPi5Irqkb72BqkUInejmq7AC7y63r A3jriUIZQy3p0N1D2xy2rbUwKf20x8XZjDgy+HxoGI131+OPio6tBRF0Ynp7fqrySMYg /IsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=LkF3qcscmA2kBhwPHqxkyh35te1NmNOigg6okMMFevE=; b=c1hhFFp98Ew2nczw3OmQZNtuWbv4WXD9FxSB091zscon/OXErrdgRsV/WprniE8R6W fM2/PFIFCRfdz9rYncWBHuOKJCMNSUCUTV43nTb48EYhtewr0rsLgqWnTjfLqb4bt190 M3StHtT/Prskrvef2XPode3v8EXhOBx52q0DXLQfHtZhuwte9v2cUpmLgTQBt4XVHKGi jio18AWgGa8qV/ekqsrSPB0uRkyuejmcBguGzdSd23Gsiticzp0xK+kd8G3145chT4Pl PlEQ6qU7Z7sTyx8atLL+euTEG8UX88LOyhYYsiykQAFkmhLYrTYAeCHfb5Y0agqcjznl 4+qw== X-Gm-Message-State: AG10YOQEP44h51tMgNyvfRBKSA/60kiGOK7X3gyzpd3ntboWSoDcJNlNSM8VHtkBL1h1mYzJ X-Received: by 10.194.23.37 with SMTP id j5mr26029256wjf.171.1456136651815; Mon, 22 Feb 2016 02:24:11 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id t12sm20341614wmt.20.2016.02.22.02.24.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 02:24:10 -0800 (PST) From: Thomas Monjalon To: Santosh Shukla , "Xie, Huawei" , Yuanhan Liu Date: Mon, 22 Feb 2016 11:22:37 +0100 Message-ID: <2279602.6hRPlZZ2rr@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1454853068-14621-1-git-send-email-sshukla@mvista.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org 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 10:24:15 -0000 2016-02-22 09:44, Santosh Shukla: > 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: > >>>>>> 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. > > > > 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_. Yes the obvious fix is to use some CPU flags. In ACL the flags are checked on runtime to allow using some optimizations after a "default" build. It can be considered later for virtio. > > 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. If there are some basic functions which can be re-used in other libs, there must be in EAL. For virtio-specific functions, you can have some arch-specific files in virtio.