From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8231D426B6 for ; Wed, 4 Oct 2023 09:19:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 493A14029A; Wed, 4 Oct 2023 09:19:44 +0200 (CEST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by mails.dpdk.org (Postfix) with ESMTP id 7608E40289 for ; Wed, 4 Oct 2023 09:19:42 +0200 (CEST) Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-504427aae4fso732676e87.1 for ; Wed, 04 Oct 2023 00:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696403982; x=1697008782; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=WXLHmBFR66codM4jMYYPKPXbckrGKl8pjj222ZfHFRg=; b=BwYUw8ZqhymjyxNqE8VfhK1JJJN9j1kBogSHpSPRowlkP/+Ck2GgIu/l7Ua/AK+RLY 0oKRxVGuki1R+zy3cAXA0HmMlt61tbfADeGAZATkG8TgQosTdhuwNBcocj02V0LcBLfh 1uVG7Y1ibCD+73a2Ewbr8wLgIIboE+KCyX5HopARpiuW/HzBGM8yc/CAYxd5Wirutw4p lLQfaGpn6G4yaYRiM42NKEtGcnLdLAcnfcaiZyx5Veprt1Qp5zW61uGmu5J9D0rwfpBR Imzl/Js/3GUorA0yjIJKNDPD6hoWLxTiSfaoICEFzjZhC3FqtPMS9iRCl0BR5K0+oh1R j02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696403982; x=1697008782; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WXLHmBFR66codM4jMYYPKPXbckrGKl8pjj222ZfHFRg=; b=brOLjNGIEIsnq0TyK0wNK71/Gr0+i+/+Tz8O/Ji4ECvL2r3WPxSExfCDpGzE4BKU0s 243M6mWVx54wOBgcVkiYV1z1V8QjS+uNSZ1xETkSmcqQ6ysM3+18ngJU9WQIaKlFBFJx DEiQzQUsNw9hkYSBJpbMruEhKn5PSFZStdpjPsm23b5vv2VDuKQ+5ivgK99NFdR+j0qm Ftrgufm4cEIV/V/9wNOdqa7Eus2BPqAzZCCQ+ZcYtYEHj3PfZG3UkBRv9hISaKJzhpKq cc9VzzXJhPHAlzqDmN5ABa/b6czsyRPduCeP/kQhAYAPTKWLrGeU0AuV1BowT8UnjVfM pVqg== X-Gm-Message-State: AOJu0Yx/1OLjp3mtbWIZzKMTvB8/k0QyH7jx4eCCPCLlAMht6U/cS0wM /HOqfRiZCtDGIvO88/d0q9g= X-Google-Smtp-Source: AGHT+IGzIXIVRcT+htwsk2MErrBpaYrIV4c+fraBTx3EaKmu3vZsmdnQGEH+ht01r0Zat6UfhB8V3g== X-Received: by 2002:a19:5019:0:b0:505:7163:c132 with SMTP id e25-20020a195019000000b005057163c132mr3331993lfb.7.1696403981653; Wed, 04 Oct 2023 00:19:41 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id o4-20020ac24344000000b0050481c400e9sm476226lfl.287.2023.10.04.00.19.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 00:19:40 -0700 (PDT) Date: Wed, 4 Oct 2023 10:19:39 +0300 From: Dmitry Kozlyuk To: "Nicolson Ken (=?UTF-8?B?44OL44Kz44Or44K944OzIOOCseODsw==?=)" Cc: "users@dpdk.org" Subject: Re: mbuf data is 1400 bytes but the most common (?) use, Ethernet II frames, allow for 1518 bytes Message-ID: <20231004101939.3d65dfca@sovereign> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Hi Ken, 2023-10-04 06:52 (UTC+0000), Nicolson Ken (=E3=83=8B=E3=82=B3=E3=83=AB=E3= =82=BD=E3=83=B3 =E3=82=B1=E3=83=B3):=20 > Looking at sending Ethernet packets over a DPDK connection, I see that an > Ethernet Type II frame has 1518 max, but mbuf's data block is 1400 bytes. rte_mbuf has no fixed-length "data block", so there is no limitation of 140= 0. Buffer size is usually configured when creating a packet mempool. Typically (rte_mbuf_core.h): /** * Some NICs need at least 2KB buffer to RX standard Ethernet frame without * splitting it into multiple segments. * So, for mbufs that planned to be involved into RX/TX, the recommended * minimal buffer length is 2KB + RTE_PKTMBUF_HEADROOM. */ #define RTE_MBUF_DEFAULT_DATAROOM 2048 #define RTE_MBUF_DEFAULT_BUF_SIZE \ (RTE_MBUF_DEFAULT_DATAROOM + RTE_PKTMBUF_HEADROOM) > Is this what the headroom and tailroom are for? It is for prepending headers/trailers without copying the packet into a new buffer, that is, it is used to change the packet efficiently. Sometimes some headers still need to be moved, but not the entire frame. Documentation shows how headroom, dataroom, tailroom, and buffer are relate= d: https://doc.dpdk.org/guides/prog_guide/mbuf_lib.html > I see example code that uses the headroom for the MAC Header, but what is > the preferred way of copying a 1518 Ethernet packet into an mbuf? Should I > use rte_pktmbuf_append() to reserve the extra bytes, or is there a better > way? Is the question still relevant given the explanations above?