From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by dpdk.org (Postfix) with ESMTP id 5B861C39E for ; Fri, 19 Feb 2016 05:46:43 +0100 (CET) Received: by mail-pf0-f173.google.com with SMTP id q63so44228191pfb.0 for ; Thu, 18 Feb 2016 20:46:43 -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=i1j99oV445kzzvtaFRVJZn/YM/Kx/XdT/HRBZkWWGW0=; b=Kb3JLrrHzKyChE14Wkbz1fGjaaqQStyj57lMex2zjeoMHqP11yloGolQGICpCujAUK F1bvRtdzEwYrvVq0cX6y0oFGre8uXqYKODRDZAtXds8Ef1DpRQPtrtFmFwnvNit7SgS8 agr4SpkXUZvGDnu2g23qOyS0u/TTtPcmBv1AupIvgRmxjjcfCpzANi2x7RNFPMKBfirK pMmhDSX6Xp03idXpsHGSOX5oL5l0EcA/oTIOqAZtDYDVx3QDYQ9tU68KJQ8eMjol3rhW GNsQDIPzbdEyX4EI85nzRgIpInn3KrJqnU0krZFKNxSVrFBXStuzAC1qe0MXQQjd/z5y 3DIg== 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=i1j99oV445kzzvtaFRVJZn/YM/Kx/XdT/HRBZkWWGW0=; b=CTGppyW+tTvSXyddpszH2wVS/wDFeAnE5JH9bm15aJro7bOLXr8r/DikpYHGSG/rED KqouCPv1qLWzhHXQ7IiyB2jfBhYBydif6tirSB3JBTJLse8dY9N52vu9F7gvLHHYX2jZ iynaQirfBuQGxGEffLypsAm8m9AJhNTozgqO6zHjSwVCMJ1ZiR06vOlT6gF9QgXOHNl+ lCjWu/trta7gi124IAZtH5lSFNa8GHevWmLslSY5HVjSn3uu117UVjecwmMtehMZ5je5 2/LXETHjXJr0elheSJX5DWBHTWGtCG+MPX5ac5wRheGLddNGTyYiJGNIje3Q5zF6rJUk sEVg== X-Gm-Message-State: AG10YOTFvLfsZExyu4l1HGjL0irFvGXUQ4cwY0G12JRT2P0gBm0k+XX6DzzTJFSGRyaIsLuLKexgwKjz+GY5HNX2 MIME-Version: 1.0 X-Received: by 10.98.0.11 with SMTP id 11mr15426158pfa.5.1455857202730; Thu, 18 Feb 2016 20:46:42 -0800 (PST) Received: by 10.66.12.132 with HTTP; Thu, 18 Feb 2016 20:46:42 -0800 (PST) In-Reply-To: <20160216030548.GE21426@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> Date: Fri, 19 Feb 2016 10:16:42 +0530 Message-ID: From: Santosh Shukla To: Yuanhan Liu 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: Fri, 19 Feb 2016 04:46:43 -0000 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. This patch is blocking virtio-for-arm entry which is floating close to month or so, if no taker for this topic then pl. let me know, I'll propose a patch. Thanks! > > Huawei, since it's your patch introduced such issue, mind to fix > it? > > --yliu >> >> Does this make sense? >> >> Thanks >> > --yliu >> >> >> >> Thanks >> >> >> >> On Mon, Feb 8, 2016 at 11:15 AM, Santosh Shukla wrote: >> >> > On Mon, Feb 8, 2016 at 2:55 AM, Thomas Monjalon >> >> > wrote: >> >> >> 2016-02-07 19:21, Santosh Shukla: >> >> >>> - virtio_recv_pkts_vec and other virtio vector friend apis are written for >> >> >>> sse/avx instructions. For arm64 in particular, virtio vector implementation >> >> >>> does not exist(todo). >> >> >>> >> >> >>> So virtio pmd driver wont build for targets like i686, arm64. By making >> >> >>> RTE_VIRTIO_INC_VECTOR=n, Driver can build for non-sse/avx targets and will work >> >> >>> in non-vectored virtio mode. >> >> >>> >> >> >>> Disabling RTE_VIRTIO_INC_VECTOR config for : >> >> >>> >> >> >>> - i686 arch as i686 target config says: >> >> >>> config/defconfig_i686-native-linuxapp-gcc says "Vectorized PMD is not >> >> >>> supported on 32-bit". >> >> >>> >> >> >>> - armv7/v8 arch. >> >> >> >> >> >> Yes it can be useful to disable vector optimizations, but it should done >> >> >> at runtime, not a compilation option. I know it is already wrongly configured >> >> >> at compilation for other drivers, we should fix them. >> >> >> >> >> > >> >> > Can't we consider this separate topic. My intent is virtio works for arm. >> >> > >> >> >> Here, you want to avoid SSE/AVX code on ARM. So we should just add the >> >> >> appropriate ifdefs. Adding a compilation option does not prevent from enabling >> >> >> it on ARM or old x86 which do not support these instructions. >> >> >> >> >> > >> >> > By disabling VIRTIO_INC_VEC, compiler wont build >> >> > virtio_recv_pkts_vec(), so wont generate SSE/AVX code. Adding ifdef >> >> > for other arch example arm, is next step. Vector instruction for arm >> >> > are not fully supported, Its a todolist (Pl. refer my early v1/2 >> >> > cover-letter), We'll add that after virtio functionally works for arm. >> >> > >> >> >> Please virtio maintainers, we need to fix this code. Thanks