From: Olivier MATZ <olivier.matz@6wind.com>
To: "Damjan Marion (damarion)" <damarion@cisco.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
Date: Mon, 15 Jun 2015 15:20:22 +0200 [thread overview]
Message-ID: <557ED116.7040508@6wind.com> (raw)
In-Reply-To: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
Hi Damjan,
On 06/10/2015 11:47 PM, Damjan Marion (damarion) wrote:
>
> Hi,
>
> We noticed 7% performance improvement by simply moving rte_mbuf.next field to the 1st cache line.
>
> Currently, it falls under /* second cache line - fields only used in slow path or on TX */
> but it is actually used at several places in rx fast path. (e.g.: i40e_rx_alloc_bufs() is setting that field to NULL).
>
> Is there anything we can do here (stop using next field, or move it to 1st cache line)?
Agree, this is also something I noticed, see:
http://dpdk.org/ml/archives/dev/2015-February/014400.html
I did not have the time to do performance testing, but it's something
I'd like to do as soon as I can. I don't see any obvious reason not to
do it.
It seems we currently just have enough room to do it (8 bytes are
remaining in the first cache line when compiled in 64 bits).
Regards,
Olivier
>
> Thanks,
>
> Damjan
>
>
>
>
next prev parent reply other threads:[~2015-06-15 13:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 21:47 Damjan Marion (damarion)
2015-06-15 13:20 ` Olivier MATZ [this message]
2015-06-15 13:44 ` Bruce Richardson
2015-06-15 13:54 ` Ananyev, Konstantin
2015-06-15 14:05 ` Olivier MATZ
2015-06-15 14:12 ` Bruce Richardson
2015-06-15 14:30 ` Olivier MATZ
2015-06-15 14:46 ` Bruce Richardson
2015-06-15 14:52 ` Ananyev, Konstantin
2015-06-15 15:19 ` Olivier MATZ
2015-06-15 15:23 ` Bruce Richardson
2015-06-15 15:28 ` Ananyev, Konstantin
2015-06-15 15:39 ` Bruce Richardson
2015-06-15 15:59 ` Ananyev, Konstantin
2015-06-15 16:02 ` Bruce Richardson
2015-06-15 16:10 ` Ananyev, Konstantin
2015-06-15 16:23 ` Bruce Richardson
2015-06-15 18:34 ` Ananyev, Konstantin
2015-06-15 20:47 ` Stephen Hemminger
2015-06-16 8:20 ` Bruce Richardson
2015-06-17 13:55 ` Damjan Marion (damarion)
2015-06-17 14:04 ` Thomas Monjalon
2015-06-17 14:06 ` Bruce Richardson
2015-06-17 14:23 ` Damjan Marion (damarion)
2015-06-17 16:32 ` Thomas Monjalon
[not found] ` <0DE313B5-C9F0-4879-9D92-838ED088202C@cisco.com>
[not found] ` <27EA8870B328F74E88180827A0F816396BD43720@xmb-aln-x10.cisco.com>
[not found] ` <59AF69C657FD0841A61C55336867B5B0345592CD@IRSMSX103.ger.corp.intel.com>
[not found] ` <1FD9B82B8BF2CF418D9A1000154491D97450B186@ORSMSX102.amr.corp.intel.com>
[not found] ` <27EA8870B328F74E88180827A0F816396BD43891@xmb-aln-x10.cisco.com>
[not found] ` <2601191342CEEE43887BDE71AB97725836A1237C@irsmsx105.ger.corp.intel.com>
2015-06-17 18:50 ` Ananyev, Konstantin
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=557ED116.7040508@6wind.com \
--to=olivier.matz@6wind.com \
--cc=damarion@cisco.com \
--cc=dev@dpdk.org \
/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).