DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: ferruh.yigit@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 3/5] common/dpaax: add library for PA VA translation table
Date: Tue, 25 Sep 2018 15:08:59 +0100	[thread overview]
Message-ID: <bf466bab-f1df-6531-e8aa-845d634217a5@intel.com> (raw)
In-Reply-To: <5fb7c022-228f-89d3-43b6-5d08e258fba4@nxp.com>

On 25-Sep-18 3:00 PM, Shreyansh Jain wrote:
> On Tuesday 25 September 2018 07:21 PM, Burakov, Anatoly wrote:
>> On 25-Sep-18 2:39 PM, Shreyansh Jain wrote:
>>> Hello Anatoly,
>>>
>>> On Tuesday 25 September 2018 06:58 PM, Burakov, Anatoly wrote:
>>>> On 25-Sep-18 1:54 PM, Shreyansh Jain wrote:
>>>>> A common library, valid for dpaaX drivers, which is used to maintain
>>>>> a local copy of PA->VA translations.
>>>>>
>>>>> In case of physical addressing mode (one of the option for FSLMC, and
>>>>> only option for DPAA bus), the addresses of descriptors Rx'd are
>>>>> physical. These need to be converted into equivalent VA for rte_mbuf
>>>>> and other similar calls.
>>>>>
>>>>> Using the rte_mem_virt2iova or rte_mem_virt2phy is expensive. This
>>>>> library is an attempt to reduce the overall cost associated with
>>>>> this translation.
>>>>>
>>>>> A small table is maintained, containing continuous entries
>>>>> representing a continguous physical range. Each of these entries
>>>>> stores the equivalent VA, which is fed during mempool creation, or
>>>>> memory allocation/deallocation callbacks.
>>>>>
>>>>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>>>>> ---
>>>>
>>>> Hi Shreyansh,
>>>>
>>>> So, basically, you're reimplementing old DPDK's memory view (storing 
>>>> VA's in a PA-centric way). Makes sense :)
>>>
>>> Yes, and frankly, I couldn't come up with any other way.
>>>
>>>>
>>>> I should caution you that right now, external memory allocator 
>>>> implementation does *not* trigger any callbacks for newly added 
>>>> memory. So, anything coming from external memory will not be 
>>>> reflected in your table, unless it happens to be already there 
>>>> before dpaax_iova_table_populate() gets called. This patchset makes 
>>>> a good argument for why perhaps it should trigger callbacks. Thoughts?
>>>
>>> Oh. Then I must be finishing reading through your patches for 
>>> external memory sooner. I didn't realize this.
>>
>> To be clear, the current implementation of external memory allocators 
>> is not necessarily final - it's not too late to add callbacks to 
>> enable your use case better, if that's required (and it should be 
>> pretty easy to implement as well).
>>
> 
> Is there any reason why external may not be raising call back right now? 
> I might have missed any previous conversation on this. Or may be, it is 
> just lack of need.

Well, pretty much - it didn't occur to me that it may be needed. I 
specifically went out of my way to note that it is the responsibility of 
the user to perform any DMA mappings, but i missed the fact that there 
may be other users interested to know that a user has just added a new 
external memory segment.

> 
> As for whether it is required - I do see a need. It is definitely 
> possible that after rte_eal_init has been completed (and underlying 
> probe), applications allocate memory. In which case, even existing 
> memevent callbacks (like the one in fslmc_bus, which VFIO/DMA maps the 
> area) would have issues. From the external memory patchset, I do see 
> that it is assumed DMA mapping is caller's responsibility.
> 
> Having such callback would help drives reduce that throwback of 
> responsibility.

I do not want to assume that user necessarily wants to map external 
memory for DMA unless explicitly asked to do so. At the same time, i can 
see that some uses may not have anything to do with DMA mapping and may 
instead be cases like yours, where you just need the address. In our 
case, we can just ignore external memory in VFIO and virtio callbacks, 
but still allow other callbacks to handle external memory as they see fit.

> 
> (Speaking of external memory patches, I also realize that my memevent 
> callback in this patch series need to handle msl->external).

Yes, we have to be careful on merge.

> 


-- 
Thanks,
Anatoly

  reply	other threads:[~2018-09-25 14:09 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 12:54 [dpdk-dev] [PATCH 0/5] Add a PA-VA Translation table for DPAAx Shreyansh Jain
2018-09-25 12:54 ` [dpdk-dev] [PATCH 1/5] bus/fslmc: fix physical addressing check Shreyansh Jain
2018-09-25 12:54 ` [dpdk-dev] [PATCH 2/5] drivers: common as dependency for bus Shreyansh Jain
2018-09-25 12:54 ` [dpdk-dev] [PATCH 3/5] common/dpaax: add library for PA VA translation table Shreyansh Jain
2018-09-25 13:28   ` Burakov, Anatoly
2018-09-25 13:39     ` Shreyansh Jain
2018-09-25 13:51       ` Burakov, Anatoly
2018-09-25 14:00         ` Shreyansh Jain
2018-09-25 14:08           ` Burakov, Anatoly [this message]
2018-09-26 10:16             ` Burakov, Anatoly
2018-10-09 10:45       ` Shreyansh Jain
2018-10-11  9:03         ` Burakov, Anatoly
2018-10-11 10:02           ` Shreyansh Jain
2018-10-11 10:07             ` Shreyansh Jain
2018-10-11 10:13               ` Burakov, Anatoly
2018-10-11 10:39                 ` Shreyansh Jain
2018-10-11 10:46                   ` Burakov, Anatoly
2018-10-11 10:09             ` Burakov, Anatoly
2018-09-25 12:54 ` [dpdk-dev] [PATCH 4/5] dpaa: enable dpaax library Shreyansh Jain
2018-09-25 12:54 ` [dpdk-dev] [PATCH 5/5] fslmc: " Shreyansh Jain
2018-10-09 11:25 ` [dpdk-dev] [PATCH v2 0/5] Add a PA-VA Translation table for DPAAx Shreyansh Jain
2018-10-09 11:25   ` [dpdk-dev] [PATCH v2 1/5] bus/fslmc: fix physical addressing check Shreyansh Jain
2018-10-12  9:01     ` Pavan Nikhilesh
2018-10-12 10:44       ` Shreyansh Jain
2018-10-12 16:29         ` Pavan Nikhilesh
2018-10-09 11:25   ` [dpdk-dev] [PATCH v2 2/5] drivers: common as dependency for bus Shreyansh Jain
2018-10-09 11:25   ` [dpdk-dev] [PATCH v2 3/5] common/dpaax: add library for PA VA translation table Shreyansh Jain
2018-10-09 11:25   ` [dpdk-dev] [PATCH v2 4/5] dpaa: enable dpaax library Shreyansh Jain
2018-10-09 11:25   ` [dpdk-dev] [PATCH v2 5/5] fslmc: " Shreyansh Jain
2018-10-13 12:21   ` [dpdk-dev] [PATCH v3 0/5] Add a PA-VA Translation table for DPAAx Shreyansh Jain
2018-10-13 12:21     ` [dpdk-dev] [PATCH v3 1/5] bus/fslmc: fix physical addressing check Shreyansh Jain
2018-10-13 16:08       ` Pavan Nikhilesh
2018-10-15  6:36         ` Shreyansh Jain
2018-10-13 12:21     ` [dpdk-dev] [PATCH v3 2/5] drivers: common as dependency for bus Shreyansh Jain
2018-10-13 12:21     ` [dpdk-dev] [PATCH v3 3/5] common/dpaax: add library for PA VA translation table Shreyansh Jain
2018-10-13 12:21     ` [dpdk-dev] [PATCH v3 4/5] dpaa: enable dpaax library Shreyansh Jain
2018-10-13 12:21     ` [dpdk-dev] [PATCH v3 5/5] fslmc: " Shreyansh Jain
2018-10-15  6:41     ` [dpdk-dev] [PATCH v4 0/5] Add a PA-VA Translation table for DPAAx Shreyansh Jain
2018-10-15  6:41       ` [dpdk-dev] [PATCH v4 1/5] bus/fslmc: fix physical addressing check Shreyansh Jain
2018-10-15  6:41       ` [dpdk-dev] [PATCH v4 2/5] drivers: common as dependency for bus Shreyansh Jain
2018-10-15  6:42       ` [dpdk-dev] [PATCH v4 3/5] common/dpaax: add library for PA VA translation table Shreyansh Jain
2018-10-15  6:42       ` [dpdk-dev] [PATCH v4 4/5] dpaa: enable dpaax library Shreyansh Jain
2018-10-15  6:42       ` [dpdk-dev] [PATCH v4 5/5] fslmc: " Shreyansh Jain
2018-10-15 12:01       ` [dpdk-dev] [PATCH v5 0/5] Shreyansh Jain
2018-10-15 12:01         ` [dpdk-dev] [PATCH v5 1/5] bus/fslmc: fix physical addressing check Shreyansh Jain
2018-10-16 10:02           ` Thomas Monjalon
2018-10-15 12:01         ` [dpdk-dev] [PATCH v5 2/5] drivers: common as dependency for bus Shreyansh Jain
2018-10-15 12:01         ` [dpdk-dev] [PATCH v5 3/5] common/dpaax: add library for PA VA translation table Shreyansh Jain
2018-10-15 23:17           ` Thomas Monjalon
2018-10-15 12:01         ` [dpdk-dev] [PATCH v5 4/5] dpaa: enable dpaax library Shreyansh Jain
2018-10-15 12:01         ` [dpdk-dev] [PATCH v5 5/5] fslmc: " Shreyansh Jain
2018-10-16 10:18         ` [dpdk-dev] [PATCH v5 0/5] Thomas Monjalon

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=bf466bab-f1df-6531-e8aa-845d634217a5@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=shreyansh.jain@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).