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 CEDCAA04B5; Thu, 29 Oct 2020 13:41:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B88A0CB03; Thu, 29 Oct 2020 13:41:33 +0100 (CET) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by dpdk.org (Postfix) with ESMTP id 958B5CAFC for ; Thu, 29 Oct 2020 13:41:30 +0100 (CET) Received: from [93.206.1.228] (helo=nb-martin.allegro) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1kY7C6-0008E8-UW; Thu, 29 Oct 2020 13:38:18 +0100 To: Ciara Loftus , Qi Zhang Cc: dev@dpdk.org References: <20201029112542.96131-1-martin.weiser@allegro-packets.com> From: Martin Weiser Message-ID: Date: Thu, 29 Oct 2020 13:41:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201029112542.96131-1-martin.weiser@allegro-packets.com> Content-Language: en-US X-Df-Sender: bWFydGluLndlaXNlckBhbGxlZ3JvLXBhY2tldHMuY29t Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] net/af_xdp: fix integer overflow in umem size calculation 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" Hi, the reason why I stumbled across this issue is because I was getting inconsistent errors during interface rx queue setup. We generally use quite large mempools and it looks like the umem setup fails for larger sizes. But because of the integer overflow the umem_size sometimes became small enough to let the umem setup work, so it was not immediately obvious what was going wrong. It seems that the umem setup (specifically the setsockopt call with XDP_UMEM_REG in libbpf's xsk_umem__create_v0_0_4()) fails with any length greater than 2GB and returns ENOMEM. This at least happens on our systems with kernel 5.8. Are you aware of any such kernel-side limitation? This basically makes af_xdp unusable with mempools larger than 2GB. Best regards, Martin Am 29.10.20 um 12:25 schrieb Martin Weiser: > The multiplication of two u32 integers may cause an overflow with large > mempool sizes. > > Fixes: 74b46340e2d4 ("net/af_xdp: support shared UMEM") > Cc: ciara.loftus@intel.com > > Signed-off-by: Martin Weiser > --- > drivers/net/af_xdp/rte_eth_af_xdp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c > index df2767b81..4076ff797 100644 > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c > @@ -968,7 +968,8 @@ xsk_umem_info *xdp_umem_configure(struct pmd_internals *internals, > > umem->mb_pool = mb_pool; > base_addr = (void *)get_base_addr(mb_pool, &align); > - umem_size = mb_pool->populated_size * usr_config.frame_size + > + umem_size = (uint64_t)mb_pool->populated_size * > + (uint64_t)usr_config.frame_size + > align; > > ret = xsk_umem__create(&umem->umem, base_addr, umem_size,