From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F08F0A053B; Fri, 17 Jul 2020 16:23:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D16A41BFBC; Fri, 17 Jul 2020 16:23:41 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id EDDC51BFB3; Fri, 17 Jul 2020 16:23:39 +0200 (CEST) IronPort-SDR: uE0tyuw7qmxje5s5escXINJTwMkmB1dCSxwDMR/LwYJUR15qOZIKtQwILBtAvL+CHVXLfwyf7O xzNGrf8tmuzg== X-IronPort-AV: E=McAfee;i="6000,8403,9684"; a="137707942" X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="137707942" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2020 07:23:38 -0700 IronPort-SDR: s4BQeRN/S15/3q9YdtNUlk+hfpNkslnt96/cWI8T4I50eYP9Xycm4Qagtl41AvBMiU8Y9XSbOL 4gcnhwNEytew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="286826225" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.226.225]) ([10.213.226.225]) by orsmga006.jf.intel.com with ESMTP; 17 Jul 2020 07:23:37 -0700 From: "Burakov, Anatoly" To: wangyunjian , dev@dpdk.org, david.marchand@redhat.com Cc: jerry.lilijun@huawei.com, xudingke@huawei.com, stable@dpdk.org References: <70169443-f475-a632-c1f8-6e993bea726c@intel.com> Message-ID: Date: Fri, 17 Jul 2020 15:23:36 +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: <70169443-f475-a632-c1f8-6e993bea726c@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 1/1] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 17-Jul-20 3:19 PM, Burakov, Anatoly wrote: > On 16-Jul-20 2:38 PM, wangyunjian wrote: >> From: Yunjian Wang >> >> 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. >> >> Fixes: 0cbce3a167f1 ("vfio: skip DMA map failure if already mapped") >> Cc: stable@dpdk.org >> >> Signed-off-by: Yunjian Wang >> --- >>   lib/librte_eal/linux/eal_vfio.c | 7 +++++++ >>   1 file changed, 7 insertions(+) >> >> diff --git a/lib/librte_eal/linux/eal_vfio.c >> b/lib/librte_eal/linux/eal_vfio.c >> index abb12a354..d8a8c39ab 100644 >> --- a/lib/librte_eal/linux/eal_vfio.c >> +++ b/lib/librte_eal/linux/eal_vfio.c >> @@ -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; >> + > > I'm not sure i understand this patch. If we get errno, the call has > failed, which means we're doing "goto out" from a few lines above. Am i > missing something here? > >>       /* create new user mem map entry */ >>       new_map = &user_mem_maps->maps[user_mem_maps->n_maps++]; >>       new_map->addr = vaddr; >> > > Oh, i see, the actual functions will set errno and return 0. I don't think it's an actual issue as compacting will presumably remove the extra user mem map anyway. What exactly is being fixed here? Does compacting user mem maps not remove the extra entry? -- Thanks, Anatoly