[dpdk-dev] Build break on Ubuntu12.04
Hello, For DPDK 1.6.0, cd $(DPDK_DIR) make install T=x86_64-ivshmem-linuxapp-gcc => No Errors. However, for Openvswitch, cd $(OVS_DIR)/openvswitch ./boot.sh ./configure RTE_SDK=$(DPDK_DIR) make I got following ERROR message. gcc -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wdeclaration-after-statement -Wformat-security -Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align -Wmissing-prototypes -Wmissing-field-initializers -Wno-bad-function-cast -g -O2 -export-dynamic -lpthread -o tests/test-dpdk-link tests/test-dpdk-link.o tests/dpdk-ring-stub.o lib/libopenvswitch.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_mbuf.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_eal.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_pmd_ring.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/libethdev.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_cmdline.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_hash.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_lpm.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_mempool.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_ring.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_malloc.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_ivshmem.a -lpthread -lrt -lm lib/libopenvswitch.a(stream-ssl.o): In function `interpret_queued_ssl_error': /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:516: undefined reference to `ERR_get_error' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:518: undefined reference to `ERR_error_string' lib/libopenvswitch.a(stream-ssl.o): In function `interpret_ssl_error': /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:562: undefined reference to `ERR_get_error' lib/libopenvswitch.a(stream-ssl.o): In function `read_cert_file': /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1136: undefined reference to `PEM_read_X509' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1140: undefined reference to `ERR_get_error' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1140: undefined reference to `ERR_error_string' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1143: undefined reference to `X509_free' lib/libopenvswitch.a(stream-ssl.o): In function `log_ca_cert': /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1207: undefined reference to `EVP_sha1' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1207: undefined reference to `X509_digest' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1218: undefined reference to `X509_get_subject_name' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1218: undefined reference to `X509_NAME_oneline' /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1221: undefined reference to `CRYPTO_free' lib/libopenvswitch.a(stream-ssl.o): In function `ssl_wait': Please help me...
[dpdk-dev] [PATCH 03/15] pmd: Add PMD_REGISTER_DRIVER macro
Hi Neil, On 04/16/2014 07:29 PM, Neil Horman wrote: > Ok, so look it up. DPDK is open source and cscope is easy to use. A > module initilization macro is a common method for doing init time binding in > modular programming (the best examples are the module_init() and module_exit() > macros in the linux kernel). It wraps up what you need to do to tie a modular > piece of your software into the larger main component, without having to know > all the boilerplate behind it. > > Also, if you expose the use of the constructor, then you've > broken out the initalization phase to every pmd you implement, and as a > result, > if you ever need to add code to the initilization step, you have to add it in > every pmd, instead of just updating the macro. > > The bottom line is, your method is 5 lines of boilerplate code thats going to > have to get repeated as nauseum for every pmd that gets written giving every > PMD > author the opportunity to miscode the constructor, vs my one line that, if it > compiles, will be correct every time. OK, some of your arguments are legitimate and it's a detail point of your patches that are globally a nice improvement of the DPDK code. But I'd be happy to continue this discussion over a beer ;) Regards, Olivier
[dpdk-dev] Build break on Ubuntu12.04
Hi, On 04/17/2014 09:47 AM, ??? wrote: > cd $(OVS_DIR)/openvswitch > ./boot.sh > ./configure RTE_SDK=$(DPDK_DIR) > make > > I got following ERROR message. > > gcc -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith > -Wdeclaration-after-statement -Wformat-security -Wswitch-enum > -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast -Wcast-align > -Wmissing-prototypes -Wmissing-field-initializers -Wno-bad-function-cast -g > -O2 -export-dynamic -lpthread -o tests/test-dpdk-link tests/test-dpdk-link.o > tests/dpdk-ring-stub.o lib/libopenvswitch.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_mbuf.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_eal.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_pmd_ring.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/libethdev.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_cmdline.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_hash.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_lpm.a > /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/l ib/librte_mempool.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_ring.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_malloc.a /home/snp/dpdk-ovs/DPDK-1.6.0/x86_64-ivshmem-linuxapp-gcc/lib/librte_ivshmem.a -lpthread -lrt -lm > lib/libopenvswitch.a(stream-ssl.o): In function `interpret_queued_ssl_error': > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:516: undefined reference to > `ERR_get_error' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:518: undefined reference to > `ERR_error_string' > lib/libopenvswitch.a(stream-ssl.o): In function `interpret_ssl_error': > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:562: undefined reference to > `ERR_get_error' > lib/libopenvswitch.a(stream-ssl.o): In function `read_cert_file': > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1136: undefined reference to > `PEM_read_X509' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1140: undefined reference to > `ERR_get_error' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1140: undefined reference to > `ERR_error_string' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1143: undefined reference to > `X509_free' > lib/libopenvswitch.a(stream-ssl.o): In function `log_ca_cert': > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1207: undefined reference to > `EVP_sha1' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1207: undefined reference to > `X509_digest' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1218: undefined reference to > `X509_get_subject_name' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1218: undefined reference to > `X509_NAME_oneline' > /home/snp/dpdk-ovs/openvswitch/lib/stream-ssl.c:1221: undefined reference to > `CRYPTO_free' > lib/libopenvswitch.a(stream-ssl.o): In function `ssl_wait': I think you should post your question to dpdk-ovs at lists.01.org instead. Regards, Olivier
[dpdk-dev] build break on BSD
Hi Neil, On 04/16/2014 09:52 PM, Neil Horman wrote: > I was just trying to do a build on bsd for dpdk and hit this: > > == Build lib/librte_eal/bsdapp/eal >CC eal.o > /root/git/dpdk/lib/librte_eal/bsdapp/eal/eal.c: In function ?eal_parse_args?: > /root/git/dpdk/lib/librte_eal/bsdapp/eal/eal.c:654:5: error: implicit > declaration of function ?eal_dev_whitelist_add_entry? > [-Werror=implicit-function-declaration] > eal_dev_whitelist_add_entry(optarg); > ^ > [...] > > Looks like the recent whitelist/blacklist patches forgot to add the > rte_devargs > headers to the BSD build. Thanks for reporting, I'll have a look ASAP. Regards, Olivier
[dpdk-dev] when create DMA space to NIC
HI ! When create NIC tx_desc in eth_igb_tx_queue_setup(), tx_desc was allocated by ring_dma_zone_reserve(). But when DMA speace was allocated by EAL(memzone)? eth_igb_tx_queue_setup()-->ring_dma_zone_reserve()-->memzone_lookup_thread_u nsafe()-->mcfg->memzone[] THANKS
[dpdk-dev] Calling rte_eal_init multiple times in the same process
Dear all, I'm not sure who to address with this email so I'll just present my problem and my suggested solution. The problem I'm facing is that I need to do rte_eal_init serveral times in the same process. The reason for this is mostly architectural as we want to divide certain functionality in to different, implementation independent, modules in which DPDK would be used for different purposes. Thus we would need to eventually call rte_eal_init several times because we can't say for sure if it has been called by another module or not. While thinking about it I saw no good, existing solution to this (I might have missed it though). Would returning a "DPDK has already been initialized" error code in rte_eal_init be a good way to go about it? I haven't done this yet but I could probably provide a patch if it's interesting. Thank you for your time and a very nice framework with good documentation! BR, Tomas
[dpdk-dev] Calling rte_eal_init multiple times in the same process
Hello, 2014-04-17 09:09, Tomas Vestelind: > The problem I'm facing is that I need to do rte_eal_init serveral times in > the same process. The reason for this is mostly architectural as we want to > divide certain functionality in to different, implementation independent, > modules in which DPDK would be used for different purposes. Thus we would > need to eventually call rte_eal_init several times because we can't say for > sure if it has been called by another module or not. > > While thinking about it I saw no good, existing solution to this (I might > have missed it though). Would returning a "DPDK has already been > initialized" error code in rte_eal_init be a good way to go about it? I > haven't done this yet but I could probably provide a patch if it's > interesting. Don't hesitate to submit a patch. It's far easier to discuss on a patch basis. If your patch fill your need and nobody complains about it, it will be accepted. -- Thomas
[dpdk-dev] [PATCH 05/15] ring: Convert to use of PMD_REGISTER_DRIVER and fix linking
Hi Neil,
Few comments from me there.
Thanks
Konstantin
- parse_kvlist():
1)
node = strchr(name, ':');
...
action = strchr(node, ':');
We can't expect that input parameter will always be valid.
So need to check that strchr() doesn't return NULL.
2)
if (strcmp(action, "ATTACH"))
if (strcmp(action, "CREATE"))
goto out;
...
info->list[info->count].action = strcmp(action, "ATTACH") ? DEV_CREATE :
DEV_ATTACH;
Can you create a macros for these 2 string constants and use them instead.
Another thing, probably better to reorder it that way:
if (strcmp(action, "ATTACH") == 0)
info->list[info->count].action = DEV_ATTACH;
else if (strcmp(action, "CREATE") == 0)
info->list[info->count].action = DEV_CREATE;
else
goto out;
Would save you one strcmp() and looks a bit cleaner.
3)
info->list[info->count].node = strtol(node, NULL, 10);
Again we can't assume that input string will always be valid.
Something like that should do, I think:
char *end;
...
errno = 0;
info->list[info->count].node = strtoul(node, &end, 10);
if (errno != 0 || *end != 0) {
ret = -EINVAL;
goto out;
}
4)
strncpy(info->list[info->count].name, name, PATH_MAX);
When RTE_INSECURE_FUNCTION_WARNING is defined, strncpy() (and some other
functions) are marked as poisoned.
Another thing - as I remember, if strlen(name) >= PATH_MAX, then destination
string will not be null terminated.
So probably something like that instead:
rte_snprintf(info->list[info->count].name,
sizeof(info->list[info->count].name), "%s", name);
- rte_pmd_ring_devinit():
5)
printf("Parsing kvargs\n");
Here and everywhere - please use RTE_LOG() instead.
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Neil Horman
Sent: Tuesday, April 15, 2014 7:06 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH 05/15] ring: Convert to use of PMD_REGISTER_DRIVER
and fix linking
convert the ring driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the ring library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Note that the ring driver was also written in such a way that it violated some
general layering principles, several functions were contained in the pmd which
were being called by example from the test application in the app/test
directory. Specifically it was calling eth_ring_pair_attach,
eth_ring_pair_create and rte_eth_ring_devinit, which should only be called
internally to the dpdk core library. To correct this I've removed those
functions, and instead allowed them to be called indirectly at initalization
time using the vdev command line argument key nodeaction=::
where action is one of ATTACH or CREATE. I've tested out the functionality of
the command line with the testpmd utility, with success, and have removed the
called functions from the test utility. This will affect how the test utility
is invoked (the -d and --vdev option will need to be specified on the command
line now), but honestly, given the way it was coded, I think the testing of the
ring pmd was not the best example of how to code with dpdk to begin with. I
have also left the two layer violating functions in place, so as not to break
existing applications, but added deprecation warnings to them so that apps can
migrate off them.
Signed-off-by: Neil Horman
---
app/test/test_pmd_ring.c | 95
lib/librte_pmd_ring/Makefile | 1 +
lib/librte_pmd_ring/rte_eth_ring.c | 123 ++---
mk/rte.app.mk | 14 +++--
4 files changed, 124 insertions(+), 109 deletions(-)
diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c index
4d9c2ba..1fe38fa 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -42,7 +42,6 @@
/* two test rings, r1 is used by two ports, r2 just by one */ static struct
rte_ring *r1[2], *r2;
-static struct rte_ring *nullring = NULL; static struct rte_mempool *mp;
static uint8_t start_idx; /* will store the port id of the first of our new
ports */
@@ -59,58 +58,6 @@ static uint8_t start_idx; /* will store the port id of the
first of our new port #define MBUF_SIZE (2048 + sizeof(struct rte_mbuf) +
RTE_PKTMBUF_HEADROOM)
#define NB_MBUF 512
-
-static int
-test_ring_ethdev_create(void)
-{
- int retval;
- printf("Testing ring pmd create\n");
-
- retval = rte_eth_from_rings(NULL, 0, NULL, 0, SOCKET0);
- if (retval < 0) {
- printf("Failure, failed to create zero-sized RXTX ring pmd\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(NULL, 0, NULL, 0, RTE_MAX_NUMA_NODES);
- if (retval >= 0) {
- printf("Failure, can create ring pmd on socket %d
[dpdk-dev] [PATCH 03/15] pmd: Add PMD_REGISTER_DRIVER macro
On Thu, Apr 17, 2014 at 10:08:29AM +0200, Olivier MATZ wrote: > Hi Neil, > > On 04/16/2014 07:29 PM, Neil Horman wrote: > >Ok, so look it up. DPDK is open source and cscope is easy to use. A > >module initilization macro is a common method for doing init time binding in > >modular programming (the best examples are the module_init() and > >module_exit() > >macros in the linux kernel). It wraps up what you need to do to tie a > >modular > >piece of your software into the larger main component, without having to know > >all the boilerplate behind it. > > > >Also, if you expose the use of the constructor, then you've > >broken out the initalization phase to every pmd you implement, and as a > >result, > >if you ever need to add code to the initilization step, you have to add it in > >every pmd, instead of just updating the macro. > > > >The bottom line is, your method is 5 lines of boilerplate code thats going to > >have to get repeated as nauseum for every pmd that gets written giving every > >PMD > >author the opportunity to miscode the constructor, vs my one line that, if it > >compiles, will be correct every time. > OK, some of your arguments are legitimate and it's a detail point of > your patches that are globally a nice improvement of the DPDK code. > > But I'd be happy to continue this discussion over a beer ;) > Sure, I'll be in dusseldorf for plumbers this october I think. Perfect place for a beer :) Neil > Regards, > Olivier > >
[dpdk-dev] Calling rte_eal_init multiple times in the same process
On Thu, Apr 17, 2014 at 09:09:44AM +, Tomas Vestelind wrote: > Dear all, > > I'm not sure who to address with this email so I'll just present my problem > and my suggested solution. > > The problem I'm facing is that I need to do rte_eal_init serveral times in > the same process. The reason for this is mostly architectural as we want to > divide certain functionality in to different, implementation independent, > modules in which DPDK would be used for different purposes. Thus we would > need to eventually call rte_eal_init several times because we can't say for > sure if it has been called by another module or not. > > While thinking about it I saw no good, existing solution to this (I might > have missed it though). Would returning a "DPDK has already been initialized" > error code in rte_eal_init be a good way to go about it? I haven't done this > yet but I could probably provide a patch if it's interesting. > > Thank you for your time and a very nice framework with good documentation! > > BR, > Tomas > You already (more or less) have that. rte_eal_init panics or calls exit() if something goes wrong during initialization. If all goes well it returns 0. The only time that it returns with something else is if this code at the top of the function fails: if (!rte_atomic32_test_and_set(&run_once)) return -1; Thats there to specifically gate the init routine so it only gets called once. All your code needs to do is check the return for -1. Thats your indicator that its already been initalized. Anything >= 0 is success, and if your program crashes, thats a problem :) Neil
[dpdk-dev] [PATCH 05/15] ring: Convert to use of PMD_REGISTER_DRIVER and fix linking
On Thu, Apr 17, 2014 at 09:50:02AM +, Ananyev, Konstantin wrote:
> Hi Neil,
> Few comments from me there.
> Thanks
> Konstantin
>
> - parse_kvlist():
>
> 1)
> node = strchr(name, ':');
> ...
> action = strchr(node, ':');
>
> We can't expect that input parameter will always be valid.
> So need to check that strchr() doesn't return NULL.
>
> 2)
> if (strcmp(action, "ATTACH"))
> if (strcmp(action, "CREATE"))
>goto out;
> ...
> info->list[info->count].action = strcmp(action, "ATTACH") ? DEV_CREATE :
> DEV_ATTACH;
>
> Can you create a macros for these 2 string constants and use them instead.
> Another thing, probably better to reorder it that way:
>
> if (strcmp(action, "ATTACH") == 0)
> info->list[info->count].action = DEV_ATTACH;
> else if (strcmp(action, "CREATE") == 0)
> info->list[info->count].action = DEV_CREATE;
> else
> goto out;
>
> Would save you one strcmp() and looks a bit cleaner.
>
> 3)
> info->list[info->count].node = strtol(node, NULL, 10);
> Again we can't assume that input string will always be valid.
> Something like that should do, I think:
>
> char *end;
> ...
> errno = 0;
> info->list[info->count].node = strtoul(node, &end, 10);
> if (errno != 0 || *end != 0) {
>ret = -EINVAL;
>goto out;
> }
>
> 4)
> strncpy(info->list[info->count].name, name, PATH_MAX);
> When RTE_INSECURE_FUNCTION_WARNING is defined, strncpy() (and some other
> functions) are marked as poisoned.
> Another thing - as I remember, if strlen(name) >= PATH_MAX, then destination
> string will not be null terminated.
> So probably something like that instead:
> rte_snprintf(info->list[info->count].name,
> sizeof(info->list[info->count].name), "%s", name);
>
> - rte_pmd_ring_devinit():
>
> 5)
> printf("Parsing kvargs\n");
> Here and everywhere - please use RTE_LOG() instead.
>
>
Thank you Anayev, I'll square these all up and submit a v2 of this patch.
Neil
[dpdk-dev] [PATCH] mk: pass CROSS_COMPILE when compiling kernel modules
Hi, 2014-03-07 15:32, Aaro Koskinen: > On Tue, Feb 25, 2014 at 10:55:36PM +0100, Thomas Monjalon wrote: > > 07/02/2014 18:44, Aaro Koskinen : > > > Pass CROSS_COMPILE to the kernel build system when compiling kernel > > > modules. Although we export CC etc. the top level kernel Makefile will > > > override the environment. As a result it will end up using wrong tools > > > if cross-compilation is desired but CROSS_COMPILE is not set. > > > > > > Signed-off-by: Aaro Koskinen > > > > Could you explain why it's needed ? > > In a basic test, CC=$(CROSS)gcc in rte.vars.mk seems sufficient. > > If you compile on 32-bit host to 64-bit target, the build fails with > errors such as: > > [...]include/linux/kernfs.h:331:1: note: expected 'const char *' but > argument is of type 'const unsigned char *' kernfs_find_and_get(struct > kernfs_node *kn, const char *name) > ^ > cc1: all warnings being treated as errors > > Build with V=1 shows that following appears in the command line > when compiling the kernel modules: > > -isystem /usr/lib/gcc/i486-linux-gnu/4.8/include > > With the patch this will be corrected to point to my target's sysroot: > > -isystem /foo/bar/lib/gcc/x86_64-linux-gnu/4.8.2/include > > And the build succeeds without any warnings. Acked-by: Thomas Monjalon It's applied for version 1.6.0r2. Thanks -- Thomas
[dpdk-dev] [PATCH 1.6.1] don't inline rte_string_fns
Hi Stephen,
This patch is still pending.
Please send a v2.
2014-03-20 17:30, Thomas Monjalon:
> Hi,
>
> I have some minor comments below.
>
> 27/02/2014 09:18, Stephen Hemminger :
> > The function rte_snprintf() can never be inlined by Gcc.
> >
> > If compiled with -Winline it generates an error:
> > function ?rte_snprintf? can never be inlined because it uses variable
> >
> > argument lists [-Werror=inline]
> >
> > Therefore since both rte_snprintf and rte_strsplit are not performance
> > sensitive just move them to being real functions.
> >
> > Signed-off-by: Stephen Hemminger
> >
> > --- /dev/null
> > +++ b/lib/librte_eal/common/eal_common_string_fns.c
> > @@ -0,0 +1,95 @@
> > +/*-
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2010-2013 Intel Corporation. All rights reserved.
>
> It is now 2014 in version 1.6.0.
>
> [...]
>
> > +#include
> > +#include
> > +#include
> > +#include
>
> I think stddef.h is not needed.
>
> [...]
>
> > --- a/lib/librte_eal/common/include/rte_string_fns.h
> > +++ b/lib/librte_eal/common/include/rte_string_fns.h
> > @@ -47,7 +47,6 @@ extern "C" {
> >
> > #include
> > #include
> > #include
> >
> > -#include
>
> stdarg and stddef are not needed.
>
> [...]
>
> > +int
> > +rte_snprintf(char *buffer, int buflen, const char *format, ...);
>
> One blank line should be sufficient.
>
> > +int
> >
> > rte_strsplit(char *string, int stringlen,
>
> Thank you
[dpdk-dev] [PATCH 6/6] ivshmem: fix errors identified by hardening
2014-03-07 10:13, Stephen Hemminger: > Need to pass mode argument to open with O_CREAT. > Must check return value from ftruncate(). > > Signed-off-by: Stephen Hemminger Acked-by: Thomas Monjalon It's applied for version 1.6.0r2. Thanks -- Thomas
[dpdk-dev] RES: RES: hw.nic_uio.bdfs
Hi Fred,
2014-03-26 04:22, Fred Pedrisa:
> Here is my fix for probe code :
>
> static int
> nic_uio_probe (device_t dev)
> {
> int i, len;
> char *remaining;
> long bus = 0, device = 0, function = 0;
> remaining = bdf_str;
> len = strlen(remaining);
>
> for (i = 0; remaining && len >= 5 && i < len;i+=6) {
> if ( remaining[i + 1] == ':' && remaining[i + 3] == ':' ) {
> bus = strtol(&remaining[i + 0],NULL,0);
> device = strtol(&remaining[i + 2],NULL,0);
> function = strtol(&remaining[i + 4],NULL,0);
> if (dev != NULL) {
> if (pci_get_bus(dev) == bus &&
> pci_get_slot(dev) == device && pci_get_function(dev) == function) {
> printf("nic_uio: success blocking
> probe of : %ld:%ld:%ld!\n", bus, device, function);
> return (ENXIO);
> }
> }
> }
> }
>
> for (i = 0; i < NUM_DEVICES; i++)
> if (pci_get_vendor(dev) == devices[i].vend &&
> pci_get_device(dev) == devices[i].dev) {
>
> device_set_desc(dev, "Intel(R) DPDK PCI Device");
> return (BUS_PROBE_SPECIFIC);
> }
>
> return (ENXIO);
> }
>
> Now it is working as intended ;)
If you think a patch should be applied, please send it with git-send-email as
described in http://dpdk.org/dev#send
Thank you
--
Thomas
[dpdk-dev] rte_pktmbuf_alloc fails
Hi Konstantin, 2014-04-07 08:53, Ananyev, Konstantin: > Yep indeed, there is a bug in eth_pcap_tx() that can cause mbuf corruption. > I think it should be something like that instead: > > --- a/lib/librte_pmd_pcap/rte_eth_pcap.c > +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c > @@ -205,8 +205,9 @@ eth_pcap_tx(void *queue, > mbuf = bufs[i]; > ret = pcap_sendpacket(tx_queue->pcap, (u_char*) > mbuf->pkt.data, mbuf->pkt.data_len); > - if(likely(!ret)) > - num_tx++; > + if(unlikely(ret != 0)) > + break; > + num_tx++; > rte_pktmbuf_free(mbuf); > } Please could you send a patch with a commit log as described in http://dpdk.org/dev#send ? Thanks -- Thomas
[dpdk-dev] [PATCH 05/15 v3] ring: Convert to use of PMD_REGISTER_DRIVER and fix linking
convert the ring driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the ring library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Note that the ring driver was also written in such a way that it violated some
general layering principles, several functions were contained in the pmd which
were being called by example from the test application in the app/test
directory. Specifically it was calling eth_ring_pair_attach,
eth_ring_pair_create and rte_eth_ring_devinit, which should only be called
internally to the dpdk core library. To correct this I've removed those
functions, and instead allowed them to be called indirectly at initalization
time using the vdev command line argument key nodeaction=::
where action is one of ATTACH or CREATE. I've tested out the functionality of
the command line with the testpmd utility, with success, and have removed the
called functions from the test utility. This will affect how the test utility
is invoked (the -d and --vdev option will need to be specified on the command
line now), but honestly, given the way it was coded, I think the testing of the
ring pmd was not the best example of how to code with dpdk to begin with. I
have also left the two layer violating functions in place, so as not to break
existing applications, but added deprecation warnings to them so that apps can
migrate off them.
Signed-off-by: Neil Horman
---
Change notes
v2) fixed DEPDIR specifcation, should depend on RING not PCAP
v3) Cleaned up strcmp error checking, printfs, and other parsing issues as
pointed out by Konstantin Ananyev
---
app/test/test_pmd_ring.c | 95 -
lib/librte_pmd_ring/Makefile | 1 +
lib/librte_pmd_ring/rte_eth_ring.c | 141 ++---
mk/rte.app.mk | 14 ++--
4 files changed, 142 insertions(+), 109 deletions(-)
diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c
index 4d9c2ba..1fe38fa 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -42,7 +42,6 @@
/* two test rings, r1 is used by two ports, r2 just by one */
static struct rte_ring *r1[2], *r2;
-static struct rte_ring *nullring = NULL;
static struct rte_mempool *mp;
static uint8_t start_idx; /* will store the port id of the first of our new
ports */
@@ -59,58 +58,6 @@ static uint8_t start_idx; /* will store the port id of the
first of our new port
#define MBUF_SIZE (2048 + sizeof(struct rte_mbuf) + RTE_PKTMBUF_HEADROOM)
#define NB_MBUF 512
-
-static int
-test_ring_ethdev_create(void)
-{
- int retval;
- printf("Testing ring pmd create\n");
-
- retval = rte_eth_from_rings(NULL, 0, NULL, 0, SOCKET0);
- if (retval < 0) {
- printf("Failure, failed to create zero-sized RXTX ring pmd\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(NULL, 0, NULL, 0, RTE_MAX_NUMA_NODES);
- if (retval >= 0) {
- printf("Failure, can create ring pmd on socket %d\n",
RTE_MAX_NUMA_NODES);
- return -1;
- }
-
- retval = rte_eth_from_rings(NULL, 1, &r2, 1, SOCKET0);
- if (retval >= 0) {
- printf("Failure, can create pmd with null rx rings\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(r1, 1, NULL, 1, SOCKET0);
- if (retval >= 0) {
- printf("Failure, can create pmd with null tx rings\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(&nullring, 1, r1, 2, SOCKET0);
- if (retval < 0) {
- printf("Failure, failed to create TX-only ring pmd\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(r1, 1, &nullring, 1, SOCKET0);
- if (retval < 0) {
- printf("Failure, failed to create RX-only ring pmd\n");
- return -1;
- }
-
- retval = rte_eth_from_rings(&r2, 1, &r2, 1, SOCKET0);
- if (retval < 0) {
- printf("Failure, failed to create RXTX ring pmd\n");
- return -1;
- }
-
- return 0;
-}
-
static int
test_ethdev_configure(void)
{
@@ -305,26 +252,12 @@ test_stats_reset(void)
static int
test_pmd_ring_init(void)
{
- const char * name1 = "R3";
- const char * name2 = "R4";
- const char * params_null = NULL;
- const char * params = "PARAMS";
struct rte_eth_stats stats;
struct rte_mbuf buf, *pbuf = &buf;
struct rte_eth_conf null_conf;
printf("Testing ring pmd init\n");
- if (rte_pmd_ring_devinit(name1, params_null) < 0) {
- printf("Testing ring pmd init fail\n");
- return -1;
- }
-
- if (rte_pmd_ring_devinit(name2, params) < 0
[dpdk-dev] [PATCH] kni: fix build with kernel 3.15
2014-04-14 16:50, Aaro Koskinen: > rxhash has been renamed to hash. In 3.14 and newer, we can use > skb_set_hash(). > > Signed-off-by: Aaro Koskinen Acked-by: Thomas Monjalon It's applied for version 1.6.0r2. Thanks -- Thomas
[dpdk-dev] [PATCH] eal: parse args before any kinds of init
Hi,
2014-04-15 11:03, Wang Sheng-Hui:
> Parse args first, to resolve any invalid args and give out the usage string.
> E.g './helloworld --invalid', the '--invalid' will be checked before any
> init. After the options are checked, take any init actions.
>
> Signed-off-by: Wang Sheng-Hui
[...]
> + fctret = eal_parse_args(argc, argv);
> + if (fctret < 0)
> + exit(1);
> +
> if (rte_eal_log_early_init() < 0)
> rte_panic("Cannot init early logs\n");
>
> if (rte_eal_cpu_init() < 0)
> rte_panic("Cannot detect lcores\n");
>
> - fctret = eal_parse_args(argc, argv);
> - if (fctret < 0)
> - exit(1);
> -
Thank you for trying to improve this part.
I think you cannot move eal_parse_args before rte_eal_log_early_init because
eal_parse_args uses RTE_LOG.
I cannot see why rte_eal_cpu_init is call before argument parsing but we
should double check it.
--
Thomas
