DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets
Date: Tue, 8 Dec 2015 18:15:31 +0530	[thread overview]
Message-ID: <20151208124527.GA18192@localhost.localdomain> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725836AD15BE@irsmsx105.ger.corp.intel.com>

On Mon, Dec 07, 2015 at 03:21:33PM +0000, Ananyev, Konstantin wrote:

Hi Konstantin,

> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Sunday, December 06, 2015 3:59 PM
> > To: dev@dpdk.org
> > Cc: thomas.monjalon@6wind.com; Richardson, Bruce; olivier.matz@6wind.com; Dumitrescu, Cristian; Ananyev, Konstantin; Jerin
> > Jacob
> > Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets
> >
> > No need to split mbuf structure to two cache lines for 128-byte cache line
> > size targets as it can fit on a single 128-byte cache line.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> >  app/test/test_mbuf.c                                          | 4 ++++
> >  lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4 ++++
> >  lib/librte_mbuf/rte_mbuf.h                                    | 2 ++
> >  3 files changed, 10 insertions(+)
> >
> > diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> > index b32bef6..5e21075 100644
> > --- a/app/test/test_mbuf.c
> > +++ b/app/test/test_mbuf.c
> > @@ -930,7 +930,11 @@ test_failing_mbuf_sanity_check(void)
> >  static int
> >  test_mbuf(void)
> >  {
> > +#if RTE_CACHE_LINE_SIZE == 64
> >  	RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE * 2);
> > +#elif RTE_CACHE_LINE_SIZE == 128
> > +	RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE);
> > +#endif
> >
> >  	/* create pktmbuf pool if it does not exist */
> >  	if (pktmbuf_pool == NULL) {
> > diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h b/lib/librte_eal/linuxapp/eal/include/exec-
> > env/rte_kni_common.h
> > index bd1cc09..e724af7 100644
> > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> > @@ -121,8 +121,12 @@ struct rte_kni_mbuf {
> >  	uint32_t pkt_len;       /**< Total pkt len: sum of all segment data_len. */
> >  	uint16_t data_len;      /**< Amount of data in segment buffer. */
> >
> > +#if RTE_CACHE_LINE_SIZE == 64
> >  	/* fields on second cache line */
> >  	char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
> > +#elif RTE_CACHE_LINE_SIZE == 128
> > +	char pad3[24];
> > +#endif
> >  	void *pool;
> >  	void *next;
> >  };
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index f234ac9..0bf55e0 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -813,8 +813,10 @@ struct rte_mbuf {
> >
> >  	uint16_t vlan_tci_outer;  /**< Outer VLAN Tag Control Identifier (CPU order) */
> >
> > +#if RTE_CACHE_LINE_SIZE == 64
> >  	/* second cache line - fields only used in slow path or on TX */
> >  	MARKER cacheline1 __rte_cache_aligned;
> > +#endif
>
> I suppose you'll need to keep same space reserved for first 64B even on systems with 128B cache-line.
> Otherwise we can endup with different mbuf format for systems with 128B cache-line.

Just to understand, Is there any issue in mbuf format being different
across the systems. I think, we are not sending the mbuf over the wire
or sharing with different system etc. right?

Yes, I do understand the KNI dependency with mbuf.

> Another thing - now we have __rte_cache_aligned all over the places, and I don't know is to double
> sizes of all these structures is a good idea.

I thought so, the only concern I have, what if, the struct split to 64
and one cache line is shared between two core/two different structs which have
the different type of operation(most likely). One extensive write and other one
read, The write makes the line dirty start evicting and read core is
going to suffer. Any thoughts?

If its tradeoff between amount memory and performance, I think, it makes sense
to stick the performance in data plane, Hence split option may be not useful?
right?


> Again,  #if RTE_CACHE_LINE_SIZE == 64 ... all over the places looks a bit clumsy.
> Wonder can we have __rte_cache_aligned/ RTE_CACHE_LINE_SIZE architecture specific,

I think, its architecture specific now

> but introduce RTE_CACHE_MIN_LINE_SIZE(==64)/ __rte_cache_min_aligned and used it for mbuf
> (and might be other places).

Yes, it will help in this specific mbuf case and it make sense
if mbuf going to stay within 2 x 64 CL.

AND/OR

can we introduce something like below to reduce the clutter in
other places, macro name is just not correct, trying to share the view

#define rte_cacheline_diff(for_64, for_128)\
do {\
#if RTE_CACHE_LINE_SIZE == 64\
for_64;
#elif RTE_CACHE_LINE_SIZE == 128\
for_128;\
#endif

OR

Typedef struct rte_mbuf to new abstract type and define for 64 bytes and
128 byte

Jerin

> Konstantin
>
>

  reply	other threads:[~2015-12-08 12:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06 15:59 [dpdk-dev] [PATCH 0/2] fix performance/cache resource issues " Jerin Jacob
2015-12-06 15:59 ` [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue " Jerin Jacob
2015-12-07 15:21   ` Ananyev, Konstantin
2015-12-08 12:45     ` Jerin Jacob [this message]
2015-12-08 16:07       ` Ananyev, Konstantin
2015-12-08 17:49         ` Jerin Jacob
2015-12-09 13:44           ` Ananyev, Konstantin
2015-12-09 14:49             ` Jerin Jacob
2015-12-06 15:59 ` [dpdk-dev] [PATCH 2/2] bitmap: optimize for 128-bytes " Jerin Jacob
2015-12-06 16:30 ` [dpdk-dev] [PATCH 0/2] fix performance/cache resource issues with 128-byte " Thomas Monjalon
2015-12-07  7:26   ` Jerin Jacob
2015-12-07 11:40     ` Thomas Monjalon
2015-12-07 14:33       ` Jerin Jacob
2015-12-07 14:35         ` Thomas Monjalon
2015-12-10 16:36 ` [dpdk-dev] [PATCH v2 0/4] " Jerin Jacob
2015-12-10 16:36   ` [dpdk-dev] [PATCH v2 1/4] eal: Introduce new cache macro definitions Jerin Jacob
2015-12-10 16:36   ` [dpdk-dev] [PATCH v2 2/4] mbuf: fix performance/cache resource issue with 128-byte cache line targets Jerin Jacob
2015-12-10 16:36   ` [dpdk-dev] [PATCH v2 3/4] bitmap: optimize for 128-bytes " Jerin Jacob
2015-12-10 16:36   ` [dpdk-dev] [PATCH v2 4/4] cache/slow-path: reduce cache align requirement for 128-byte cache targets Jerin Jacob
2015-12-11 12:55     ` Ananyev, Konstantin
2015-12-11 13:07       ` Thomas Monjalon
2015-12-11 13:56       ` Jerin Jacob
2015-12-11 14:42         ` Ananyev, Konstantin
2015-12-14  4:32   ` [dpdk-dev] [PATCH v3 0/4] fix performance/cache resource issues with 128-byte cache line targets Jerin Jacob
2015-12-14  4:32     ` [dpdk-dev] [PATCH v3 1/4] eal: Introduce new cache macro definitions Jerin Jacob
2016-01-04 13:15       ` Olivier MATZ
2016-01-06 15:10         ` Jerin Jacob
2015-12-14  4:32     ` [dpdk-dev] [PATCH v3 2/4] mbuf: fix performance/cache resource issue with 128-byte cache line targets Jerin Jacob
2015-12-14  4:32     ` [dpdk-dev] [PATCH v3 3/4] bitmap: optimize for 128-bytes " Jerin Jacob
2015-12-14  4:32     ` [dpdk-dev] [PATCH v3 4/4] cache/slow-path: reduce cache align requirement for 128-byte cache targets Jerin Jacob
2016-01-29  7:45     ` [dpdk-dev] [PATCH v4 0/4] fix performance/cache resource issues with 128-byte cache line targets Jerin Jacob
2016-01-29  7:45       ` [dpdk-dev] [PATCH v4 1/4] eal: Introduce new cache line macro definitions Jerin Jacob
2016-01-29  7:45       ` [dpdk-dev] [PATCH v4 2/4] mbuf: fix performance/cache resource issue with 128-byte cache line targets Jerin Jacob
2016-01-29  7:45       ` [dpdk-dev] [PATCH v4 3/4] bitmap: optimize for 128-bytes " Jerin Jacob
2016-01-29  7:45       ` [dpdk-dev] [PATCH v4 4/4] cache/slow-path: reduce cache align requirement for 128-byte cache targets Jerin Jacob
2016-02-08  9:31       ` [dpdk-dev] [PATCH v4 0/4] fix performance/cache resource issues with 128-byte cache line targets Jerin Jacob
2016-02-08 10:24         ` Jan Viktorin
2016-02-08 10:52           ` Jerin Jacob
2016-02-08 12:56             ` Jan Viktorin
2016-02-11 11:53       ` Thomas Monjalon

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=20151208124527.GA18192@localhost.localdomain \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --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).