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 4F25CA046B; Thu, 9 Jan 2020 15:23:54 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 22FCA1DE21; Thu, 9 Jan 2020 15:23:54 +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 D35DF1DE17 for ; Thu, 9 Jan 2020 15:23:52 +0100 (CET) Received: by mail-wr1-f65.google.com with SMTP id q10so7551905wrm.11 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=uFxMxffAgYT14pno3+r/xR9N3YvVlp9dk1EDWUG1tsTlWIUs8RoD4VXoIDfhDWXTgB yZu/Pf/i4a6jsDmmEmtm2isxZRoRarbp/Xic7itQyUjKciUfzLu6vj+/+Bi0LcG+kfsG FsQpp415O87Wq4SxkI/ilYJJw0oQAk5p5x5Ot4I+HfV8Z08KrkzN9m1fhEfItBQ6hZJw 1/JTydXWZaKug6ywSVilfjnxc+qtD69hCL1ab3PWlsvWj/rfFuUih0LrnXUuk7M14wPC iOvIXiB6YUmJZl5LUyZdSn1jkVmp3TVaDR+3OCHcykzz5+yuwAcRb4Q0dp/Jp/wq7Fpb n0dA== X-Gm-Message-State: APjAAAWAcRXc2joeMDnvI/QvSKZHN0xCUCsluTYKFEolvhTGX/LUA63I EtETPsg5jAqoYMcbTXoSL+U5Ew== 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-dev] [PATCH] mempool: fix mempool virt populate with small chunks 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 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