DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Stojaczyk, Dariusz" <dariusz.stojaczyk@intel.com>
To: Eric Zhang <eric.zhang@windriver.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: santosh <santosh.shukla@caviumnetworks.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	"Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Allain.Legacy@windriver.com" <Allain.Legacy@windriver.com>,
	"Matt.Peters@windriver.com" <Matt.Peters@windriver.com>
Subject: Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical
Date: Mon, 17 Sep 2018 08:32:49 +0000	[thread overview]
Message-ID: <FBE7E039FA50BF47A673AD0BD3CD56A8461E7DB4@HASMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <2dab0826-ee74-89fe-c012-ad9dd8e5f0cc@windriver.com>

Hi,

A little bit of self-advertising:
I recently pushed patches that will make DPDK default to RTE_IOVA_VA when physical addresses were not explicitly requested and are not available, e.g. when running as a non-privileged user. It shouldn't cause any conflicts with the changes you're proposing here, but any review is welcome.

pci/linux: use RTE_IOVA_VA whenever possible http://patches.dpdk.org/patch/44392/ 
[v2] eal/bus: use RTE_IOVA_PA only if phys addresses are available http://patches.dpdk.org/patch/44420/

As for the --iova-mode=<pa/va>, I agree it could help DPDK use cases where most drivers or devices are hotplugged/hotattached at runtime - e.g. SPDK, it could certainly make use of such param.

D.

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Eric Zhang
> Sent: Tuesday, September 11, 2018 7:22 PM
> To: Burakov, Anatoly <anatoly.burakov@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>
> Cc: santosh <santosh.shukla@caviumnetworks.com>;
> hemant.agrawal@nxp.com; Gaëtan Rivet <gaetan.rivet@6wind.com>;
> Richardson, Bruce <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
> 
> 
> 
> On 09/07/2018 04:13 PM, Eric Zhang wrote:
> >
> >
> > On 09/07/2018 05:26 AM, Burakov, Anatoly wrote:
> >> On 06-Sep-18 8:34 AM, Jerin Jacob wrote:
> >>> -----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.
> >>>
> >>
> >> That seems like a better option to me, +1. As far as i know, at the
> >> moment if there are no devices attached at all, or if there are only
> >> vdev devices attached, DPDK will default to IOVA as PA mode for no
> >> good reason; such a change would certainly fix this.
> > Thanks for the suggestions however our virtual device doesn't run dpdk
> > vdev code so we can't use the flag.
> > Notice that in eal.c there is one workaround that force iova to be PA
> > per virtual device is not directly attached to pci. That case is
> > checking kni module. Ours is a similar case that virtual device not
> > attach pci directly.
> > So we have to turn to force iova to PA either 1. compilation option 2.
> > eal option.  Which one should be the preference by taking into
> > consideration that align with upstream?
> >
> > Thanks
> >
> Any comments?
> >>
> >>>
> >>>>
> >>>> Thanks
> >>>> Eric
> >>>>
> >>>
> >>
> >>
> >


  reply	other threads:[~2018-09-17  8:33 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
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 [this message]
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=FBE7E039FA50BF47A673AD0BD3CD56A8461E7DB4@HASMSX105.ger.corp.intel.com \
    --to=dariusz.stojaczyk@intel.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=jerin.jacob@caviumnetworks.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).