From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 92ABFA0524
for <public@inbox.dpdk.org>; Mon, 27 Jul 2020 11:24:40 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 2D82B1C0AD;
Mon, 27 Jul 2020 11:24:40 +0200 (CEST)
Received: from mga12.intel.com (mga12.intel.com [192.55.52.136])
by dpdk.org (Postfix) with ESMTP id E1EE11BFE0;
Mon, 27 Jul 2020 11:24:35 +0200 (CEST)
IronPort-SDR: d/RnKbQdubViGKEGK8h6Q1B/pJ35bWm7Shy0H2NyYnmY0KftNfelNhkj3nbBcgQ9xAGRwsm49h
RzVKsrLV5oPg==
X-IronPort-AV: E=McAfee;i="6000,8403,9694"; a="130528886"
X-IronPort-AV: E=Sophos;i="5.75,402,1589266800"; d="scan'208";a="130528886"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58])
by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
27 Jul 2020 02:24:34 -0700
IronPort-SDR: olzxm06AD9LDJFFMxnee/meujt/pEgwwSQo/AQQQSUfWD6wWmSPrBjopsdH9B6KY81nZQMT/fP
8MyQy5GFrhyA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.75,402,1589266800"; d="scan'208";a="329613220"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.214.224.54])
([10.214.224.54])
by orsmga007.jf.intel.com with ESMTP; 27 Jul 2020 02:24:31 -0700
To: wangyunjian <wangyunjian@huawei.com>, "dev@dpdk.org" <dev@dpdk.org>,
"david.marchand@redhat.com" <david.marchand@redhat.com>
Cc: "Lilijun (Jerry)" <jerry.lilijun@huawei.com>,
xudingke <xudingke@huawei.com>, "stable@dpdk.org" <stable@dpdk.org>
References: <cdb0d6482a5c3a5d7d23625d230d9ef41d657320.1594903876.git.wangyunjian@huawei.com>
<1595515713-24640-1-git-send-email-wangyunjian@huawei.com>
<c35b31da-703e-d4d4-6283-0bb4e8ad57e2@intel.com>
<34EFBCA9F01B0748BEB6B629CE643AE60D0EAAD8@dggemm513-mbx.china.huawei.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <a75edde1-a30c-71d1-5191-6c37cad23779@intel.com>
Date: Mon, 27 Jul 2020 10:24:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <34EFBCA9F01B0748BEB6B629CE643AE60D0EAAD8@dggemm513-mbx.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] eal/linux: do not create
user mem map repeatedly when it exists
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On 25-Jul-20 10:59 AM, wangyunjian wrote:
>> -----Original Message-----
>> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
>> Sent: Friday, July 24, 2020 9:25 PM
>> To: wangyunjian <wangyunjian@huawei.com>; dev@dpdk.org;
>> david.marchand@redhat.com
>> Cc: Lilijun (Jerry) <jerry.lilijun@huawei.com>; xudingke
>> <xudingke@huawei.com>; stable@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v2] eal/linux: do not create user mem map
>> repeatedly when it exists
>>
>> On 23-Jul-20 3:48 PM, wangyunjian wrote:
>>> From: Yunjian Wang <wangyunjian@huawei.com>
>>>
>>> Currently, we will create new user mem map entry for the same memory
>>> segment, but in fact it has already been added to the user mem maps.
>>> It's not necessary to create it twice.
>>>
>>> To resolve the issue, add support to remove the same entry in the
>>> function compact_user_maps().
>>>
>>> Fixes: 0cbce3a167f1 ("vfio: skip DMA map failure if already mapped")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
>>> ---
>>> v2:
>>> * Remove the same entry in the function compact_user_maps()
>>> ---
>>> lib/librte_eal/linux/eal_vfio.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/lib/librte_eal/linux/eal_vfio.c b/lib/librte_eal/linux/eal_vfio.c
>>> index abb12a354..df99307b7 100644
>>> --- a/lib/librte_eal/linux/eal_vfio.c
>>> +++ b/lib/librte_eal/linux/eal_vfio.c
>>> @@ -167,6 +167,10 @@ adjust_map(struct user_mem_map *src, struct
>> user_mem_map *end,
>>> static int
>>> merge_map(struct user_mem_map *left, struct user_mem_map *right)
>>> {
>>> + /* merge the same maps into one */
>>> + if (memcmp(left, right, sizeof(struct user_mem_map)) == 0)
>>> + goto out;
>>> +
>>
>> merge_map looks for adjacent maps only, but does not handle maps that
>> are wholly contained within one another ("the same map" also matches
>> this definition). wouldn't it be better to check for that instead of
>> *just* handling identical maps?
>
> What about using the initial implementation?
> We don't create new user mem map entry for the same memory segment.
I don't like this implementation because it relies on particulars of how
VFIO mapping work without explicitly specifying them. I.e. it's prone to
breaking when changing code. That's not even mentioning that we have no
guarantees on kernel behavior in that particular case being identical on
all supported platforms.
I would honestly prefer an explicit compaction over implicit one.
>
> @@ -1828,6 +1828,13 @@ container_dma_map(struct vfio_config *vfio_cfg, uint64_t vaddr, uint64_t iova,
> ret = -1;
> goto out;
> }
> +
> + /* we don't need create new user mem map entry
> + * for the same memory segment.
> + */
> + if (errno == EBUSY || errno == EEXIST)
> + goto out;
> +
> /* create new user mem map entry */
> new_map = &user_mem_maps->maps[user_mem_maps->n_maps++];
> new_map->addr = vaddr;
>
> Thanks,
> Yunjian
>>
>>> if (left->addr + left->len != right->addr)
>>> return 0;
>>> if (left->iova + left->len != right->iova)
>>> @@ -174,6 +178,7 @@ merge_map(struct user_mem_map *left, struct
>> user_mem_map *right)
>>>
>>> left->len += right->len;
>>>
>>> +out:
>>> memset(right, 0, sizeof(*right));
>>>
>>> return 1;
>>>
>>
>>
>> --
>> Thanks,
>> Anatoly
--
Thanks,
Anatoly