From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id 1C9488DAE for ; Wed, 14 Oct 2015 18:10:44 +0200 (CEST) Received: by wicgb1 with SMTP id gb1so237060598wic.1 for ; Wed, 14 Oct 2015 09:10:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=zyHKCuMYXjigWKpxL4aMPnScmjwVyUYE8RcZAm2sK/w=; b=Jl5+WEQa/OtascbI6f23Pmr999Syf7jOMu6E0Lcyv3bJswaWK/73T3HQVvLdIO8cWI ZikGC4yinepKQTzV68chlWlkCFUM/c2zDX03sIjTnEOsci56likzHQQxTJ7kLpEISVSB 49A6mMRMvQXhZph2kkwOaFkcXynBfSIbB2KHo3FvXNAY4X/sMdJRIos+cszdQXJRqlaz plcRxSYyds59OG4vJ96/clMuhatrNpqOwrM01HuZ+zb0VgSpSNahOAeTsy+SzNIGkT8j pAfBW0YXeAjGrZnQt8CYXuYQzd/3eqwALp5rlhc3C5T+rWLj8mwYeVRyNrv/bvgBPdDd Rn9A== X-Gm-Message-State: ALoCoQmrRb83DbSjgw3N0A/bcGGFUHYB631xVvb04P+EVwW3RwlJCH7+LUziSsfW4f2cHc2Ry4kD X-Received: by 10.180.106.70 with SMTP id gs6mr5454104wib.19.1444839043664; Wed, 14 Oct 2015 09:10:43 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id wb11sm5349638wic.16.2015.10.14.09.10.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 09:10:43 -0700 (PDT) To: "Ananyev, Konstantin" , "Richardson, Bruce" , "dev@dpdk.org" References: <1441135036-7491-1-git-send-email-zoltan.kiss@linaro.org> <55ED8252.1020900@linaro.org> <59AF69C657FD0841A61C55336867B5B0359227DF@IRSMSX103.ger.corp.intel.com> <55ED9BFD.7040009@linaro.org> <59AF69C657FD0841A61C55336867B5B035922A83@IRSMSX103.ger.corp.intel.com> <56059255.5010507@linaro.org> <2601191342CEEE43887BDE71AB97725836A9CE89@irsmsx105.ger.corp.intel.com> From: Zoltan Kiss Message-ID: <561E7E83.5000401@linaro.org> Date: Wed, 14 Oct 2015 17:10:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836A9CE89@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] ixgbe: prefetch packet headers in vector PMD receive function 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: Wed, 14 Oct 2015 16:10:44 -0000 On 28/09/15 00:19, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org] >> Sent: Friday, September 25, 2015 7:29 PM >> To: Richardson, Bruce; dev@dpdk.org >> Cc: Ananyev, Konstantin >> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive function >> >> On 07/09/15 07:41, Richardson, Bruce wrote: >>> >>>> -----Original Message----- >>>> From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org] >>>> Sent: Monday, September 7, 2015 3:15 PM >>>> To: Richardson, Bruce; dev@dpdk.org >>>> Cc: Ananyev, Konstantin >>>> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD receive >>>> function >>>> >>>> >>>> >>>> On 07/09/15 13:57, Richardson, Bruce wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: Zoltan Kiss [mailto:zoltan.kiss@linaro.org] >>>>>> Sent: Monday, September 7, 2015 1:26 PM >>>>>> To: dev@dpdk.org >>>>>> Cc: Ananyev, Konstantin; Richardson, Bruce >>>>>> Subject: Re: [PATCH] ixgbe: prefetch packet headers in vector PMD >>>>>> receive function >>>>>> >>>>>> Hi, >>>>>> >>>>>> I just realized I've missed the "[PATCH]" tag from the subject. Did >>>>>> anyone had time to review this? >>>>>> >>>>> Hi Zoltan, >>>>> >>>>> the big thing that concerns me with this is the addition of new >>>>> instructions for each packet in the fast path. Ideally, this >>>>> prefetching would be better handled in the application itself, as for >>>>> some apps, e.g. those using pipelining, the core doing the RX from the >>>>> NIC may not touch the packet data at all, and the prefetches will >>>> instead cause a performance slowdown. >>>>> Is it possible to get the same performance increase - or something >>>>> close to it - by making changes in OVS? >>>> OVS already does a prefetch when it's processing the previous packet, but >>>> apparently it's not early enough. At least for my test scenario, where I'm >>>> forwarding UDP packets with the least possible overhead. I guess in tests >>>> where OVS does more complex processing it should be fine. >>>> I'll try to move the prefetch earlier in OVS codebase, but I'm not sure if >>>> it'll help. >>> I would suggest trying to prefetch more than one packet ahead. Prefetching 4 or >>> 8 ahead might work better, depending on the processing being done. >> >> I've moved the prefetch earlier, and it seems to work: >> >> https://patchwork.ozlabs.org/patch/519017/ >> >> However it raises the question: should we remove header prefetch from >> all the other drivers, and the CONFIG_RTE_PMD_PACKET_PREFETCH option? > > My vote would be for that. > Konstantin After some further thinking I would rather support the rte_packet_prefetch() macro (prefetch the header in the driver, and configure it through CONFIG_RTE_PMD_PACKET_PREFETCH) - the prefetch can happen earlier, so if an application needs the header right away, this is the fastest - if the application doesn't need header prefetch, it can turn it off compile time. Same as if we wouldn't have this option. - if the application has mixed needs (sometimes it needs the header right away, sometimes it doesn't), it can turn it off and do what it needs. Same as if we wouldn't have this option. A harder decision would be whether it should be turned on or off by default. Currently it's on, and half of the receive functions don't use it. > > >> >>> >>> /Bruce >