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 549BB8E6E for ; Fri, 25 Sep 2015 20:28:39 +0200 (CEST) Received: by padhy16 with SMTP id hy16so112673032pad.1 for ; Fri, 25 Sep 2015 11:28:38 -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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=bD9BJQjcy9gfgFque+eV1YS0X1QI7oBGQKrQNqyOe/U=; b=B4pTz55w3GNNP9elA42HEjcimbeplO0L4uvThiaNc29Shl28CAlvA5GZ/NTXOlgXsk P1JUxbVkTtGY3RPE+UI+RWsR1zURAqbmAN9WS/+RKoCuyvZ5D/q6wO+/mBbrvDtBctZi Un/tx0qBYntUQPvQ6PGkq0R9qkwhi/2geUadHBRdPzG38zlCpDervrKzo4KzLgAYyF9k GPvvBCyMtoxdvDid0KoYQtAOMCTpzpDeMBqLp3XTEOnyX+fjYzQExjldsByz40wJh4RD fwkyL24N5IhFePgDrGPIyGtL1JQM64E20YQD9eqmws3xY+wvmC+v5E/pWzgLgRuAhXAD Kfww== X-Gm-Message-State: ALoCoQk6b69S8NM0mgibQsw4U8Xbw+LpFFhexM2JtyPQJgQnVJvipgGyIizQajlrZeZYMyPplQ0U X-Received: by 10.68.68.143 with SMTP id w15mr9171701pbt.56.1443205718543; Fri, 25 Sep 2015 11:28:38 -0700 (PDT) Received: from [172.20.3.146] ([70.35.39.2]) by smtp.googlemail.com with ESMTPSA id fu4sm5121684pbb.59.2015.09.25.11.28.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2015 11:28:37 -0700 (PDT) To: "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> From: Zoltan Kiss Message-ID: <56059255.5010507@linaro.org> Date: Fri, 25 Sep 2015 11:28:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <59AF69C657FD0841A61C55336867B5B035922A83@IRSMSX103.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: Fri, 25 Sep 2015 18:28:39 -0000 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? > > /Bruce