DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	"Ding, Xuan" <xuan.ding@intel.com>,
	 "dev@dpdk.org" <dev@dpdk.org>
Cc: "maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"Xia, Chenbo" <chenbo.xia@intel.com>,
	"Hu, Jiayu" <jiayu.hu@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc: announce change in vfio dma mapping
Date: Wed, 1 Sep 2021 12:01:30 +0100	[thread overview]
Message-ID: <032e666a-9ada-f4c0-36bc-ad9b5fac4359@intel.com> (raw)
In-Reply-To: <926d7065-481f-b84e-1d05-bdeebd31d6ea@intel.com>

On 01-Sep-21 10:56 AM, Ferruh Yigit wrote:
> On 9/1/2021 2:41 AM, Ding, Xuan wrote:
>> Hi Ferruh,
>>
>>> -----Original Message-----
>>> From: Yigit, Ferruh <ferruh.yigit@intel.com>
>>> Sent: Wednesday, September 1, 2021 12:01 AM
>>> To: Ding, Xuan <xuan.ding@intel.com>; dev@dpdk.org; Burakov, Anatoly
>>> <anatoly.burakov@intel.com>
>>> Cc: maxime.coquelin@redhat.com; Xia, Chenbo <chenbo.xia@intel.com>; Hu,
>>> Jiayu <jiayu.hu@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>
>>> Subject: Re: [PATCH] doc: announce change in vfio dma mapping
>>>
>>> On 8/31/2021 2:10 PM, Xuan Ding wrote:
>>>> Currently, the VFIO subsystem will compact adjacent DMA regions for the
>>>> purposes of saving space in the internal list of mappings. This has a
>>>> side effect of compacting two separate mappings that just happen to be
>>>> adjacent in memory. Since VFIO implementation on IA platforms also does
>>>> not allow partial unmapping of memory mapped for DMA, the current
>>> DPDK
>>>> VFIO implementation will prevent unmapping of accidentally adjacent
>>>> maps even though it could have been unmapped [1].
>>>>
>>>> The proper fix for this issue is to change the VFIO DMA mapping API to
>>>> also include page size, and always map memory page-by-page.
>>>>
>>>> [1] https://mails.dpdk.org/archives/dev/2021-July/213493.html
>>>>
>>>> Signed-off-by: Xuan Ding <xuan.ding@intel.com>
>>>> ---
>>>>   doc/guides/rel_notes/deprecation.rst | 3 +++
>>>>   1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/doc/guides/rel_notes/deprecation.rst
>>> b/doc/guides/rel_notes/deprecation.rst
>>>> index 76a4abfd6b..1234420caf 100644
>>>> --- a/doc/guides/rel_notes/deprecation.rst
>>>> +++ b/doc/guides/rel_notes/deprecation.rst
>>>> @@ -287,3 +287,6 @@ Deprecation Notices
>>>>     reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and
>>> other
>>>>     information from the crypto/security operation. This field will be used to
>>>>     communicate events such as soft expiry with IPsec in lookaside mode.
>>>> +
>>>> +* vfio: the functions `rte_vfio_container_dma_map` will be amended to
>>>> +  include page size. This change is targeted for DPDK 22.02.
>>>>
>>>
>>> Is this means adding a new parameter to API?
>>> If so this is an ABI/API break and we can't do this change in the 22.02.
>>
>> Our original plan is add a new parameter in order not to use a new function name, so you mean, any changes to the API can only be done in the LTS version?
>> If so, we can only add a new API and retire the old one in 22.11.
>>
> 
> We can add a new API anytime. Adding new parameter to an existing API can be
> done on the ABI break release.

So, 22.11 then?

> 
> You can add the new API in this release, and start using it.
> And mark the old API as deprecated in this release. This lets existing binaries
> to keep using it, but app needs to switch to new API for compilation.
> Old API can be removed on 22.11, and you will need a deprecation notice before
> 22.11 for it.
> 
> Is above plan works for you?
> 

We have slightly rethought our approach, and the functionality that Xuan 
requires does not rely on this API. They can, for all intents and 
purposes, be considered unrelated issues.

I still think it's a good idea to update the API that way, so I would 
like to do that, and if we have to wait until 22.11 to fix it, I'm OK 
with that. Since there no longer is any urgency here, it's acceptable to 
wait for the next LTS to break it.

-- 
Thanks,
Anatoly

  reply	other threads:[~2021-09-01 11:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 13:10 Xuan Ding
2021-08-31 13:46 ` Burakov, Anatoly
2021-08-31 16:01 ` Ferruh Yigit
2021-09-01  1:41   ` Ding, Xuan
2021-09-01  9:56     ` Ferruh Yigit
2021-09-01 11:01       ` Burakov, Anatoly [this message]
2021-09-01 11:42         ` Ferruh Yigit
2021-09-01 13:25           ` Burakov, Anatoly
2021-09-02  9:50             ` Ferruh Yigit
2021-09-02 16:13               ` Kinsella, Ray
2021-09-06  8:51                 ` Ding, Xuan
2021-09-06 13:43                   ` Ferruh Yigit
2021-09-07 15:21                     ` Burakov, Anatoly
2021-09-07 16:08                       ` Ferruh Yigit
2021-09-08  8:59                         ` Kinsella, Ray

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=032e666a-9ada-f4c0-36bc-ad9b5fac4359@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=chenbo.xia@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jiayu.hu@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=xuan.ding@intel.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).