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 5F098A0352; Mon, 4 Nov 2019 16:19:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96E503576; Mon, 4 Nov 2019 16:19:23 +0100 (CET) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by dpdk.org (Postfix) with ESMTP id DF0ED237 for ; Mon, 4 Nov 2019 16:19:22 +0100 (CET) Received: by mail-wm1-f50.google.com with SMTP id 11so17134571wmk.0 for ; Mon, 04 Nov 2019 07:19:22 -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=+z4Abm55rmo5hIqy6CcAsScMAeCYtZBY/2KJi3Fx1jU=; b=dBaHo/CDNr4U7I9zWCnjkOAYNqXDUA+VwokJPK3AbqkERTOumEVEu/h9m8N0w5JLno ATYcgrPE98gL4ez3aY0kkRCGOawk5g4MUESb+PpPvoSsaFFAjiEeCDDo+01uEC0nJo8L Rrd180cUrpor6NRX9qNjYHcnROakjoJxt371T2s5/YGNwIip8mgYdzkMb+EGeAeAB45T PMXL+Ww5F5hO9shtGRBE56vgYc2BXKV1/pKY3FaFV+0Pok4dBBLIS0OHRENbBswMriM0 9JoWnAeJdWx71SAdRtjvf2mz5pu83f717I1m7LjM4YN93uOOgb01orWO+zakaYLP3Zxu V6Vg== 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=+z4Abm55rmo5hIqy6CcAsScMAeCYtZBY/2KJi3Fx1jU=; b=fxNDxUuniOguAYZizKZCg2s/43PkDNbk87IFxygKvaqSpvBRrrPlCj70ncSvwlWJ7m ouCybo0+jNaMun+gyuK/fXfJwdxbdTCKLJ9DeLuwpH8UG5HXm2NxmUSHf2E7xdfLZPFz hxLpNhLnLusjRnSXE5TaDwFfZsLu80Ep25WiGJM4zo+Vcha7Df27WTjzhQqbG4jIxUgp mPWzD7JuQKqRh+bLNK85m7c9U1smrNzqrH5zOKBI6qhItf9nXDumXfN1PmMMOkPo1dRX pAoK0jKvYQ4qG4Y9KeeLRYoMDMktoG4rLPpPEBV0WnME5NJKcz/zYpQHAnCiF6+myoTj +/Gw== X-Gm-Message-State: APjAAAVHuW7dnTtMGhp9p74WbCzcN0e5VCiMKTHSYEdPYil78AwbSULL 2xr5N6bb5sTI0BACjqibUuMDZg== X-Google-Smtp-Source: APXvYqwncJJCc3M/sjzy6gwuKHdpp6bspoDUab7y6zCzsX1i4rwUOS4O78Nee7nOVzk/+LeDIbSVXA== X-Received: by 2002:a05:600c:1002:: with SMTP id c2mr3760003wmc.79.1572880762530; Mon, 04 Nov 2019 07:19:22 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a6000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id f14sm18671743wrv.17.2019.11.04.07.19.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Nov 2019 07:19:21 -0800 (PST) Date: Mon, 4 Nov 2019 16:19:20 +0100 From: Olivier Matz To: Jerin Jacob Kollanukkaran Cc: "dev@dpdk.org" , "anatoly.burakov@intel.com" , "bruce.richardson@intel.com" Message-ID: <20191104151920.gq62kmhu3gfgpcy2@platinum> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Subject: Re: [dpdk-dev] Limiting packet buffers under 4GB 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 Jerin, On Mon, Nov 04, 2019 at 12:59:40PM +0000, Jerin Jacob Kollanukkaran wrote: > Hi Anatoly and All, > > Just wondering what would the side effect of lowering a _bit_ of static uint64_t baseaddr = 0x100000000 in > lib/librte_eal/common/eal_common_memory.c for 64bit systems. > > Use case: > If we _reserve_ VA address which less than 2^32 ONLY for packet buffers(mbuf), The use cases like > Pipeline, where need to transfer packets from one core to another cores can use ring element > size of 4B(32bit) which will reduce the a lot of read and write to enable better > performance. > > i.e Since upper 32bits will be zero, it is matter of typecasting of item to read and write from/to ring. > Essentially memcpy overhead for moving pointers over the ring will be half. > > Is baseaddr set to 2^32 to make sure that secondary process will have more _chance_ of getting > the baseaddr in order for DPDK to work? > > Thoughts on above? On general to reduce the mbuf pointer storage requirement for ring? There are use cases where the mbufs take more than 4GB of memory, typically for protocols that do a lot of buffering/queing. So if anything is done in that direction, it has to be an option.