DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Eric Zhang <eric.zhang@windriver.com>
Cc: santosh <santosh.shukla@caviumnetworks.com>,
	hemant.agrawal@nxp.com, "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	bruce.richardson@intel.com, dev@dpdk.org,
	Allain.Legacy@windriver.com, Matt.Peters@windriver.com
Subject: Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical
Date: Thu, 6 Sep 2018 13:04:49 +0530	[thread overview]
Message-ID: <20180906073449.GA20576@jerin> (raw)
In-Reply-To: <9ae6e3dd-5f33-d874-9a58-730435b58de3@windriver.com>

-----Original Message-----
> Date: Tue, 4 Sep 2018 23:40:36 -0400
> From: Eric Zhang <eric.zhang@windriver.com>
> To: santosh <santosh.shukla@caviumnetworks.com>, hemant.agrawal@nxp.com,
>  Gaëtan Rivet <gaetan.rivet@6wind.com>, "Burakov, Anatoly"
>  <anatoly.burakov@intel.com>
> CC: bruce.richardson@intel.com, dev@dpdk.org, Allain.Legacy@windriver.com,
>  Matt.Peters@windriver.com
> Subject: Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>  Thunderbird/52.9.1
> 
> On 08/30/2018 08:59 AM, santosh wrote:
> > On Thursday 30 August 2018 05:43 PM, Hemant wrote:
> > > External Email
> > > 
> > > Hi,
> > > 
> > > On 8/30/2018 3:13 PM, Gaëtan Rivet wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Aug 30, 2018 at 10:09:04AM +0100, Burakov, Anatoly wrote:
> > > > > On 29-Aug-18 4:58 PM, eric zhang wrote:
> > > > > > This patch adds a configuration option to force the IOVA mode to
> > > > > > physical address (PA). There exists virtual devices that are not
> > > > > > directly attached to the PCI bus, and therefore the auto detection
> > > > > > of the IOVA mode based on probing the PCI bus and IOMMU configuration
> > > > > > may not report the required addressing mode. Having the configuration
> > > > > > option permits the mode to be explicitly configured in this scenario.
> > > > > > 
> > > > > > Signed-off-by: eric zhang <eric.zhang@windriver.com>
> > > > > > ---
> > > > > Defining this at compile-time seems like an overkill. Wouldn't it be better
> > > > > to just add an EAL command-line option to force IOVA mode to a particular
> > > > > value?
> > > That is a good suggestion.
> > > > > --
> > > > > Thanks,
> > > > > Anatoly
> > > > What is the bus of these devices and why not implement get_iommu_class
> > > > in it?
> > > There are cases, where you are using dpdk libraries with external
> > > libraries and you need to change the default behavior DPDK lib to use
> > > physical address instead of virtual address.
> > > Providing an option to user will help.
> > > 
> > > 
> > More appropriate solution could be:
> > * Either fix it at bus layer .. i.e.. get_iommu_class()..
> > * Or introduce something like [1] --iova-mode=<pa/va> param.
> > 
> > Former is better solution than latter if autodetection is a key criteria.
> > Thanks.
> > 
> > [1] http://patchwork.dpdk.org/patch/25192/
> > 
> It's not generic which couldn't be fixed at bus layer.
> So what's the preference of EAL option or compile time solution?
> Adding --iova-mode as patch [1] will overrivde auto-detection
> rte_bus_get_iommu_class()
> make it no use; compile time solution will align with upstream and keep
> new atuodetection
> solution in #ifndef.

If it is for vdev devices, why not introduce something like
RTE_PCI_DRV_IOVA_AS_VA and let vdev device describe its personality.
And based on the devices(flags) on vdev bus, rte_bus_get_iommu_class()
of vdev can decide the mode just like PCI bus.


> 
> Thanks
> Eric
> 

  reply	other threads:[~2018-09-06  7:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 15:58 eric zhang
2018-08-30  6:13 ` Hemant
2018-08-30  9:09 ` Burakov, Anatoly
2018-08-30  9:43   ` Gaëtan Rivet
2018-08-30 12:13     ` Hemant
2018-08-30 12:59       ` santosh
2018-08-30 13:56         ` Legacy, Allain
2018-08-30 13:58           ` santosh
2018-09-05  3:40         ` Eric Zhang
2018-09-06  7:34           ` Jerin Jacob [this message]
2018-09-07  9:26             ` Burakov, Anatoly
2018-09-07 20:13               ` Eric Zhang
2018-09-11 17:21                 ` Eric Zhang
2018-09-17  8:32                   ` Stojaczyk, Dariusz
2018-09-17 19:04                     ` Eric Zhang

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=20180906073449.GA20576@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=Allain.Legacy@windriver.com \
    --cc=Matt.Peters@windriver.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=eric.zhang@windriver.com \
    --cc=gaetan.rivet@6wind.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=santosh.shukla@caviumnetworks.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).