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 29FD0A04AB; Wed, 6 Nov 2019 13:40:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D7D591C192; Wed, 6 Nov 2019 13:40:11 +0100 (CET) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by dpdk.org (Postfix) with ESMTP id B2E281C18F for ; Wed, 6 Nov 2019 13:40:10 +0100 (CET) Received: by mail-io1-f48.google.com with SMTP id x21so11157852iol.2 for ; Wed, 06 Nov 2019 04:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zpugoEw+W8Wvuxv4zVBLRapevJ3BKY9wzdG0KiiT6Go=; b=NnWTOIPd7nCcbC0G5by4Eq4TvXW0K8kC4nf9EqinOFOhzEq9GVVVFAMzuvAM6CArQY 67iNaZPiHXYkBCpD/eVBztArxSpzB1PAtOyx+cXeCkh6ckIUIFSdcnXqb8FCjFOAoaBL aegAySGMNs/r8Lc5wMUuBnRbP6ZYqPLmhHgn4xTCZU1S8rl7G7xRZJSOF4qdY2rMP+m3 v8iY1Cm3wTGaMvqlLPPy0bvOrJvbRDh/P+I6haBSUbAKN+YDs9K8io2kFL21IDqhuCIQ Kg1od6JGsRpkV1Q2QUWVvExGX9/C5bn2LWagR+jsJMsfyq2vQQFpay5jxcmE2d++2B5p EsnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zpugoEw+W8Wvuxv4zVBLRapevJ3BKY9wzdG0KiiT6Go=; b=dlHsmTZN3U5EMudA0ReFOmSEPJ0tBTebJUWNyva3E/3+m2Z1L4bdaZZZWsJxUaMEOg 8vUJ+h1HxOiRfzsgpN9b+6XtJFmb/SwuhI4XF8owaGIepTOE11isJIP1A55fvldOhKrz +eyaETIfmkU7t0GY1pytU98lS/jGspM8B/ShQSYKDBYeSJokPK//wP29X0q36V2T2q0j ONHwAcTarQh9sg0MSkMaU3hn5M++fgmuvhxkQtaFqAb9OPh4lvyxAS9JqUS40IBz2R2U fqr+tQ5wDs4I+YGuabSBNQoq+p5TSRzhcYxt0RyXHtu72d3ZOO0l7ckd2wFrrFKVKyQY 57cQ== X-Gm-Message-State: APjAAAU9+S7+bF8B+ysXJqK/MkXgHWVJhF3kSbBPfv8D2tcS6MYlQFHX 8dUmn1ME6dZhxUz2HcyoceNLxpz3KwBEk3xkdzI= X-Google-Smtp-Source: APXvYqzFSInjc0TXt1z3cnlrssoj7HuznijFt0Vi2WTjC5auZ7Hyl7BihG2q8tJf46so3f8SctbB/zC/NVe0HaVXwcQ= X-Received: by 2002:a6b:c701:: with SMTP id x1mr32909083iof.162.1573044009873; Wed, 06 Nov 2019 04:40:09 -0800 (PST) MIME-Version: 1.0 References: <4fe56f91-1817-3213-5e1a-19f85f5d83d8@intel.com> In-Reply-To: <4fe56f91-1817-3213-5e1a-19f85f5d83d8@intel.com> From: Jerin Jacob Date: Wed, 6 Nov 2019 18:09:58 +0530 Message-ID: To: Anatoly Burakov Cc: Jerin Jacob , dpdk-dev , "bruce.richardson@intel.com" , Olivier Matz Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" On Wed, 6 Nov, 2019, 5:46 pm Burakov, Anatoly, wrote: > On 04-Nov-19 12:59 PM, 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? > > > > You can already try that with --base-virtaddr option if you have such > specific addressing requirements. That said, the address is pretty much > arbitrary, so i'm not against lowering it in principle, it just feels > like a workaround for something that's very specific to the workloads > you are targetting. > Thanks for the feedback. I will find the performance delta first to decide any such option makes sense. > -- > Thanks, > Anatoly >