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 222B0A04DE; Fri, 30 Oct 2020 16:01:45 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 935EAC99C; Fri, 30 Oct 2020 16:01:43 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 7453AC96C for ; Fri, 30 Oct 2020 16:01:42 +0100 (CET) IronPort-SDR: SyQ0PTk6/2EFmuMoaXaaKY2EotB4kUNNarHgop4D6EmrseRfRUsg+ebDzCY1JHtINdE2dLkqpr Ds0diXfLW2kg== X-IronPort-AV: E=McAfee;i="6000,8403,9790"; a="165120236" X-IronPort-AV: E=Sophos;i="5.77,433,1596524400"; d="scan'208";a="165120236" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 08:01:40 -0700 IronPort-SDR: GoM1X+iCLDfYZjzOg7LylviwBlQYW1L8E/sZTV/urxelDYWEcQX5++234Je1c/afNsN8kmKeAd GBQOQLJElODw== X-IronPort-AV: E=Sophos;i="5.77,433,1596524400"; d="scan'208";a="537092852" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.23.197]) ([10.252.23.197]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2020 08:01:38 -0700 To: Martin Weiser , Ciara Loftus , Qi Zhang Cc: dev@dpdk.org References: <20201029112542.96131-1-martin.weiser@allegro-packets.com> From: Ferruh Yigit Message-ID: <5dcf837b-3a8c-866e-c22e-78035de9d3dc@intel.com> Date: Fri, 30 Oct 2020 15:01:34 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 10/29/2020 12:41 PM, Martin Weiser wrote: > 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 Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/main, thanks.