From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: Olivier Matz <olivier.matz@6wind.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
David Christensen <drc@linux.vnet.ibm.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
Shahaf Shuler <shahafs@mellanox.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Gavin Hu <gavin.hu@arm.com>,
"viktorin@rehivetech.com" <viktorin@rehivetech.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>
Subject: [dpdk-dev] Mbuf memory alignment constraints for (micro)architectures
Date: Wed, 30 Oct 2019 18:02:15 +0000 [thread overview]
Message-ID: <BYAPR18MB24249DB7169305B7BE0C73F2C8600@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)
CC: Arch and platform maintainers
While reviewing the mempool objection allocation requirements in the code,
A) it's found that in the default case, mempool objects have padding
in the object trailer to have start addresses of objects among the different channels,
to enable equally load on the DRAM channel to have better performance
# More documentation is here
https://doc.dpdk.org/guides/prog_guide/mempool_lib.html
in section 8.3. Memory Alignment Constraints
B) The optimize_object_size() does the channel distribution requirement
by the following formula
new_obj_size = (obj_size + RTE_MEMPOOL_ALIGN_MASK) / RTE_MEMPOOL_ALIGN;
while (get_gcd(new_obj_size, nrank * nchan) != 1)
new_obj_size++;
C) The formula mentioned in the (B) is NOT generic. At least of the octeontx2 SoC
The memory/DDR controller works in different way. Where by:
# It does XOR operation of some of physical address lines(not the user space VA address)
to compute the hash and that the function defines the actual channel.
The XOR(kind of CRC) scheme is useful because there is natural channel distribution
based on the address i.e No need to have padding to waste memory
So, in short the padding scheme does not need for some SoC. I trying to send the patch
to fix it. So the questions is,
# Is PPC and other ARM SoC has formula (B) to compute DRAM channel distribution ? or
Is it specific to x86? That would define where the hooks needs to added to have proper fix.
next reply other threads:[~2019-10-30 18:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 18:02 Jerin Jacob Kollanukkaran [this message]
2019-11-11 14:01 ` Gavin Hu (Arm Technology China)
2019-11-12 2:36 ` Gavin Hu (Arm Technology China)
2019-11-13 23:08 ` David Christensen
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=BYAPR18MB24249DB7169305B7BE0C73F2C8600@BYAPR18MB2424.namprd18.prod.outlook.com \
--to=jerinj@marvell.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=drc@linux.vnet.ibm.com \
--cc=gavin.hu@arm.com \
--cc=hemant.agrawal@nxp.com \
--cc=konstantin.ananyev@intel.com \
--cc=olivier.matz@6wind.com \
--cc=shahafs@mellanox.com \
--cc=viktorin@rehivetech.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).