From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 69D05A0526;
Fri, 24 Jul 2020 15:25:16 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id A5D2F1C0BE;
Fri, 24 Jul 2020 15:25:15 +0200 (CEST)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id 0B19F1C0BD;
Fri, 24 Jul 2020 15:25:13 +0200 (CEST)
IronPort-SDR: IVlMWgihPmSGImBX8GoxZvPyMnZmLznb2uQ0kLqeF0JBZuvypcjQ8HNoScfmlVRMaqw2FuzPcF
SQwg3q6827SQ==
X-IronPort-AV: E=McAfee;i="6000,8403,9691"; a="235583205"
X-IronPort-AV: E=Sophos;i="5.75,390,1589266800"; d="scan'208";a="235583205"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51])
by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
24 Jul 2020 06:25:12 -0700
IronPort-SDR: 9sQSbDmCA5wYp0Ec40xOl7tvog7koPZjDh/KhkrY20QsMFYnTdb09iZ2DzrG1qpHWs2TptOaxJ
Lw1mW9IhtZTQ==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.75,390,1589266800"; d="scan'208";a="288991646"
Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.35.102])
([10.252.35.102])
by orsmga006.jf.intel.com with ESMTP; 24 Jul 2020 06:25:10 -0700
To: wangyunjian <wangyunjian@huawei.com>, dev@dpdk.org,
david.marchand@redhat.com
Cc: jerry.lilijun@huawei.com, xudingke@huawei.com, stable@dpdk.org
References: <cdb0d6482a5c3a5d7d23625d230d9ef41d657320.1594903876.git.wangyunjian@huawei.com>
<1595515713-24640-1-git-send-email-wangyunjian@huawei.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <c35b31da-703e-d4d4-6283-0bb4e8ad57e2@intel.com>
Date: Fri, 24 Jul 2020 14:25:10 +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: <1595515713-24640-1-git-send-email-wangyunjian@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2] eal/linux: do not create user mem map
repeatedly when it exists
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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?
> 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