From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f66.google.com (mail-la0-f66.google.com [209.85.215.66]) by dpdk.org (Postfix) with ESMTP id 39940590B for ; Fri, 29 Aug 2014 01:56:49 +0200 (CEST) Received: by mail-la0-f66.google.com with SMTP id hz20so733729lab.5 for ; Thu, 28 Aug 2014 17:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8FpACZcBp9FOpdpuN/MWS5D6r7o0nv0/SKUhL8bi1xE=; b=ARLBHrXa7497bm8xJX9QMuHH+PQJW5G1F8lQV3NpveEbbJQnMRiifKDvDjL1cjUTYD QA8dtsYU7MaIk8UmL8dNVmSseSMSqMhqysNPMxT3CPN7AwNp01ddZ3A78ZQQI0sw8fAL IKVMPCVX/bSsm2/mDSqRSTRcsbH/GlCWd0j3KxE/iHtmZxNaMmb1oGGcooSItgSvS7HG Fo+CddLum6/gRw6Vxa9EGieHDRZVY1lWNdPe+bxHgP9SpUmWHPpPGznejgIQ3M8IeC3Q Rb/XAL88sY9YXgUivqoa7+piUU1g05vquuegkFZZPUKgTrrlAIuvzaXPe1DH29AMcQsB UCbA== MIME-Version: 1.0 X-Received: by 10.152.207.99 with SMTP id lv3mr7898045lac.22.1409270459812; Thu, 28 Aug 2014 17:00:59 -0700 (PDT) Received: by 10.25.165.212 with HTTP; Thu, 28 Aug 2014 17:00:59 -0700 (PDT) Date: Thu, 28 Aug 2014 20:00:59 -0400 Message-ID: From: daniel chapiesky To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] rte_mbuf: documentation, meta-data, and inconsistencies X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:56:49 -0000 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