DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: David Marchand <david.marchand@redhat.com>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	Ben Walker <benjamin.walker@intel.com>
Subject: Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode selection
Date: Wed, 10 Jul 2019 09:49:59 +0000	[thread overview]
Message-ID: <BYAPR18MB242463D7991F5B8DE6CD9280C8F00@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)

Not sure if it is problem from my email client or David email settings, I am getting the David email ONLY as HTML.
And outlook creating format issues when change to plain text on reply.
It looks like it is due to "Content-Type: multipart/alternative".

Please find inline reply.


From: David Marchand <david.marchand@redhat.com> 
Sent: Wednesday, July 10, 2019 1:40 PM
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Burakov, Anatoly <anatoly.burakov@intel.com>
Cc: dev <dev@dpdk.org>; Thomas Monjalon <thomas@monjalon.net>; Ben Walker <benjamin.walker@intel.com>
Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] bus/pci: fix IOVA as VA mode selection

Hello guys,


> 
> Currently (again, disregarding your interpretation of how IOVA as VA works
> and looking at the actual commit history), we always seem to imply that IOVA
> as PA works for all devices, and we use IOVA_AS_VA flag to indicate that the
> device *also* supports IOVA as VA mode.
> 
> But we don't have any way to express a *requirement* for IOVA as VA mode
> - only for IOVA as PA mode. That is the purpose of the new flag. You are
> stating that the IOVA_AS_VA drv flag is an expression of that requirement,
> but that is not reflected in the codebase - our commit history indicates that
> we don't treat IOVA as VA as hard requirement whenever this flag is
> specified (and i would argue that we shouldn't).

> No objection to further classify it.

I propose to introduce:
* RTE_PCI_DRV_IOVA_AS_PA which means "the combination of the pmd+kmod+hw supports usage of Physical Addresses"
* RTE_PCI_DRV_IOVA_AS_VA which means "the combination of the pmd+kmod+hw supports usage of Virtual Addresses"

- For the pci bus, the algorigthm would be:

devices_want_pa = false
devices_want_va = false

Foreach pci device
  Skip blacklisted devices
  Skip unbound devices (i.e. we only consider devices bound to a known kernel driver)
  Skip unsupported devices (i.e. we only consider devices that have a pmd that supports them)

  If the combination pmd+kmod only supports VA (RTE_PCI_DRV_IOVA_AS_VA capability in driver flags), then devices_want_va = true
  Else if the combination pmd+kmod only supports PA (RTE_PCI_DRV_IOVA_AS_PA capability in driver flags), then devices_want_pa = true

If devices_want_va and !devices_want_pa
  return RTE_IOVA_VA
If devices_want_pa and !devices_want_va
  return RTE_IOVA_PA

return RTE_IOVA_DC

---------------
[Jerin] I am fine with introducing RTE_PCI_DRV_IOVA_AS_PA instead of RTE_PCI_DRV_IOVA_AS_DC(As I proposed earlier).
Only my concern is there may not be any PCIe device which is hitting the following.

If devices_want_pa and !devices_want_va
  return RTE_IOVA_PA

Assuming for i40e etc, You will change to RTE_PCI_DRV_IOVA_AS_PA | RTE_PCI_DRV_IOVA_AS_VA.
No strong option on RTE_PCI_DRV_IOVA_AS_PA vs RTE_PCI_DRV_IOVA_AS_DC.

---------------
Notes:
* the IOMMU limitations are considered as a per device/driver thing, since the kmod is the one that configures the system IOMMU,
* the case "devices_want_pa and devices_want_va" is considered as DC, we leave EAL decide based on the physical addresses availability because we can't comply with all present devices/drivers in the system.
  This means that at bus probe time for a device, we must add a check that the combination is fulfilled (and avoid this check in the drivers themselves).


- For the global bus code, that aggregates the different buses preferences, we need to do the same, while I suspect a bug at the moment.

The algorigthm:

buses_want_pa = false
buses_want_va = false

Foreach bus
  If the bus reports RTE_IOVA_VA, then buses_want_va = true
  Else if the bus reports RTE_IOVA_PA, then buses_want_pa = true

If buses_want_va and !buses_want_pa
  return RTE_IOVA_VA
If buses_want_pa and !buses_want_va
  return RTE_IOVA_PA

return RTE_IOVA_DC

- Finally at EAL level, we keep the current code.

----------------------------------

[Jerin] Algorithm look OK to me.  All of the following devices[1] added RTE_PCI_DRV_IOVA_AS_VA in the driver list
to run in VA mode to enable DPDK to run with out root privilege. But due to recent change it making as PA i.e
need root privilege to run.

May it is a separate topic to dicuss what would be default if the system has IOMMU and device is RTE_PCI_DRV_IOVA_AS_VA | RTE_PCI_DRV_IOVA_AS_PA.
I would say RTE_IOVA_VA. But I don’t know why it changed to RTE_IOVA_PA for hotplug or SPDK?


[1] http://patchwork.dpdk.org/patch/53206/
[2] http://patchwork.dpdk.org/patch/50274/
[3] http://patchwork.dpdk.org/patch/50991/
[4] http://patchwork.dpdk.org/patch/46134/


-----------------------------------

Hope I did not miss anything.
If we agree on this, I will send the changes and an update in the documentation.


-- 
David Marchand


             reply	other threads:[~2019-07-10  9:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10  9:49 Jerin Jacob Kollanukkaran [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-07-08 14:24 jerinj
2019-07-08 18:39 ` David Marchand

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=BYAPR18MB242463D7991F5B8DE6CD9280C8F00@BYAPR18MB2424.namprd18.prod.outlook.com \
    --to=jerinj@marvell.com \
    --cc=anatoly.burakov@intel.com \
    --cc=benjamin.walker@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --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).