DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	Ben Walker <benjamin.walker@intel.com>
Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] bus/pci: fix IOVA as VA mode selection
Date: Tue, 9 Jul 2019 14:50:42 +0100	[thread overview]
Message-ID: <71f982c0-cad0-7ca6-b452-e09b2f9a281c@intel.com> (raw)
In-Reply-To: <c2695938-b74d-750f-0a67-50aeb075a375@intel.com>

On 09-Jul-19 2:30 PM, Burakov, Anatoly wrote:
> On 09-Jul-19 1:11 PM, Jerin Jacob Kollanukkaran wrote:
>>> -----Original Message-----
>>> From: Burakov, Anatoly <anatoly.burakov@intel.com>
>>> Sent: Tuesday, July 9, 2019 5:10 PM
>>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; David Marchand
>>> <david.marchand@redhat.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
>>>>>> ________________________________________
>>>>>>
>>>>>> On Mon, Jul 8, 2019 at 4:25 PM <mailto:jerinj@marvell.com> wrote:
>>>>>> From: Jerin Jacob <mailto:jerinj@marvell.com>
>>>>>>
>>>>>> Existing logic fails to select IOVA mode as VA if driver request to
>>>>>> enable IOVA as VA.
>>>>>>
>>>>>> IOVA as VA has more strict requirement than other modes, so enabling
>>>>>> positive logic for IOVA as VA selection.
>>>>>>
>>>>>> This patch also updates the default IOVA mode as PA for PCI devices
>>>>>> as it has to deal with DMA engines unlike the virtual devices that
>>>>>> may need only IOVA as DC.
>>>>>>
>>>>>> We have three cases:
>>>>>> - driver/hw supports IOVA as PA only
>>>>>>
>>>>>> [Jerin] It is not driver cap, it is more of system cap(IOMMU vs non
>>>>>> IOMMU). We are already addressing that case
>>>>>
>>>>> I don't get how this works. How does "system capability" affect what
>>>>> the device itself supports? Are we to assume that *all* hardware
>>>>> support IOVA as VA by default? "System capability" is more of a bus
>>>>> issue than an individual device issue, is it not?
>>>>
>>>> What I meant is, supporting VA vs PA is function of IOMMU(not the 
>>>> device
>>> attribute).
>>>> Ie. Device makes the  bus master request, if IOMMU available and
>>>> enabled in the SYSTEM , It goes over IOMMU  and translate the IOVA to
>>> physical address.
>>>>
>>>> Another way to put is, Is there any _PCIe_ device which need/requires
>>>> RTE_PCI_DRV_NEED_IOVA_AS_PA in rte_pci_driver.drv_flags
>>>>
>>>>
>>>
>>> Previously, as far as i can tell, the flag was used to indicate 
>>> support for IOVA
>>> as VA mode, not *requirement* for IOVA as VA mode. For example, there
>>> are multiple patches [1][2][3][4] (i'm sure i can find more!) that 
>>> added IOVA
>>> as VA support to various drivers, and they all were worded it in this 
>>> exact way
>>> - "support for IOVA as VA mode", not "require IOVA as VA mode". As 
>>> far as i
>>> can tell, none of these drivers *require* IOVA as VA mode - they 
>>> merely use
>>> this flag to indicate support for it.
>>
>> Some class of devices NEED IOVA as VA for performance reasons.
>> Specially the devices has HW mempool allocators. On those devices If 
>> we don’t use IOVA as VA,
>> Upon getting packet from device, It needs to go over 
>> rte_mem_iova2virt() per
>> packet see driver/net/dppa2. Which has real performance issue.
> 
> I wouldn't classify this as "needing" IOVA. "Need" implies it cannot 
> work without it, whereas in this case it's more of a "highly 
> recommended" rather than "need".
> 
>>>
>>> Now suddenly it turns out that someone somewhere "knew" that "IOVA as
>>> VA" flag in PCI drivers is supposed to indicate *requirement* and not
>>> support, and it appears that this knowledge was not communicated nor
>>> documented anywhere, and is now treated as common knowledge.
>>
>> I think, the confusion here is,  I was under impression that
>> # If device supports IOVA as VA and system runs with IOMMU then
>> the  dpdk should run in IOVA as VA mode.
>> If above statement true then we don’t really need a new flag.
> 
> Exactly. And the flag used to indicate that the device *supports* IOVA 
> as VA, not that it *requires* it.

...unless the driver itself is written in such a way as to simply not 
support VA to PA lookups - in that case, the above suggested way of 
simply not indicating IOVA as PA support would fix the issue in that it 
will require the device to either work in IOVA as VA mode, or fail to 
initialize. Current semantics of only having one flag do not distinguish 
between "can do both PA and VA" and "can only do VA" - hence the 
suggestion of adding an additional flag indicating IOVA as PA support.

-- 
Thanks,
Anatoly

  reply	other threads:[~2019-07-09 13:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08 14:24 [dpdk-dev] " jerinj
2019-07-08 18:39 ` David Marchand
2019-07-08 19:13   ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-09  8:39     ` Bruce Richardson
2019-07-09  9:05       ` Jerin Jacob Kollanukkaran
2019-07-09  9:32         ` Bruce Richardson
2019-07-09  9:44     ` Burakov, Anatoly
2019-07-09 11:13       ` Jerin Jacob Kollanukkaran
2019-07-09 11:40         ` Burakov, Anatoly
2019-07-09 12:11           ` Jerin Jacob Kollanukkaran
2019-07-09 13:30             ` Burakov, Anatoly
2019-07-09 13:50               ` Burakov, Anatoly [this message]
2019-07-09 14:19                 ` Jerin Jacob Kollanukkaran
2019-07-09 14:00               ` Jerin Jacob Kollanukkaran
2019-07-09 14:37                 ` Burakov, Anatoly
2019-07-09 15:04                   ` Thomas Monjalon
2019-07-09 15:06                     ` Burakov, Anatoly
2019-07-09 17:50                   ` Jerin Jacob Kollanukkaran
2019-07-10  8:09                     ` David Marchand
2019-07-09 14:54                 ` Burakov, Anatoly
2019-07-09 14:58                   ` Jerin Jacob Kollanukkaran
2019-07-09 15:02                     ` Burakov, Anatoly
2019-07-09 15:12                       ` Thomas Monjalon
2019-07-09 15:18                         ` Burakov, Anatoly

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=71f982c0-cad0-7ca6-b452-e09b2f9a281c@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=benjamin.walker@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.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 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).