From: daniel chapiesky <dchapiesky2@gmail.com>
To: dev@dpdk.org
Subject: [dpdk-dev] rte_mbuf: documentation, meta-data, and inconsistencies
Date: Thu, 28 Aug 2014 20:00:59 -0400 [thread overview]
Message-ID: <CAJnwcoPgydbE9BOZCkMejcd4BpLpw7E3gtYnrdCWs0744qJTkg@mail.gmail.com> (raw)
rte_muf: Inconsistency in the programmer's guide or the code.....?
---------------------------------------------------------
>From the DPDK 1.7.0 programmer's guide we read:
"For a newly allocated mbuf, the area at which the data begins in the
message buffer
is RTE_PKTMBUF_HEADROOM bytes after the beginning of the buffer, which
is cache
aligned."
In the file ./lib/librte_mbuf/rte_mbuf.c and function rte_pktmbuf_init() we
find:
m->pkt.data = (char*) m->buf_addr + RTE_MIN(RTE_PKTMBUF_HEADROOM,
m->buf_len);
Where RTE_PKTMBUF_HEADROOM is configured to be 128 bytes from the file
./config/common_linuxapp:
CONFIG_RTE_PKTMBUF_HEADROOM=128
Question 1:
Does the above invocation of RTE_MIN() cause the programmer's guide
to be inaccurate?
(Saying "in practice it does not matter..." is not an answer)
Question 2:
Why is "packet metadata" implicitly sharing the same bytes of the mbuf
headroom area,
instead of being explicitly kept from being overwritten by a call to
rte_pktmbuf_prepend(pkt, 100);
presuming my metadata is at least 32 bytes long????
The above command would place the packet data area starting at the last
4 bytes of my metadata....
(Saying "you can change CONFIG_RTE_PKTMBUF_HEADROOM at compile time" is
not an answer because it
effects all mbufs not just the one I with my meta-data...)
Question 3:
Why do we write:
#define MBUF_SIZE (2048 + sizeof(struct rte_mbuf) +
RTE_PKTMBUF_HEADROOM)
rte_mempool_create(s, 1024, MBUF_SIZE, 32,0,
rte_pktmbuf_pool_init, NULL,
rte_pktmbuf_init, NULL,
socketid, flags);
instead of:
#define MBUF_SIZE (2048 + sizeof(struct rte_mbuf))
rte_mempool_create(s, 1024, MBUF_SIZE, 32,0,
rte_pktmbuf_pool_init, NULL,
rte_pktmbuf_init, NULL,
socketid, flags);
and have rte_pktmbuf_init() enforce ( + RTE_PKTMBUF_HEADROOM )
automatically?
------------------------------
My reason for asking the above questions stems from my work on a Packet
Framework
Pipeline.
I came to understand that there really isn't an *explicit* declaration
of "allocate this much meta-data space for each packet".
The programmer's guide and mbuf.h describe of headroom and tailroom as a
place to edit
the packet data. An example would be to wrap the packet for tunnelling by
prepending
and appending the data area to be large enought to contain a new header and
checksum.
In fact, while the programmer's guide mentions packet meta-data a few
times, there is no
section which actually describes ****how to make and access**** your very
own packet meta-data.
This addition would be very nice.
The tables in the Packet Framework Pipeline examples all use keys injected
into the meta-data
of the mbuf at RX time to compare a rule against that key (explicitly
stating the "offset
into packet meta-data") and not allowing "offset into packet data".
I actually like this setup because it allows the meta-data key to be
securely analyzed
and copied from the packet data - keeping malformed packets out of the
decision making
process of the tables.
But, in the end, sharing the meta-data area with the packet headroom seems
to be a very
bad idea.
Sincerely,
Daniel Chapiesky
next reply other threads:[~2014-08-28 23:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 0:00 daniel chapiesky [this message]
2014-08-29 3:09 ` Matthew Hall
2014-08-29 23:22 ` [dpdk-dev] rte_memzone: memzone_reserve_aligned_thread_unsafe failed when running two process at the same time zimeiw
2014-08-30 14:22 ` Zhang, Jerry
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=CAJnwcoPgydbE9BOZCkMejcd4BpLpw7E3gtYnrdCWs0744qJTkg@mail.gmail.com \
--to=dchapiesky2@gmail.com \
--cc=dev@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).