[dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user support into DPDK vhost library
Hi Haifeng: Might be in the release after 1.8. > -Original Message- > From: Linhaifeng [mailto:haifeng.lin at huawei.com] > Sent: Saturday, September 13, 2014 1:28 PM > To: Xie, Huawei; dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user support > into DPDK vhost library > > when will publish ? > > On 2014/8/26 19:05, Xie, Huawei wrote: > > Hi all: > > We are implementing qemu official vhost-user interface into DPDK vhost > library, so there would be two coexisting implementations for user space > vhost backend. > > Pro and cons in my mind: > > Existing solution: > > Pros: works with qemu version before 2.1; Cons: depends on eventfd > proxy kernel module and extra maintenance effort > > Qemu vhost-user: > >Pros: qemu official us-vhost interface; Cons: only > > available > after qemu 2.1 > > > > BR. > > huawei > > > >
[dpdk-dev] Patch merges for 1.8 release
Hi Thomas, I'm just wondering what the expected timeline is for you starting to merge patches in for the 1.8 release? As you have probably seen, I have quite a number of outstanding patches submitted for mbufs, and I'm wonder when the "part 1" set, which by now has been pretty well reviewed and ack'ed, might be merged to the mainline? I'm loath to start upstreaming drafts of part 3 patches at this stage, because the depth of the backlog I'm building up just increases the amount of work I have to do for any mainline changes that require me to do changes on rebase. Thanks, /Bruce
[dpdk-dev] Valgrind and DPDK - does it work ?
Hi all,
I am interested to hear if anyone here have had any luck running Valgrind on
DPDK applications?
I tried to use this some time ago, but Valgrind does not seem to work
together with hugepages ? or
I am doing something wrong ;-)
I would like to hear form anyone having success or failure with Valgrind and
DPDK.
Best regards
/Morten
This is an extract of a printout from running my application normally
>sudo ./build/l47app ?c 0x ?n 4
EAL: Detected a total of 32 lcores
EAL: Setting up memory...
EAL: Ask a virtual area of 0x28000 bytes
EAL: Virtual area found at 0x7f7b8000 (size = 0x28000)
EAL: Ask a virtual area of 0x28000 bytes
EAL: Virtual area found at 0x7f78c000 (size = 0x28000)
EAL: Requesting 10 pages of size 1024MB from socket 0
EAL: Requesting 10 pages of size 1024MB from socket 1
This is what I get when running Valgrind
>sudo valgrind --leak-check=full ./build/l47server
EAL: Detected a total of 32 lcores
EAL: Setting up memory...
EAL: map_all_hugepages(): mmap failed: Invalid argument
EAL: Failed to mmap 1024 MB hugepages
And here is an strace of the above command
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 29696
read(1028, "C", 1) = 1
close(6)= 0
gettid()= 29696
write(1029, "D", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(1, "EAL: Setting up memory...\n", 26EAL: Setting up memory...
) = 26
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 29696
read(1028, "D", 1) = 1
mmap(0x805b51000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x805b51000
getpid()= 29696
getpid()= 29696
gettid()= 29696
write(1029, "E", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
open("/dev/hugepages/rtemap_0", O_RDWR|O_CREAT, 0755) = 6
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 29696
read(1028, "E", 1) = 1
mmap(0x39fe, 1073741824, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 6,
0) = -1 EINVAL (Invalid argument)
gettid()= 29696
write(1029, "F", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(1, "EAL: map_all_hugepages(): mmap f"..., 56EAL: map_all_hugepages():
mmap failed: Invalid argument
) = 56
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) = 0
gettid()= 29696
read(1028, "F", 1) = 1
close(6)= 0
gettid()= 29696
write(1029, "G", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
write(1, "EAL: Failed to mmap 1024 MB huge"..., 38EAL: Failed to mmap 1024
MB hugepages
Morten Jagd Christensen
VP Product Management
Xena Networks
L?derstr?de 34, 3rd Floor
1201 Copenhagen K
Denmark
Ph: (+45) 51 54 51 87
mjc at xenanetworks.com
[dpdk-dev] [PATCH 2/3] distributor_app: code review comments implementation
From: Reshma Pattan
* support provided for command-line option portmask.
* removed -g option in make file
* spacing adjustment in header files inclusion in main.c
* removal of const +3 in delcarration of rte_mbuf inside
output_buffer structure declaration
Changes in V2:
Signed-off-by: Reshma Pattan
---
examples/distributor_app/Makefile | 2 +-
examples/distributor_app/main.c | 137 --
2 files changed, 133 insertions(+), 6 deletions(-)
diff --git a/examples/distributor_app/Makefile
b/examples/distributor_app/Makefile
index d46746e..394785d 100644
--- a/examples/distributor_app/Makefile
+++ b/examples/distributor_app/Makefile
@@ -52,6 +52,6 @@ ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_main.o += -Wno-return-type
endif
-EXTRA_CFLAGS += -O3 -g -Wfatal-errors
+EXTRA_CFLAGS += -O3 -Wfatal-errors
include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/distributor_app/main.c b/examples/distributor_app/main.c
index 45d5bc1..fab8199 100644
--- a/examples/distributor_app/main.c
+++ b/examples/distributor_app/main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -42,6 +43,7 @@
#include
#include
#include
+
#include "main.h"
#define RX_RING_SIZE 256
@@ -66,6 +68,9 @@
#define BURST_SIZE 32
#define RTE_RING_SZ 1024
+/* mask of enabled ports */
+static uint32_t enabled_port_mask = 0;
+
static volatile struct app_stats {
struct {
uint64_t rx_pkts;
@@ -127,7 +132,7 @@ static const struct rte_eth_txconf tx_conf_default = {
struct output_buffer {
unsigned count;
- struct rte_mbuf *mbufs[BURST_SIZE + 3];
+ struct rte_mbuf *mbufs[BURST_SIZE];
};
/*
@@ -210,16 +215,27 @@ lcore_rx(struct lcore_params *p)
const int socket_id = rte_socket_id();
uint8_t port;
- for (port = 0; port < nb_ports; port++)
+ for (port = 0; port < nb_ports; port++){
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0){
+ continue;
+ }
if (rte_eth_dev_socket_id(port) > 0 &&
rte_eth_dev_socket_id(port) != socket_id)
printf("WARNING, port %u is on remote NUMA node to "
"RX thread.\n\tPerformance will not "
"be optimal.\n", port);
+ }
printf("\nCore %u doing packet RX.\n", rte_lcore_id());
port = 0;
for (;;) {
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0){
+ if (++port == nb_ports)
+ port = 0;
+ continue;
+ }
struct rte_mbuf *bufs[BURST_SIZE*2];
const uint16_t nb_rx = rte_eth_rx_burst(port, 0, bufs,
BURST_SIZE);
@@ -265,6 +281,11 @@ flush_all_ports(struct output_buffer *tx_buffers, uint8_t
nb_ports)
{
uint8_t outp;
for (outp = 0; outp < nb_ports; outp++) {
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << outp)) == 0){
+ continue;
+ }
+
if (tx_buffers[outp].count == 0)
continue;
@@ -280,16 +301,25 @@ lcore_tx(struct rte_ring *in_r)
const int socket_id = rte_socket_id();
uint8_t port;
- for (port = 0; port < nb_ports; port++)
+ for (port = 0; port < nb_ports; port++){
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0){
+ continue;
+ }
if (rte_eth_dev_socket_id(port) > 0 &&
rte_eth_dev_socket_id(port) != socket_id)
printf("WARNING, port %u is on remote NUMA node to "
"TX thread.\n\tPerformance will not "
"be optimal.\n", port);
+ }
printf("\nCore %u doing packet TX.\n", rte_lcore_id());
for (;;) {
for (port = 0; port < nb_ports; port++) {
+ /* skip ports that are not enabled */
+ if ((enabled_port_mask & (1 << port)) == 0){
+ continue;
+ }
struct rte_mbuf *bufs[BURST_SIZE];
const uint16_t nb_rx = rte_ring_dequeue_burst(in_r,
(void *)bufs, BURST_SIZE);
@@ -313,6 +343,10 @@ lcore_tx(struct rte_ring *in_r)
/* workers should update in_port to hold the
* output port value */
outp = bufs[i]->pkt.in_port;
+
[dpdk-dev] [PATCH 0/3] distributor_app: new sample application for distributor library
From: Reshma Pattan A new sample app that shows the usage of the distributor library. This app works as follows: *An RX thread runs which pulls packets from each ethernet port in turn and passes those packets to worker using a distributor component. *The workers take the packets in turn, and determine the output port for those packets using basic l2forwarding doing an xor on the source port id. *The RX thread takes the returned packets from the workers and enqueue those packets into an rte_ring structure. *A TX thread pulls the packets off the rte_ring structure and then sends each packet out the output port specified previously by the worker Bruce Richardson (1): distributor_app: new sample app Reshma Pattan (2): distributor_app: code review comments implementation distributor_app: removed extra spaces examples/Makefile | 1 + examples/distributor_app/Makefile | 57 examples/distributor_app/main.c | 586 ++ examples/distributor_app/main.h | 46 +++ 4 files changed, 690 insertions(+) create mode 100644 examples/distributor_app/Makefile create mode 100644 examples/distributor_app/main.c create mode 100644 examples/distributor_app/main.h -- 1.8.3.1
[dpdk-dev] [PATCH 1/3] distributor_app: new sample app
From: Bruce Richardson A new sample app that shows the usage of the distributor library. This app works as follows: * An RX thread runs which pulls packets from each ethernet port in turn and passes those packets to worker using a distributor component. * The workers take the packets in turn, and determine the output port for those packets using basic l2forwarding doing an xor on the source port id. * The RX thread takes the returned packets from the workers and enqueue those packets into an rte_ring structure. * A TX thread pulls the packets off the rte_ring structure and then sends each packet out the output port specified previously by the worker The app takes no command-line parameters other than those passed to the EAL. The cores to be used are specified via the EAL coremask and the ports to be used can be specified using the EAL whitelisting and blacklisting support. --- examples/Makefile | 1 + examples/distributor_app/Makefile | 57 + examples/distributor_app/main.c | 459 ++ examples/distributor_app/main.h | 46 4 files changed, 563 insertions(+) create mode 100644 examples/distributor_app/Makefile create mode 100644 examples/distributor_app/main.c create mode 100644 examples/distributor_app/main.h diff --git a/examples/Makefile b/examples/Makefile index d6b08c2..3164aab 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -64,5 +64,6 @@ DIRS-y += vhost DIRS-$(CONFIG_RTE_LIBRTE_XEN_DOM0) += vhost_xen DIRS-y += vmdq DIRS-y += vmdq_dcb +DIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += distributor_app include $(RTE_SDK)/mk/rte.extsubdir.mk diff --git a/examples/distributor_app/Makefile b/examples/distributor_app/Makefile new file mode 100644 index 000..d46746e --- /dev/null +++ b/examples/distributor_app/Makefile @@ -0,0 +1,57 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overriden by command line or environment +RTE_TARGET ?= x86_64-default-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +# binary name +APP = distributor_app + +# all source are stored in SRCS-y +SRCS-y := main.c + +CFLAGS += $(WERROR_FLAGS) + +# workaround for a gcc bug with noreturn attribute +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) +CFLAGS_main.o += -Wno-return-type +endif + +EXTRA_CFLAGS += -O3 -g -Wfatal-errors + +include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/distributor_app/main.c b/examples/distributor_app/main.c new file mode 100644 index 000..45d5bc1 --- /dev/null +++ b/examples/distributor_app/main.c @@ -0,0 +1,459 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other material
[dpdk-dev] [PATCH 3/3] distributor_app: removed extra spaces
From: Reshma Pattan
Changes in V2:
Signed-off-by: Reshma Pattan
---
examples/distributor_app/main.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/examples/distributor_app/main.c b/examples/distributor_app/main.c
index fab8199..b064a3a 100644
--- a/examples/distributor_app/main.c
+++ b/examples/distributor_app/main.c
@@ -230,7 +230,7 @@ lcore_rx(struct lcore_params *p)
printf("\nCore %u doing packet RX.\n", rte_lcore_id());
port = 0;
for (;;) {
- /* skip ports that are not enabled */
+ /* skip ports that are not enabled */
if ((enabled_port_mask & (1 << port)) == 0){
if (++port == nb_ports)
port = 0;
@@ -283,7 +283,7 @@ flush_all_ports(struct output_buffer *tx_buffers, uint8_t
nb_ports)
for (outp = 0; outp < nb_ports; outp++) {
/* skip ports that are not enabled */
if ((enabled_port_mask & (1 << outp)) == 0){
- continue;
+ continue;
}
if (tx_buffers[outp].count == 0)
@@ -302,7 +302,7 @@ lcore_tx(struct rte_ring *in_r)
uint8_t port;
for (port = 0; port < nb_ports; port++){
- /* skip ports that are not enabled */
+ /* skip ports that are not enabled */
if ((enabled_port_mask & (1 << port)) == 0){
continue;
}
@@ -316,7 +316,7 @@ lcore_tx(struct rte_ring *in_r)
printf("\nCore %u doing packet TX.\n", rte_lcore_id());
for (;;) {
for (port = 0; port < nb_ports; port++) {
- /* skip ports that are not enabled */
+ /* skip ports that are not enabled */
if ((enabled_port_mask & (1 << port)) == 0){
continue;
}
@@ -431,16 +431,16 @@ parse_portmask(const char *portmask)
}
/* Parse the argument given in the command line of the application */
-static int
+static int
parse_args(int argc, char **argv)
{
int opt;
char **argvopt;
int option_index;
char *prgname = argv[0];
-static struct option lgopts[] = {
+static struct option lgopts[] = {
{NULL, 0, 0, 0}
-};
+};
argvopt = argv;
@@ -454,8 +454,8 @@ parse_args(int argc, char **argv)
if (enabled_port_mask == 0) {
printf("invalid portmask\n");
print_usage(prgname);
-return -1;
-}
+return -1;
+}
break;
default:
@@ -499,7 +499,7 @@ MAIN(int argc, char *argv[])
/* parse application arguments (after the EAL ones) */
ret = parse_args(argc, argv);
-if (ret < 0)
+if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid distributor parameters\n");
if (rte_lcore_count() < 3)
@@ -549,7 +549,7 @@ MAIN(int argc, char *argv[])
if (!nb_ports_available) {
rte_exit(EXIT_FAILURE,
"All available ports are disabled. Please set
portmask.\n");
-}
+}
d = rte_distributor_create("PKT_DIST", rte_socket_id(),
rte_lcore_count() - 2);
--
1.8.3.1
[dpdk-dev] [PATCH 0/3] eal / bonding pmd cleanup
On Tue, Aug 26, 2014 at 4:12 PM, David Marchand wrote: > This patchset reworks the bonding pmd so that we don't need to modify the > eal > for this pmd to work. > > Basically, the arguments parsed at bond_init are stored in the bond private > structure to be used at dev_configure time. > If no argument are present, we suppose that the bonding api has been > called. > I did not get any comment on these patches. Anyone ? The idea here is to keep pmd stuff in the pmds and avoid polluting the eal. -- David Marchand
[dpdk-dev] About RTE_MAX_ETHPORT_QUEUE_STATS_MAPS
Hi, 2014-08-21 10:04, Alejandro Lucero: > Documentation and header files describe stat_idx parameter for > rte_eth_dev_set_tx_queue_stats_mapping > and > rte_eth_dev_set_rx_queue_stats_mapping > as > The value must be in the range > [0, RTE_MAX_ETHPORT_QUEUE_STATS_MAPS - 1] This function should not be part of the generic API. It's an ixgbe-only setup. Cleanup is required here. > I have not found a definition for RTE_MAX_ETHPORT_QUEUE_STATS_MAPS but the > per queue counters inside struct rte_eth_stats are arrays with length > RTE_ETHDEV_QUEUE_STAT_CNTRS which is defined at > config/defconfig_x86_64-default-linuxapp-gcc > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16 > > I assume RTE_MAX_ETHPORT_QUEUE_STATS_MAPS is equal to > CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS. To be more precise, this index must be lower than the number of stat counters (CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16) AND lower than the number of ixgbe hardware counters (16 if I remember well). A patch to fix this doxygen comment would be welcome. Another patch to move this API in an ixgbe specific file would be great. Thanks -- Thomas
[dpdk-dev] Patch merges for 1.8 release
Hi Bruce, 2014-09-16 11:18, Bruce Richardson: > I'm just wondering what the expected timeline is for you starting to merge > patches in for the 1.8 release? As you have > probably seen, I have quite a number of outstanding patches submitted for > mbufs, and I'm wonder when the "part 1" set, > which by now has been pretty well reviewed and ack'ed, might be merged to the > mainline? I'm loath to start upstreaming > drafts of part 3 patches at this stage, because the depth of the backlog I'm > building up just increases the amount > of work I have to do for any mainline changes that require me to do changes > on rebase. I was very busy last week with DPDK summit and IDF. Now I'm back and I'm cleaning up the patchwork tool (before availability announcement in a couple of days). Then the goal of the next days is to make a -rc1 tag with all the patches which are ready and properly reviewed. The mbuf changes are first in my list. -- Thomas
[dpdk-dev] Patch merges for 1.8 release
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, September 16, 2014 3:20 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: Patch merges for 1.8 release > > Hi Bruce, > > 2014-09-16 11:18, Bruce Richardson: > > I'm just wondering what the expected timeline is for you starting to merge > patches in for the 1.8 release? As you have > > probably seen, I have quite a number of outstanding patches submitted for > mbufs, and I'm wonder when the "part 1" set, > > which by now has been pretty well reviewed and ack'ed, might be merged to > the mainline? I'm loath to start upstreaming > > drafts of part 3 patches at this stage, because the depth of the backlog I'm > building up just increases the amount > > of work I have to do for any mainline changes that require me to do changes > on rebase. > > I was very busy last week with DPDK summit and IDF. > Now I'm back and I'm cleaning up the patchwork tool (before availability > announcement in a couple of days). > Then the goal of the next days is to make a -rc1 tag with all the patches > which are ready and properly reviewed. > The mbuf changes are first in my list. > Thanks for the info, and welcome back! /Bruce
[dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf metadata
Hi Olivier,
I agree that your suggested approach for application-dependent metadata makes
sense, in fact the two approaches work in exactly the same way (packet metadata
immediately after the regular mbuf), there is only a subtle difference, which
is related to defining consistent DPDK usage guidelines.
1. Advertising the presence of application-dependent meta-data as supported
mechanism
If we explicitly have a metadata zero-size field at the end of the mbuf, we
basically tell people that adding their own application meta-data at the end of
the mandatory meta-data (mbuf structure) is a mechanism that DPDK allows and
supports, and will continue to do so for the foreseeable future. In other
words, we guarantee that an application doing so will continue to build
successfully with future releases of DPDK, and we will not introduce changes in
DPDK that could potentially break this mechanism. It is also a hint to people
of where to put their application dependent meta-data.
2. Defining a standard base address for the application-dependent metadata
- There are also libraries in DPDK that work with application dependent
meta-data, currently these are the Packet Framework libraries: librte_port,
librte_table, librte_pipeline. Of course, the library does not have the
knowledge of the application dependent meta-data format, so they treat it as
opaque array of bytes, with the offset and size of the array given as
arguments. In my opinion, it is safer (and more elegant) if these libraries
(and others) can rely on an mbuf API to access the application dependent
meta-data (in an opaque way) rather than make an assumption about the mbuf
(i.e. the location of custom metadata relative to the mbuf) that is not clearly
supported/defined by the mbuf library.
- By having this API, we basically say: we define the custom meta-data base
address (first location where custom metadata _could_ be placed) immediately
after the mbuf, so libraries and apps accessing custom meta-data should do so
by using a relative offset from this base rather than each application defining
its own base: immediately after mbuf, or 128 bytes after mbuf, or 64 bytes
before the end of the buffer, or other.
More (minor) comments inline below.
Thanks,
Cristian
-Original Message-
From: Olivier MATZ [mailto:olivier.m...@6wind.com]
Sent: Friday, September 12, 2014 10:02 PM
To: Dumitrescu, Cristian; Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf
metadata
Hello Cristian,
> What is the reason to remove this field? Please explain the
> rationale of removing this field.
The rationale is explained in
http://dpdk.org/ml/archives/dev/2014-September/005232.html
"The format of the metadata is up to the application".
The type of data the application stores after the mbuf has not
to be defined in the mbuf. These macros limits the types of
metadata to uint8, uint16, uint32, uint64? What should I do
if I need a void*, a struct foo ? Should we add a macro for
each possible type?
[Cristian] Actually, this is not correct, as macros to access metadata through
pointers (to void or scalar types) are provided as well. This pointer can be
converted by the application to the format is defines.
> We previously agreed we need to provide an easy and standard
> mechanism for applications to extend the mandatory per buffer
> metadata (mbuf) with optional application-dependent
> metadata.
Defining a structure in the application which does not pollute
the rte_mbuf structure is "easy and standard(TM)" too.
[Cristian] I agree, both approaches work the same really, it is just the
difference in advertising the presence of meta-data as supported mechanism and
defining a standard base address for it.
> This field just provides a clean way for the apps to
> know where is the end of the mandatory metadata, i.e. the first
> location in the packet buffer where the app can add its own
> metadata (of course, the app has to manage the headroom space
> before the first byte of packet data). A zero-size field is the
> standard mechanism that DPDK uses extensively in pretty much
> every library to access memory immediately after a header
> structure.
Having the following is clean too:
struct metadata {
...
};
struct app_mbuf {
struct rte_mbuf mbuf;
struct metadata metadata;
};
There is no need to define anything in the mbuf structure.
[Cristian] I agree, both approaches work the same really, it is just the
difference in advertising the presence of meta-data as supported mechanism and
defining a standard base address for it.
>
> The impact of removing this field is that there is no standard
> way to identify where the end of the mandatory metadata is, so
> each application will have to reinvent this. With no clear
> convention, we will end up with a lot of non-standard ways. Every
> time the format of the mbuf structure is going to be changed,
> this can potential
[dpdk-dev] [PATCH v2] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices
On Fri, Sep 12, 2014 at 02:05:23PM -0400, John W. Linville wrote: > Ping? Are there objections to this patch from mid-July? > > John > Thomas, Where are you on this? It seems like if you don't have any objections to this patch, it should go in, in ilght of the lack of further commentary. Neil
[dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf metadata
I completely agree with Cristian here, instead of leaving to applications where
to place their meta data, we can provide a guidance by having this field about
placement of application meta while maintaining transparency on the contents of
application meta information.
Regards
Kannan Babu Ramia
Sr.System Architect
Communication Storage Infrastructure Group
DCG
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dumitrescu, Cristian
Sent: Wednesday, September 17, 2014 1:37 AM
To: Olivier MATZ; Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf
metadata
Hi Olivier,
I agree that your suggested approach for application-dependent metadata makes
sense, in fact the two approaches work in exactly the same way (packet metadata
immediately after the regular mbuf), there is only a subtle difference, which
is related to defining consistent DPDK usage guidelines.
1. Advertising the presence of application-dependent meta-data as supported
mechanism If we explicitly have a metadata zero-size field at the end of the
mbuf, we basically tell people that adding their own application meta-data at
the end of the mandatory meta-data (mbuf structure) is a mechanism that DPDK
allows and supports, and will continue to do so for the foreseeable future. In
other words, we guarantee that an application doing so will continue to build
successfully with future releases of DPDK, and we will not introduce changes in
DPDK that could potentially break this mechanism. It is also a hint to people
of where to put their application dependent meta-data.
2. Defining a standard base address for the application-dependent metadata
- There are also libraries in DPDK that work with application dependent
meta-data, currently these are the Packet Framework libraries: librte_port,
librte_table, librte_pipeline. Of course, the library does not have the
knowledge of the application dependent meta-data format, so they treat it as
opaque array of bytes, with the offset and size of the array given as
arguments. In my opinion, it is safer (and more elegant) if these libraries
(and others) can rely on an mbuf API to access the application dependent
meta-data (in an opaque way) rather than make an assumption about the mbuf
(i.e. the location of custom metadata relative to the mbuf) that is not clearly
supported/defined by the mbuf library.
- By having this API, we basically say: we define the custom meta-data base
address (first location where custom metadata _could_ be placed) immediately
after the mbuf, so libraries and apps accessing custom meta-data should do so
by using a relative offset from this base rather than each application defining
its own base: immediately after mbuf, or 128 bytes after mbuf, or 64 bytes
before the end of the buffer, or other.
More (minor) comments inline below.
Thanks,
Cristian
-Original Message-
From: Olivier MATZ [mailto:olivier.m...@6wind.com]
Sent: Friday, September 12, 2014 10:02 PM
To: Dumitrescu, Cristian; Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf
metadata
Hello Cristian,
> What is the reason to remove this field? Please explain the rationale
> of removing this field.
The rationale is explained in
http://dpdk.org/ml/archives/dev/2014-September/005232.html
"The format of the metadata is up to the application".
The type of data the application stores after the mbuf has not to be defined in
the mbuf. These macros limits the types of metadata to uint8, uint16, uint32,
uint64? What should I do if I need a void*, a struct foo ? Should we add a
macro for each possible type?
[Cristian] Actually, this is not correct, as macros to access metadata through
pointers (to void or scalar types) are provided as well. This pointer can be
converted by the application to the format is defines.
> We previously agreed we need to provide an easy and standard mechanism
> for applications to extend the mandatory per buffer metadata (mbuf)
> with optional application-dependent metadata.
Defining a structure in the application which does not pollute the rte_mbuf
structure is "easy and standard(TM)" too.
[Cristian] I agree, both approaches work the same really, it is just the
difference in advertising the presence of meta-data as supported mechanism and
defining a standard base address for it.
> This field just provides a clean way for the apps to know where is the
> end of the mandatory metadata, i.e. the first location in the packet
> buffer where the app can add its own metadata (of course, the app has
> to manage the headroom space before the first byte of packet data). A
> zero-size field is the standard mechanism that DPDK uses extensively
> in pretty much every library to access memory immediately after a
> header structure.
Having the following is clean too:
struct metadata {
...
};
struct app_mbuf {
