dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
* rte_mbuf: documentation, meta-data, and inconsistencies
@ 2014-08-29  0:00 daniel chapiesky
       [not found] ` <CAJnwcoPgydbE9BOZCkMejcd4BpLpw7E3gtYnrdCWs0744qJTkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: daniel chapiesky @ 2014-08-29  0:00 UTC (permalink / raw)
  To: dev-VfR2kkLFssw

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

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-08-30 14:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-29  0:00 rte_mbuf: documentation, meta-data, and inconsistencies daniel chapiesky
     [not found] ` <CAJnwcoPgydbE9BOZCkMejcd4BpLpw7E3gtYnrdCWs0744qJTkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-29  3:09   ` Matthew Hall
2014-08-29 23:22   ` rte_memzone: memzone_reserve_aligned_thread_unsafe failed when running two process at the same time zimeiw
     [not found]     ` <14f9ed02.118f5.1482414316f.Coremail.zimeiw-9Onoh4P/yGk@public.gmane.org>
2014-08-30 14:22       ` Zhang, Jerry

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).