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 F3A37A046B for ; Thu, 9 Jan 2020 15:23:53 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DEF651DE17; Thu, 9 Jan 2020 15:23:53 +0100 (CET) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id D37541DE1C for ; Thu, 9 Jan 2020 15:23:52 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id c9so7576100wrw.8 for ; Thu, 09 Jan 2020 06:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0VPGtj8/EOApK+UIsc+UPs+x0gBr7Zbnjy2D+Gn1PUo=; b=XydYj/jm1ISv/y/ASGyto2u+ZlmYaq/zj3TOdz62fpxDR1Fk1ddNTb2C+BTxcNSppJ e52l+rdH4hw0aUpPfiV7HASSlo2IF8KTXdyPFyiOiGcp5HB1U9voPFnU2FbfzEDL+iD6 nH7sbIVHWM+iZu/bb0mc3BrBAq9jco5y+qOyjQA/IT0fW53Z0/OWlimyZCHMW4RjRwF5 f0slhwIzPdF2AQUn9Z/h1AkNS1mABVbL8YuItprKIXTQkl7FvA4i+vFibRK+WDBK5FK+ A+ZeBCTiE8Ehz7RUoH0ymu2T+fbnNnLrEFOSvS4m0lh1sF06DbsL1du0E0kLP4igObIe DIzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0VPGtj8/EOApK+UIsc+UPs+x0gBr7Zbnjy2D+Gn1PUo=; b=iRdCNbqCf875dEF84jj0YUFjNDYTIWdMBEvSk0+KxmSP4dYPtpcDu4RXk7yynnamyW oXHwBmRislFUXTZQPCzAGeoQS8bL8ZUg9P7B95OaHoCwKK7bKSi1dt06xWiKpEo0Osu/ x0g/5vTN61yBmhkz7LOVMKCFEiiFwKT6sWAhWp84/N9uDMLW8UZOf8on410TWwqQSckt Ho8u5gG2bdH4ywwYd2rIXjRNMTADIf/IiSeRS9Vv43W73cyHqYBcSasqUzNUF5blZyr+ dvZQlgqXpu2AeNO/4HTS5Fx0POL1cX6zaU5r8qDu9/kKPGsXG5mlkMwpA20m5rsGmEJ5 cWcA== X-Gm-Message-State: APjAAAUxuCS+kSJ27looxcsn0Mq0XC6vnX+p1BkGxmSYf/1vIqzf7CJP WMgztPt+xZLvYFCtx0GTJdMmPQ== X-Google-Smtp-Source: APXvYqwBhqXuoAVUM5HNgWZEnReUrtWEQ6m+bWiXggUdeSKglDiAe1RBa1Dgh3lph6WOIwfzsy1jCw== X-Received: by 2002:a5d:4b8f:: with SMTP id b15mr11947885wrt.100.1578579832564; Thu, 09 Jan 2020 06:23:52 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id h66sm3128615wme.41.2020.01.09.06.23.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jan 2020 06:23:52 -0800 (PST) Date: Thu, 9 Jan 2020 15:23:51 +0100 From: Olivier Matz To: "Burakov, Anatoly" Cc: dev@dpdk.org, Andrew Rybchenko , stable@dpdk.org Message-ID: <20200109142351.GJ22738@platinum> References: <20200109132720.15664-1-olivier.matz@6wind.com> <8b59b3c9-ac1a-f448-e38d-063a6cb8ba7a@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b59b3c9-ac1a-f448-e38d-063a6cb8ba7a@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [PATCH] mempool: fix mempool virt populate with small chunks X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, Jan 09, 2020 at 01:52:41PM +0000, Burakov, Anatoly wrote: > On 09-Jan-20 1:27 PM, Olivier Matz wrote: > > To populate a mempool with a virtual area, the mempool code calls > > rte_mempool_populate_iova() for each iova-contiguous area. It happens > > (rarely) that this area is too small to store one object. In this case, > > rte_mempool_populate_iova() returns an error, which is forwarded by > > rte_mempool_populate_virt(). > > > > This case should not throw an error in > > rte_mempool_populate_virt(). Instead, the area that is too small should > > just be ignored. > > > > To fix this issue, change the return value of > > rte_mempool_populate_iova() to -ENOBUFS when no object can be populated, > > so it can be ignored by the caller. As this would be an API change, add > > a compat wrapper to keep the current API unchanged. The wrapper will be > > removed for 20.11. > > > > Fixes: 354788b60cfd ("mempool: allow populating with unaligned virtual area") > > Cc: stable@dpdk.org > > > > Signed-off-by: Olivier Matz > > --- > > > > The approach fixes the issue on my end, so > > Tested-by: Anatoly Burakov > > > Is there a simple way to ensure that we won't forget to remove the > > wrapper for 20.11? Anatoly suggested me to use versioned symbols, but > > it's not clear to me how. > > > > Yes, i'd like to do better than "ah shur we won't forget pinky swear". > > Can't we do this with ABI versioning? E.g. > > rte_populate_iova_v20() ... returns EINVAL > > rte_populate_iova_v21() ... returns ENOBUFS > > I'm pretty sure, even if it doesn't break, it will still be more likely to > not be forgotten because there's almost a guarantee that someone will grep > for symbol versioning macros across the codebase around 20.11 timeframe. Without using symbol versionning, would this be ok too? int rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr, rte_iova_t iova, size_t len, rte_mempool_memchunk_free_cb_t *free_cb, void *opaque) { int ret; ret = __rte_mempool_populate_iova(mp, vaddr, iova, len, free_cb, opaque); #if RTE_VERSION < RTE_VERSION_NUM(20, 11, 0, 0) if (ret == -ENOBUFS) ret = -EINVAL; #endif return ret; } > -- > Thanks, > Anatoly