From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: Vladyslav Buslov <Vladyslav.Buslov@harmonicinc.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/i40e: add additional prefetch instructions for bulk rx
Date: Tue, 15 Nov 2016 12:19:09 +0000 [thread overview]
Message-ID: <7c26e964-f2c8-1685-829c-e1c37bb25bf3@intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0C1209@irsmsx105.ger.corp.intel.com>
On 10/13/2016 11:30 AM, Ananyev, Konstantin wrote:
<...>
>>>>
>>>> Actually I can see some valid use cases where it is beneficial to have this prefetch in driver.
>>>> In our sw distributor case it is trivial to just prefetch next packet on each iteration because packets are processed one by one.
>>>> However when we move this functionality to hw by means of RSS/vfunction/FlowDirector(our long term goal) worker threads will
>> receive
>>>> packets directly from rx queues of NIC.
>>>> First operation of worker thread is to perform bulk lookup in hash table by destination MAC. This will cause cache miss on accessing
>> each
>>>> eth header and can't be easily mitigated in application code.
>>>> I assume it is ubiquitous use case for DPDK.
>>>
>>> Yes it is a quite common use-case.
>>> Though I many cases it is possible to reorder user code to hide (or minimize) that data-access latency.
>>> From other side there are scenarios where this prefetch is excessive and can cause some drop in performance.
>>> Again, as I know, none of PMDs for Intel devices prefetches packet's data in simple (single segment) RX mode.
>>> Another thing that some people may argue then - why only one cache line is prefetched,
>>> in some use-cases might need to look at 2-nd one.
>>>
>> There is a build-time config setting for this behaviour for exactly the reasons
>> called out here - in some apps you get a benefit, in others you see a perf
>> hit. The default is "on", which makes sense for most cases, I think.
>> From common_base:
>>
>> CONFIG_RTE_PMD_PACKET_PREFETCH=y$
>
> Yes, but right now i40e and ixgbe non-scattered RX (both vector and scalar) just ignore that flag.
> Though yes, might be a good thing to make them to obey that flag properly.
Hi Vladyslav,
According Konstantin's comment, what do you think updating patch to do
prefetch within CONFIG_RTE_PMD_PACKET_PREFETCH ifdef?
But since config option is enabled by default, performance concern is
still valid and needs to be investigated.
Thanks,
ferruh
next prev parent reply other threads:[~2016-11-15 12:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 17:27 [dpdk-dev] [PATCH] Add missing prefetches to i40e bulk rx path Vladyslav Buslov
2016-07-14 17:27 ` [dpdk-dev] [PATCH] net/i40e: add additional prefetch instructions for bulk rx Vladyslav Buslov
2016-09-14 13:24 ` Ferruh Yigit
2016-10-10 13:25 ` Wu, Jingjing
2016-10-10 17:05 ` Vladyslav Buslov
2016-10-11 8:51 ` Ananyev, Konstantin
2016-10-11 9:24 ` Vladyslav Buslov
2016-10-12 0:04 ` Ananyev, Konstantin
2016-10-13 10:18 ` Bruce Richardson
2016-10-13 10:30 ` Ananyev, Konstantin
2016-11-15 12:19 ` Ferruh Yigit [this message]
2016-11-15 13:27 ` Vladyslav Buslov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c26e964-f2c8-1685-829c-e1c37bb25bf3@intel.com \
--to=ferruh.yigit@intel.com \
--cc=Vladyslav.Buslov@harmonicinc.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).