DPDK usage discussions
 help / color / mirror / Atom feed
From: "Nicolson Ken (ニコルソン ケン)" <ken.nicolson@jp.panasonic.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: RE: mbuf data is 1400 bytes but the most common (?) use, Ethernet II frames, allow for 1518 bytes
Date: Thu, 5 Oct 2023 02:28:43 +0000	[thread overview]
Message-ID: <TYAPR01MB63788F1D85C1B24DD16C8DA7BCCAA@TYAPR01MB6378.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20231004101939.3d65dfca@sovereign>

Hi Dmitry,

Thanks for that answer; I'd pulled this diagram from a random page without fully checking the source:

https://promisechen.github.io/_images/mbuf_layout1.png
https://promisechen.github.io/dpdk/zp/mbuf.html

I see now that the 1400 bytes was just an example value for demonstration purposes; the official example source code I've looked so far just used the default mempool on rx_queue_setup.

I'm teaching myself DPDK, so I'm occasionally fumbling about in the dark.

Cheers,
Ken


-----Original Message-----
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> 
Sent: Wednesday, October 4, 2023 4:20 PM
To: Nicolson Ken (ニコルソン ケン) <ken.nicolson@jp.panasonic.com>
Cc: users@dpdk.org
Subject: Re: mbuf data is 1400 bytes but the most common (?) use, Ethernet II frames, allow for 1518 bytes

Hi Ken,

2023-10-04 06:52 (UTC+0000), Nicolson Ken (ニコルソン ケン): 
> 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 1400.
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 related:

	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?

      reply	other threads:[~2023-10-05  2:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04  6:52 Nicolson Ken (ニコルソン ケン)
2023-10-04  7:19 ` Dmitry Kozlyuk
2023-10-05  2:28   ` Nicolson Ken (ニコルソン ケン) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=TYAPR01MB63788F1D85C1B24DD16C8DA7BCCAA@TYAPR01MB6378.jpnprd01.prod.outlook.com \
    --to=ken.nicolson@jp.panasonic.com \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).