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 6848C45564 for ; Wed, 3 Jul 2024 20:16:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C6A942D80; Wed, 3 Jul 2024 20:16:37 +0200 (CEST) Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by mails.dpdk.org (Postfix) with ESMTP id 8AD564278B for ; Wed, 3 Jul 2024 20:16:35 +0200 (CEST) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-650cef35de3so16542377b3.1 for ; Wed, 03 Jul 2024 11:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720030595; x=1720635395; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lPRIgppSc9Rrk6/l+F8E4Sp1tusq+zBfPw/xnBe8P50=; b=Mhmb3TOXKZEojqwCtCyhBbj5r73Mod8cL1xBvDC1ka58OL3lVFVhjxMbzF4QwDTC9P g6nGdKcLnLyBao2RsVyVVBmiG5Hiuha9RQ7txxXaLr1Q+BhDNE+zC/3MveU7xXVskXuI DzA9s23Jj+yVnABRDpeCGEOCcJTpQ0h5RZ4OOVhmMYMPO/walX+ij/d/jR2VK/w03jOL RMtLD7ZCp4RIQaoYU25hcEaIk87RlGpWKcfjIq0NuJu+WZ5f6efYzDYNBBbbsd9QuwDE GUMEW0H0NeiYPvpJivwEqLrDDLyTLCC3zHir+TW6ZsA1Md0gM8WArpa7TLJGlW1KTg+Y ANYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720030595; x=1720635395; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lPRIgppSc9Rrk6/l+F8E4Sp1tusq+zBfPw/xnBe8P50=; b=I/Yu0qZg3CCptrL2n1sH4Q9uNew5IxVwYMcnoi5W1pa/GzWnso34MZry4qAdquAmZm H3kxzpRkKbpZTrIlLpCm7Monv8lpyHBx0FL1ZqxX6zLBxlPsKCH5qXKYx1aNkX/AMxL7 KEpTLlEYRM2HWHkYmBv4FT0PKIZ07UF7TXD7K1OCv+O3ob0kKF53+6YzIAsx5PNjexeI leqkrRmjudu0BNaUXw+lPMfHFlHGZWIUqq+17iapArO6+8nZOtLNh/bbtO5kxxiDRZjS v3lIxSLKHjDiyxFfLmmi8IwHFql/eCHs/7RTZJ7xESJIbULfeYj7uO+G0+AAQFdMCeRg rOpw== X-Gm-Message-State: AOJu0Ywm50zbctUXPndfBebp3aOWDMPXXDsferYSzoF0Q9uawCzvW+3H 8Alnm+Wzn5I0iHyOJ/Ep8m7Z8mStemp6o0mle0aoRXF2WZZjLM223Zxz9X3Bs06+79M5MVDFqdZ ve374HggnpzAjG7rYFtC2LmU51+xNj1fb X-Google-Smtp-Source: AGHT+IEfVW6cVyfUf12iXbMO7rw3nHp5GdRvlZux7eRPkp1oZgUCKnedI/1dV1F87fxTF1vCX8md5BT3T5vNamNCC+4= X-Received: by 2002:a81:fe04:0:b0:64a:5df5:3afb with SMTP id 00721157ae682-64c73418c03mr122465737b3.39.1720030594551; Wed, 03 Jul 2024 11:16:34 -0700 (PDT) MIME-Version: 1.0 From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Wed, 3 Jul 2024 14:15:58 -0400 Message-ID: Subject: Regarding multi-segmented mbufs To: users@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 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 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. 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. 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.