DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: santosh <santosh.shukla@caviumnetworks.com>
Cc: thomas@monjalon.net, dev@dpdk.org,
	jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com
Subject: Re: [dpdk-dev] [RFC] eal/memory: introducing an option to set iova as va
Date: Fri, 2 Jun 2017 10:27:35 +0100	[thread overview]
Message-ID: <20170602092735.GA51388@bricha3-MOBL3.ger.corp.intel.com> (raw)
In-Reply-To: <79f1e8ae-d2cc-e49e-a17d-73c7185b26f8@caviumnetworks.com>

On Fri, Jun 02, 2017 at 09:54:46AM +0530, santosh wrote:
> Ping?
> 
> On Wednesday 24 May 2017 09:41 PM, Santosh Shukla wrote:
> 
> > Some NPU hardware like OCTEONTX follows push model to get
> > the packet from the pktio device. Where packet allocation
> > and freeing done by the HW. Since HW can operate only on
> > IOVA with help of SMMU/IOMMU, When packet receives from the
> > Ethernet device, It is the IOVA address(which is PA in existing scheme).
> >
> > Mapping IOVA as PA is expensive on those HW, where every
> > packet needs to be converted to VA from PA/IOVA.
> >
> > This patch proposes the scheme where the user can set IOVA
> > as VA by using an eal command line argument. That helps to
> > avoid costly lookup for VA in SW by leveraging the SMMU
> > translation feature.
> >
> > Signed-off-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
> > ---
Hi,

I agree this is a problem that needs to be solved, but this doesn't look
like a particularly future-proofed solution. Given that we should
use the IOMMU on as many platforms as possible for protection, we
probably need to find an automatic way for DPDK to use IO addresses
correctly. Is this therefore better done as part of the VFIO and
UIO-specific code in EAL - as that is the part that knows how the memory
mapping is done, and in the VFIO case, what address ranges were
programmed in. The mempool driver was something else I considered but it
is probably too high a level to implement this.

So, in short, I don't particularly like this solution, but I could live
with it as a short-term option. Longer term though, I think we need a
better way to support using IO addresses rather than physical addresses
- I just don't know what that would look like or where it would sit/live.

/Bruce

  reply	other threads:[~2017-06-02  9:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24 16:11 Santosh Shukla
2017-06-02  4:24 ` santosh
2017-06-02  9:27   ` Bruce Richardson [this message]
2017-06-05  4:54     ` santosh
2017-06-06  9:57       ` Bruce Richardson
2017-06-06 10:13         ` Gaëtan Rivet
2017-06-06 10:41           ` Jerin Jacob
2017-06-06 10:38         ` 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=20170602092735.GA51388@bricha3-MOBL3.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=santosh.shukla@caviumnetworks.com \
    --cc=thomas@monjalon.net \
    /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).