All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
	santosh <santosh.shukla@caviumnetworks.com>,
	thomas@monjalon.net, dev@dpdk.org, hemant.agrawal@nxp.com
Subject: Re: [RFC] eal/memory: introducing an option to set iova as va
Date: Tue, 6 Jun 2017 16:11:55 +0530	[thread overview]
Message-ID: <20170606104154.GB20333@jerin> (raw)
In-Reply-To: <20170606101308.GL18840@bidouze.vm.6wind.com>

-----Original Message-----
> Date: Tue, 6 Jun 2017 12:13:08 +0200
> From: Gaëtan Rivet <gaetan.rivet@6wind.com>
> To: Bruce Richardson <bruce.richardson@intel.com>
> Cc: santosh <santosh.shukla@caviumnetworks.com>, 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
> User-Agent: Mutt/1.5.23 (2014-03-12)
> 
> > 
> > That sounds a more complete solution. However, it's probably a lot of
> > work to implement. :-)
> > 
> > I also wonder if we want to simplify things a little and disallow
> > mixed-mode operation i.e. all devices have to use UIO or all use VFIO?
> > Would that help to allow simplification or other options. Having a whole
> > new bus type seems strange for this. Can each bus just report whether
> > it's members require physical addresses. Then the EAL can manage a
> > single flag to report whether we are using VA or PA?
> > 
> 
> Implementing this at a bus level requires all buses to have drivers
> iterators, which are currently not exposed, or force all buses to
> actively report drivers capabilities upon successful probing. The former
> is a sizeable evolution while the latter leads to having duplicated code
> in all bus->probe() implementation, which seems unsound.
> 
> I may be mistaken, but is this iova mode not currently limited to
> VFIO? Should this API be made generic for all buses or is it only
> relevant to the PCI bus?
> 
> If it can stay specific to the PCI bus, then it should simplify greatly
> the implementation.

It not PCI bus specific. We can have VFIO platform bus too. NXP bus is a
VFIO platform bus. I think, This will help NXP bus as well as currently
they are using #ifdef scheme to select PA vs VA.

  reply	other threads:[~2017-06-06 10:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24 16:11 [RFC] eal/memory: introducing an option to set iova as va Santosh Shukla
2017-06-02  4:24 ` santosh
2017-06-02  9:27   ` Bruce Richardson
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 [this message]
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=20170606104154.GB20333@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=hemant.agrawal@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.