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 7B515A052A; Fri, 10 Jul 2020 14:58:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E9A7E1DD51; Fri, 10 Jul 2020 14:58:23 +0200 (CEST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by dpdk.org (Postfix) with ESMTP id E0CFC1DCC3 for ; Fri, 10 Jul 2020 14:58:22 +0200 (CEST) Received: by mail-wr1-f41.google.com with SMTP id f18so5877692wrs.0 for ; Fri, 10 Jul 2020 05:58:22 -0700 (PDT) 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:content-transfer-encoding:in-reply-to :user-agent; bh=aKDMwgJtqWQcpXwuTGoj7jfiOl0Yz3+q9s4FhTw+xT8=; b=KVQ2kkadH+PHZL25pC+euF/03N/ybitOoTZSXPpRfy6qji/stBKsJlC8fL34vg/Ex1 zp/2vowyIdgt5xcXVttuEQ4/k4PQdhkkxnSoc9+fjOriUvjri6SWQMOiP+vmUl4ESYmh eoyfAuqjsfCDJ5eKfJy4oFj6yrgnmr7gjI/zccELX+iq/tGPcxDbVVp3ROsMU5qXtwBh O096KjnV89JjIABQXkynMW55ZdI7fFlP3H8kQWsRa/zy6+YGF0j2JPnl12b7YUkIygyc 6QAdMA+KBqSXpIA9wSNC+iDDN2kLcuZlRftP2wv8x/Sx75GgfDv6RQ4BjZPtepTlR/S4 rpXQ== 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:content-transfer-encoding :in-reply-to:user-agent; bh=aKDMwgJtqWQcpXwuTGoj7jfiOl0Yz3+q9s4FhTw+xT8=; b=WwufrZdRlZcod2e/+zskgvoiHzJGXuvvgXHYdJ3Z51Ee4mreeMyoKEYlzxZ3F4NqOi 1jUjAfs7KYWDgbLcJ1LUsH7BP85FfEH01WaWcnFou0OaYf8KAH9SZbQUr6iJDUJWrRZ8 fdUrRYwQu8++fL9/rNUlo6zKY34cIc/9KIOwqymXMwBJthxbuFwRE8XivCNEX9FTioJY ynhv7rUSHz+bU4Plio0dUUlkm9L3ikA5XeOuBND6NxoXvURIThimVzewE+rRcuDCJs1X IMhEBYxs1hdQmgEjJNpUqT+qkQDFzN3L+iONzyGoj0dxaziV+8SlghTRdO27MwYnUM8+ qNig== X-Gm-Message-State: AOAM533BxsNnCvGDkbwQKCik5XCCzR1hq5faoXg8FWq0tsDrGPaaqd3R mNTWcc733YyAFG9sopfQDrtl+A== X-Google-Smtp-Source: ABdhPJx58q5sJfpccv8BMHa7+KsUDlvDOBTjJsZWxR/n0qi8buSsR9GJokTT6h/Yo8O8Y8IBjVRCkw== X-Received: by 2002:a5d:4a4f:: with SMTP id v15mr64726673wrs.87.1594385902669; Fri, 10 Jul 2020 05:58:22 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id 78sm2481268wma.31.2020.07.10.05.58.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2020 05:58:22 -0700 (PDT) Date: Fri, 10 Jul 2020 14:58:21 +0200 From: Olivier Matz To: Bruce Richardson Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org Message-ID: <20200710125821.GA5869@platinum> References: <98CBD80474FA8B44BF855DF32C47DC35C61113@smartserver.smartshare.dk> <20200710102609.GA684@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200710102609.GA684@bricha3-MOBL.ger.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] Weird 2 KB MBUF data room requirement 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, On Fri, Jul 10, 2020 at 11:26:09AM +0100, Bruce Richardson wrote: > On Fri, Jul 10, 2020 at 10:21:40AM +0200, Morten Brørup wrote: > > Dear Ethernet PMD developers, > > > > According to rte_mbuf_core.h, RTE_MBUF_DEFAULT_DATAROOM is 2048 bytes because some NICs need at least 2 KB buffer to receive standard Ethernet frames without splitting them into multiple segments. > > > > This is a serious waste of memory, considering that standard Ethernet frames are max 1518 bytes. > > > > How wide spread is this limitation... is it common or a rare exception? > > > > Where is it documented which NICs suffer from this limitation? > > > > Do any Intel NICs suffer from this limitation? > > > > > > NB: We are targeting an MBUF total size (incl. memzone element overhead) of 2^N, and this limitation would increase our MBUF total size to 4 KB. > > > > > > Med venlig hilsen / kind regards > > - Morten Brørup > > > > AFAIK: the NICs supported by the ixgbe driver only allow the size to be > specified in KB granularity. > > However, it may be safe to have a driver modification whereby anything over > 1600 bytes is considered as 2KB if jumbo frame support is disabled. I don't > think anyone has actually looked into doing so though, or if there are > other hidden gotchas about attempting to do so. If I remember well, the niantic NICs (and probably some others) can have their rx size configured with 512, 1024, 2048, ... This is the size that should be available from the given data pointer, i.e. it does not include the headroom. I suppose that if we configure the NIC with 2K but give less than 2K, the NIC may write after the buffer when receiving a large packet. Olivier