[dpdk-dev] DPDK Bare Metal
Hello, [This message was previously sent to "contact us" on 01.org... they directed me to post here instead... ] My company is developing secure networking technology and we are currently building a prototype of our system using the dpdk as the underlying communications platform. So far so good. We are interested in finding out how much we can decrease the attack surface of our application by going full bare metal.. (i.e. sans OS). The mention of a bare metal version of dpdk is one of the contributing factors for our working on our prototype. Can you please provide any information on the dpdk bare metal version? Such as: 1) is it in fact - a zero OS version or is it based on a RTOS such as those from Wind River. 2) Does the bare metal version only support one kind of processor family such as i7, or is it possible to target atom or arm with it as well? 3) what are the licensing terms for it? 4) are royalties required? Thank you for your help in resolving these questions. Sincerely, Daniel Chapiesky
[dpdk-dev] rte_table: fails on 32 bit platforms
Hello,
I found a problem with the Packet Framework's rte_table library.
The rte_table library, when compiled against a 32-bit target, becomes
non-functional.
This is because certain code in the various table implementations assumes
64-bit (or 8 byte) pointers.
For example, the following code:
if ((check_params_create_lru(p) != 0) ||
((sizeof(struct rte_table_hash) % CACHE_LINE_SIZE) != 0) ||
((sizeof(struct rte_bucket_4_8) % CACHE_LINE_SIZE) != 0) ) {
return NULL;
}
when combined with the structure:
struct rte_bucket_4_8 {
/* Cache line 0 */
uint64_t signature;
uint64_t lru_list;
struct rte_bucket_4_8 *next;
uint64_t next_valid;
uint64_t key[4];
/* Cache line 1 */
uint8_t data[0];
};
will compile just fine, but the compiler optimizer will happily do constant
propagation,
note the math does not line up, and performs dead code removal, thus
removing everything
below this point without a word.
I was able to do a quick fix by adding a uint32_t pad variable, but that is
a hack.
In rte_table_acl.c we find the following assertion:
RTE_BUILD_BUG_ON(((sizeof(struct rte_table_acl) % CACHE_LINE_SIZE)
!= 0));
This appears to be a better way to perform this kind of check, rather than
embedding it in an "if" statement.
While I have a git patch which fixes this problem, I would prefer that the
experts take a look at this problem and figure out if it can be more
elegantly fixed.
Sincerely,
Daniel Chapiesky
AllSource
Below is listed some of the files and offending bits of code:
In rte_table_hash_key8.c we find:
struct rte_bucket_4_8 {
/* Cache line 0 */
uint64_t signature;
uint64_t lru_list;
struct rte_bucket_4_8 *next;
uint64_t next_valid;
uint64_t key[4];
/* Cache line 1 */
uint8_t data[0];
};
and the questionable checks:
/* Check input parameters */
if ((check_params_create_lru(p) != 0) ||
((sizeof(struct rte_table_hash) % CACHE_LINE_SIZE) != 0) ||
((sizeof(struct rte_bucket_4_8) % CACHE_LINE_SIZE) != 0) ) {
return NULL;
}
This was fixed by me using 4 bytes for padding:
struct rte_bucket_4_8 {
/* Cache line 0 */
uint64_t signature;
uint64_t lru_list;
struct rte_bucket_4_8 *next;
uint32_t pad0; // <<< TOTAL HACK
uint64_t next_valid;
uint64_t key[4];
/* Cache line 1 */
uint8_t data[0];
};
---
The same code structure was found in these files as well:
rte_table_hash_key16.c
rte_table_hash_key32.c
rte_table_hash_lru.c
---
Interestingly in rte_table_hash_ext.c we find:
struct bucket {
union {
uintptr_t next;
uint64_t lru_list;
};
uint16_t sig[KEYS_PER_BUCKET];
uint32_t key_pos[KEYS_PER_BUCKET];
};
and the questionable checks:
/* Check input parameters */
if ((check_params_create(p) != 0) ||
(!rte_is_power_of_2(entry_size)) ||
((sizeof(struct rte_table_hash) % CACHE_LINE_SIZE) != 0) ||
(sizeof(struct bucket) != (CACHE_LINE_SIZE / 2)))
return NULL;
The union in struct bucket saves us from 32 bit pointers mucking up the
math.
[dpdk-dev] rte_mbuf: documentation, meta-data, and inconsistencies
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
[dpdk-dev] to the intel dpdk engineers and all contributors
I just watched the closing remarks by Tim Driscol at the dpdk summit http://youtu.be/r-JA5NBybrs At time 4:30, he mentioned the "shock to the system" of developers expecting a pat on the back and instead receiving critiques of their code. I realized that I was one of those who failed to acknowledge the incredible work the Intel Engineers and other contributors have produced. Please let me acknowledge all of you and your efforts with a few comments: 1) Kudos!!: 2) The Packet Framework made me run around waving my hands in the air yelling: "This is freaking awesome! I don't have to write it myself!!!" 3) The layered architecture is elegant. 4) Examples The examples are wonderful! Those who wrote the examples are my heroes. 5) Docs? Clear, to the point, and better than the other projects we depend upon (you know who you are) 6) 6Wind - Thank you for taking on the management of the repository and website - your coordination effort is truly appreciated 7) Did I say the Packet Framework saved me so much time I was actually able to cut back my coffee intake by 10% 8) Windriver - PktGen! (though I really want to know more about mcos) Finally, I recently received a pat on the back for the application I have developed. In truth, that pat should be passed on, since my application depends so heavily on DPDK. Thank you. I encourage others to let the Intel Engineers and contributors know how much we appreciate the time and effort they have given to DPDK. Sincerely, Daniel Chapiesky AllSource
