DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] Limiting packet buffers under 4GB
Date: Mon, 4 Nov 2019 16:19:20 +0100	[thread overview]
Message-ID: <20191104151920.gq62kmhu3gfgpcy2@platinum> (raw)
In-Reply-To: <BYAPR18MB2424E2396F4B352EDC80488AC87F0@BYAPR18MB2424.namprd18.prod.outlook.com>

Hi Jerin,

On Mon, Nov 04, 2019 at 12:59:40PM +0000, Jerin Jacob Kollanukkaran wrote:
> Hi Anatoly and All,
> 
> Just wondering what would the side effect of lowering a  _bit_ of static uint64_t baseaddr = 0x100000000 in 
> lib/librte_eal/common/eal_common_memory.c for 64bit systems.
> 
> Use case:
> If we _reserve_ VA address which less than 2^32 ONLY for packet buffers(mbuf), The use cases like
> Pipeline, where need to transfer packets from one core to another cores can use ring element
> size of 4B(32bit) which will reduce the a lot of read and write  to enable better
> performance.
> 
> i.e Since upper 32bits will be zero, it is matter of typecasting of item to read and write from/to ring.
> Essentially memcpy overhead for moving pointers over the ring will be half.
> 
> Is baseaddr set to 2^32 to make sure that secondary process will have more _chance_ of getting
> the baseaddr in order for DPDK to work?
> 
> Thoughts on above? On general to reduce the mbuf pointer storage requirement for ring?

There are use cases where the mbufs take more than 4GB of memory,
typically for protocols that do a lot of buffering/queing. So if
anything is done in that direction, it has to be an option.

  reply	other threads:[~2019-11-04 15:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-04 12:59 Jerin Jacob Kollanukkaran
2019-11-04 15:19 ` Olivier Matz [this message]
2019-11-06 12:16 ` Burakov, Anatoly
2019-11-06 12:39   ` Jerin Jacob

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=20191104151920.gq62kmhu3gfgpcy2@platinum \
    --to=olivier.matz@6wind.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.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).