From: santosh <santosh.shukla@caviumnetworks.com>
To: hemant.agrawal@nxp.com, "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: eric zhang <eric.zhang@windriver.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, 30 Aug 2018 18:29:10 +0530 [thread overview]
Message-ID: <a8b41461-9888-b88f-7b3b-1c5a4b225e37@caviumnetworks.com> (raw)
In-Reply-To: <0f19de06-fccd-eff2-b33e-71d49a005dbb@nxp.com>
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/
next prev parent reply other threads:[~2018-08-30 12:59 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 [this message]
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
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=a8b41461-9888-b88f-7b3b-1c5a4b225e37@caviumnetworks.com \
--to=santosh.shukla@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 \
/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).