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 7CC5243FA2 for ; Wed, 3 Jul 2024 20:54:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 10ABA427C1; Wed, 3 Jul 2024 20:54:59 +0200 (CEST) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mails.dpdk.org (Postfix) with ESMTP id 14D63410FC for ; Wed, 3 Jul 2024 20:54:57 +0200 (CEST) Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-710437d0affso3447060a12.3 for ; Wed, 03 Jul 2024 11:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1720032896; x=1720637696; 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=2PS5lsxu3MgTS5CtdT3bSse2i2vJls7T2yf8UXFXFxY=; b=Fp0BcEYFTVA+0FWKsSVmNKcj/qlKebS3L+l1F5ekgnVKU3ygjbHk68N7MuPQ/4tcNx N9h2sG7TQC4JF/G3J2cPmR4kZaETOLqIhPL2/8S7W81Jzlxk3x+SEEL7nBLkHyQCamCU kq0yT5RO6aKW6gPX7mlIjKwYU6uDpKewfntwU8GslKePlCNKQcTVI3IkK0/WxeDZ1PlZ Ws5DIVtM1mCf140erVCCzzdTH4PSQAhhlsHZukRKmZbvLKyIg0WPt6cuzajUUYr/9YZZ NlHp+JcmhtpWUK7HbOmkFbOAS2RvnEssRl3Hg3byqOpEnWuBax0yV2SzvpDQyBt05h7S Lu0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720032896; x=1720637696; 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=2PS5lsxu3MgTS5CtdT3bSse2i2vJls7T2yf8UXFXFxY=; b=WxAHF28VgjZM2arVB5eIfhNDAdx59GvqbcV1PdjdWXM8b/zH+43/efHF2sajPhKqQH /i7NQSMHFrjvJzVnMye1TgulK6/hdY7i200aq6YSEmfvzsiK379upcIvnXCNcXT/9sw4 tGhqcGbPgRSPhTP/ihzbziwmRLnUG8iPKfQLexSQMZrvHxy7LM7apE/Bba4cYM5nvuBC E4hgCkMdAMUYbSMcaqiyTkDiRK+27zxS6isO6oIqI/SjCIu31eFfBF4cBOrC/iBoCasd q7UT1w/KLRcHSHQ+9VAx/CIl2vUH0+v/0D/eTZzS90H3dsc57uf3hhDNZJMnD+CpSUCw EImw== X-Gm-Message-State: AOJu0YwWdnvAOdVN+2ZwVqJIpcrxdPcsAJnDh7cWa2+JpwLerpgMiY+5 HDaWPKckTCFBdxctng4dtYAYu5GtRKVutWxS/I8n77G2nRsNY8klMiNEqMZ6cIZKUj03J55U/pU VlEY= X-Google-Smtp-Source: AGHT+IF8B/bYtIQOHbUOafWMfjbGc7m+gvycr/rl1Xlp4n3VenDgBEKlnBL9KjlhmPesQKP4oPF1eg== X-Received: by 2002:a05:6a20:1586:b0:1be:d321:7e09 with SMTP id adf61e73a8af0-1bef611faa7mr13209481637.28.1720032895752; Wed, 03 Jul 2024 11:54:55 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c91d3bc99fsm11087703a91.41.2024.07.03.11.54.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jul 2024 11:54:55 -0700 (PDT) Date: Wed, 3 Jul 2024 11:54:53 -0700 From: Stephen Hemminger To: fwefew 4t4tg <7532yahoo@gmail.com> Cc: users@dpdk.org Subject: Re: Regarding multi-segmented mbufs Message-ID: <20240703115453.1bec4733@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 3 Jul 2024 14:15:58 -0400 fwefew 4t4tg <7532yahoo@gmail.com> wrote: > The DPDK documentation > https://doc.dpdk.org/guides/prog_guide/mbuf_lib.html provides helpful > information but comes up a tad short re: multi-segmented mbufs. See > Fig. 14.3 An mbuf with Three Segments. > > See https://doc.dpdk.org/api/structrte__mbuf.html for mbuf struct > field description. > > Consider a 16Kb message which can fit into 16 packets (to keep the > numbers nice here). Now one way to play to game TX side is: > > 1. Allocate 16 mbufs from a mempool > 2. Chain mbuf 0 to mbuf 1 by updating mbuf0's m->ptr.next pointer as per diagram > 3. Chain mbuf 1 to mbuf 2 by updating mbuf1's m->ptr.next pointer as per diagram > 4. etc.; > 5. Update ONLY mbuf 0's nb_seg to 16 so DPDK has some idea there's 16 > related packets > 6. Write headers, payloads into each of the 16 mbuf's data room > 7. Transmit > > However, the doc misses at least two points: > > 1. The diagram mentions 'm->pkt.next'. However mbuf does not have a > pkt field. It does have a 'next' field described as "Next segment of > scattered packet. This field is valid when physical address field is > undefined." Should the diagram read 'm->next The next field used to be in pkt.next, got changed many releases ago; this is just a documentation bug. > 2. Once I get the 16 mbufs linked together, can I send them one at a > time, or will DPDK make me burst TX all 16 in one shot? Note, the TX > ring may not have capacity for all 16 the first time code tries to > send them. A mbuf represents a single packet, a multi-segment mbuf still represents a single packet on the network. If the HW TX ring does not have space for that many segments, then tx_burst should return that the packet can not be sent. For a burst with only a single packet that would be zero. Also tx_burst preserves packet order so if a packet could not fit, then that ends the burst. > > I'm guessing that, more or less, the next pointers are handy for app > devs because it records which mbufs are related to a larger overall > message while, on the other hand, DPDK doesn't care. As far as DPDK is > concerned, I can burst send all 16, transmit 1 at a time, or heck, > even send them in reverse order one at a time. But then I don't know > why DPDK cares about nb_seg. No, next pointers are not for apps handling bursts of packets. If the application needs to keep track of a chain of packets then it needs to define its own pointer (using dynamic field) or have meta data wrapper. It is also worth noting that linked lists are slower than arrays. > > Or perhaps the next pointers, nb_seg cary through on TX, and are > intended to help code RX side. For example, once the RX code sees a > packet with nb_seg = 16, it'll know there are 15 more related packets.