[dpdk-dev] perfomance of rte_lpm rule subsystem
Hi Alexander, Why next_hop is 64 bit long? 2016-04-19 18:46 GMT+03:00 Stephen Hemminger : > On Tue, 19 Apr 2016 14:11:11 +0300 > ? ??? wrote: > > > Hi. > > > > Doing some test with rte_lpm (adding/deleting bgp full table rules) I > > noticed that > > rule subsystem is very slow even considering that probably it was never > > designed for using > > in a data forwarding plane. So I want to propose some changes to the > "rule" > > subsystem. > > > > I reimplemented rule part ot the lib using rte_hash, and perfomance of > > adding/deleted routes have increased dramatically. > > If increasing speed of adding deleting routes makes sence for anybody > else > > I would like to discuss my patch. > > The patch also include changes that make next_hop 64 bit, so please just > > ignore them. The rule changes are in the following > > functions only: > > > > rte_lpm2_create > > > > rule_find > > rule_add > > rule_delete > > find_previous_rule > > delete_depth_small > > delete_depth_big > > > > rte_lpm2_add > > rte_lpm2_delete > > rte_lpm2_is_rule_present > > rte_lpm2_delete_all > > > > We forked LPM back several versions ago. > I sent the patches to use BSD red-black tree for rules but the patches were > ignored. mostly because it broke ABI. > -- Regards, Vladimir
[dpdk-dev] [PATCH] eal: remove useless internal function from memcpy headers
The function rte_memcpy_func() is used in ARM and PPC implementations
of rte_memcpy().
There are some useless copies in Tile and some ARM branches.
It was also declared without doxygen comment in the generic header.
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 6 --
lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h | 6 --
lib/librte_eal/common/include/arch/tile/rte_memcpy.h | 6 --
lib/librte_eal/common/include/generic/rte_memcpy.h | 7 ---
4 files changed, 25 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
index 988125b..da6c233 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
@@ -323,12 +323,6 @@ rte_memcpy(void *dst, const void *src, size_t n)
return memcpy(dst, src, n);
}
-static inline void *
-rte_memcpy_func(void *dst, const void *src, size_t n)
-{
- return memcpy(dst, src, n);
-}
-
#endif /* RTE_ARCH_ARM_NEON_MEMCPY */
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
index 917cdc1..5db66b6 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_64.h
@@ -80,12 +80,6 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
#define rte_memcpy(d, s, n)memcpy((d), (s), (n))
-static inline void *
-rte_memcpy_func(void *dst, const void *src, size_t n)
-{
- return memcpy(dst, src, n);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/tile/rte_memcpy.h
b/lib/librte_eal/common/include/arch/tile/rte_memcpy.h
index 9b5b37e..e606957 100644
--- a/lib/librte_eal/common/include/arch/tile/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/tile/rte_memcpy.h
@@ -80,12 +80,6 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
#define rte_memcpy(d, s, n)memcpy((d), (s), (n))
-static inline void *
-rte_memcpy_func(void *dst, const void *src, size_t n)
-{
- return memcpy(dst, src, n);
-}
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/generic/rte_memcpy.h
b/lib/librte_eal/common/include/generic/rte_memcpy.h
index 03e8477..afb0afe 100644
--- a/lib/librte_eal/common/include/generic/rte_memcpy.h
+++ b/lib/librte_eal/common/include/generic/rte_memcpy.h
@@ -134,11 +134,4 @@ rte_memcpy(void *dst, const void *src, size_t n);
#endif /* __DOXYGEN__ */
-/*
- * memcpy() function used by rte_memcpy macro
- */
-static inline void *
-rte_memcpy_func(void *dst, const void *src, size_t n)
__attribute__((always_inline));
-
-
#endif /* _RTE_MEMCPY_H_ */
--
2.7.0
[dpdk-dev] [PATCH] remove poisoned flags
Some flags were poisoned after having been removed from EAL and mbuf
in releases 1.8 (b10eef348d, 62814bc2e9) and 2.0 (4769bc5a27cc).
After several releases, they have probably disappeared from the applications.
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/common/include/rte_pci.h | 2 --
lib/librte_mbuf/rte_mbuf.h | 4
2 files changed, 6 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 9f2301d..8fa2712 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -213,8 +213,6 @@ struct rte_pci_driver {
/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */
#define RTE_PCI_DRV_NEED_MAPPING 0x0001
-/** Device driver must be registered several times until failure - deprecated
*/
-#pragma GCC poison RTE_PCI_DRV_MULTIPLE
/** Device needs to be unbound even if no module is provided */
#define RTE_PCI_DRV_FORCE_UNBIND 0x0004
/** Device driver supports link state interrupt */
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 75a227d..451921f 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -65,10 +65,6 @@
extern "C" {
#endif
-/* deprecated options */
-#pragma GCC poison RTE_MBUF_SCATTER_GATHER
-#pragma GCC poison RTE_MBUF_REFCNT
-
/*
* Packet Offload Features Flags. It also carry packet type information.
* Critical resources. Both rx/tx shared these bits. Be cautious on any change
--
2.7.0
[dpdk-dev] Memory leak when adding/removing vhost_user ports
On Tue, Apr 19, 2016 at 06:33:50PM +0200, Christian Ehrhardt wrote:
> Hi,
> thanks for the patch.
> I backported it this way to my DPDK 2.2 based environment for now (see below):
>
> With that applied one (and only one) of my two guests looses connectivity
> after
> removing the ports the first time.
Yeah, that's should be because I invoked the "->destroy_device()"
callback.
BTW, I'm curious how do you do the test? I saw you added 256 ports, but
with 2 guests only? So, 254 of them are idle, just for testing the
memory leak bug?
And then you remove all of them, without stopping the guest. How that's
gonna work? I mean, the vhost-user connection would be broken, and data
flow would not work.
--yliu
> No traffic seems to pass, setting the device in the guest down/up doesn't get
> anything.
> But It isn't totally broken - stopping/starting the guest gets it working
> again.
> So openvswitch/dpdk is still somewhat working - it just seems the guest lost
> something, after tapping on that vhost_user interface again it works.
>
> I will check tomorrow and let you know:
> - if I'm more lucky with that patch on top of 16.04
> - if it looses connectivity after the first or a certain amount of port
> removes
>
> If you find issues with my backport adaption let me know.
>
>
> ---
>
> Backport and reasoning:
>
> new fix relies on a lot of new code, vhost_destroy_device looks totally
> different from the former destroy_device.
> History on todays function content:
> ? 4796ad63 - original code moved from examples to lib
> ? a90ca1a1 - this replaces ops->destroy_device with vhost_destroy_device
> ? 71dc571e - simple check against null pointers
> ? 45ca9c6f - this changed the code from linked list to arrays
>
> ? New code cleans with:
> ? ? ? notify_ops->destroy_device (callback into the parent)
> ? ? ? cleanup_device was existing before even in 2.2 code
> ? ? ? free_device as well existing before even in 2.2 code
> ? Old code cleans with:
> ? ? ? notify_ops->destroy_device - still there
> ? ? ? rm_config_ll_entry -> eventually calls cleanup_device and free_device
> ? ? ? ? (just in the more complex linked list way)
>
> So the "only" adaption for backporting needed is to replace
> vhost_destroy_device
> with ops->destroy_device(ctx)
>
> Index: dpdk/lib/librte_vhost/vhost_user/vhost-net-user.c
> ===
> --- dpdk.orig/lib/librte_vhost/vhost_user/vhost-net-user.c
> +++ dpdk/lib/librte_vhost/vhost_user/vhost-net-user.c
> @@ -310,6 +310,7 @@ vserver_new_vq_conn(int fd, void *dat, _
> ? }
> ?
> ? vdev_ctx.fh = fh;
> + vserver->fh = fh;
> ? size = strnlen(vserver->path, PATH_MAX);
> ? ops->set_ifname(vdev_ctx, vserver->path,
> ? size);
> @@ -516,6 +517,11 @@ rte_vhost_driver_unregister(const char *
> ?
> ? for (i = 0; i < g_vhost_server.vserver_cnt; i++) {
> ? if (!strcmp(g_vhost_server.server[i]->path, path)) {
> + struct vhost_device_ctx ctx;
> +
> + ctx.fh = g_vhost_server.server[i]->fh;
> + ops->destroy_device(ctx);
> +
> ? fdset_del(&g_vhost_server.fdset,
> ? g_vhost_server.server[i]->listenfd);
> ?
> Index: dpdk/lib/librte_vhost/vhost_user/vhost-net-user.h
> ===
> --- dpdk.orig/lib/librte_vhost/vhost_user/vhost-net-user.h
> +++ dpdk/lib/librte_vhost/vhost_user/vhost-net-user.h
> @@ -43,6 +43,7 @@
> ?struct vhost_server {
> ? char *path; /**< The path the uds is bind to. */
> ? int listenfd; ? ? /**< The listener sockfd. */
> + uint32_t fh;
> ?};
> ?
> ?/* refer to hw/virtio/vhost-user.c */
>
>
>
>
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>
> On Mon, Apr 18, 2016 at 8:14 PM, Yuanhan Liu
> wrote:
>
> On Mon, Apr 18, 2016 at 10:46:50AM -0700, Yuanhan Liu wrote:
> > On Mon, Apr 18, 2016 at 07:18:05PM +0200, Christian Ehrhardt wrote:
> > > I assume there is a leak somewhere on adding/removing vhost_user
> ports.
> > > Although it could also be "only" a fragmentation issue.
> > >
> > > Reproduction is easy:
> > > I set up a pair of nicely working OVS-DPDK connected KVM Guests.
> > > Then in a loop I
> > >? ? - add up to more 512 ports
> > >? ? - test connectivity between the two guests
> > >? ? - remove up to 512 ports
> > >
> > > Depending on memory and the amount of multiqueue/rxq I use it seems to
> > > slightly change when exactly it breaks. But for my default setup of 4
> > > queues and 5G Hugepages initialized by DPDK it always breaks at the
> sixth
> > > iteration.
> > > Here a link to the stack trace indicating a memory shortage (TBC):
> > > https://launchpadlibrarian.net/253916410/apport-retrace.log
> > >
> > > Known Todos:
> > > - I want to track it down more, and will try to come up with a non
> > > openvswitch based looping testcase that might show it as well to
> simplify
> > > debugging.
> > > - in use were Openvswitch-dpdk 2.5
[dpdk-dev] [PATCH] hash: remove aliases for bulk lookup
The function rte_hash_lookup_multi() was renamed rte_hash_lookup_bulk()
in DPDK 1.4 and was kept as an undocumented alias.
Signed-off-by: Thomas Monjalon
---
app/test/test_hash.c| 4 ++--
doc/guides/sample_app_ug/l3_forward.rst | 2 +-
examples/l3fwd/l3fwd_em_hlm_sse.h | 4 ++--
examples/performance-thread/l3fwd-thread/main.c | 4 ++--
lib/librte_hash/rte_hash.h | 2 --
5 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/app/test/test_hash.c b/app/test/test_hash.c
index adbdb4a..61fc0a0 100644
--- a/app/test/test_hash.c
+++ b/app/test/test_hash.c
@@ -486,7 +486,7 @@ static int test_five_keys(void)
for(i = 0; i < 5; i++)
key_array[i] = &keys[i];
- ret = rte_hash_lookup_multi(handle, &key_array[0], 5, (int32_t *)pos);
+ ret = rte_hash_lookup_bulk(handle, &key_array[0], 5, (int32_t *)pos);
if(ret == 0)
for(i = 0; i < 5; i++) {
print_key_info("Lkp", key_array[i], pos[i]);
@@ -527,7 +527,7 @@ static int test_five_keys(void)
}
/* Lookup multi */
- ret = rte_hash_lookup_multi(handle, &key_array[0], 5, (int32_t *)pos);
+ ret = rte_hash_lookup_bulk(handle, &key_array[0], 5, (int32_t *)pos);
if (ret == 0)
for (i = 0; i < 5; i++) {
print_key_info("Lkp", key_array[i], pos[i]);
diff --git a/doc/guides/sample_app_ug/l3_forward.rst
b/doc/guides/sample_app_ug/l3_forward.rst
index 3e070d0..491f99d 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -324,7 +324,7 @@ The key code snippet of simple_ipv4_fwd_4pkts() is shown
below:
const void *key_array[4] = {&key[0], &key[1], &key[2],&key[3]};
-rte_hash_lookup_multi(qconf->ipv4_lookup_struct, &key_array[0], 4,
ret);
+rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 4, ret);
dst_port[0] = (ret[0] < 0)? portid:ipv4_l3fwd_out_if[ret[0]];
dst_port[1] = (ret[1] < 0)? portid:ipv4_l3fwd_out_if[ret[1]];
diff --git a/examples/l3fwd/l3fwd_em_hlm_sse.h
b/examples/l3fwd/l3fwd_em_hlm_sse.h
index 5001c72..7714a20 100644
--- a/examples/l3fwd/l3fwd_em_hlm_sse.h
+++ b/examples/l3fwd/l3fwd_em_hlm_sse.h
@@ -81,7 +81,7 @@ em_get_dst_port_ipv4x8(struct lcore_conf *qconf, struct
rte_mbuf *m[8],
const void *key_array[8] = {&key[0], &key[1], &key[2], &key[3],
&key[4], &key[5], &key[6], &key[7]};
- rte_hash_lookup_multi(qconf->ipv4_lookup_struct, &key_array[0], 8, ret);
+ rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 8, ret);
dst_port[0] = (uint8_t) ((ret[0] < 0) ?
portid : ipv4_l3fwd_out_if[ret[0]]);
@@ -179,7 +179,7 @@ em_get_dst_port_ipv6x8(struct lcore_conf *qconf, struct
rte_mbuf *m[8],
const void *key_array[8] = {&key[0], &key[1], &key[2], &key[3],
&key[4], &key[5], &key[6], &key[7]};
- rte_hash_lookup_multi(qconf->ipv6_lookup_struct, &key_array[0], 8, ret);
+ rte_hash_lookup_bulk(qconf->ipv6_lookup_struct, &key_array[0], 8, ret);
dst_port[0] = (uint8_t) ((ret[0] < 0) ?
portid : ipv6_l3fwd_out_if[ret[0]]);
diff --git a/examples/performance-thread/l3fwd-thread/main.c
b/examples/performance-thread/l3fwd-thread/main.c
index 15c0a4d..cb9a82e 100644
--- a/examples/performance-thread/l3fwd-thread/main.c
+++ b/examples/performance-thread/l3fwd-thread/main.c
@@ -996,7 +996,7 @@ simple_ipv4_fwd_8pkts(struct rte_mbuf *m[8], uint8_t portid)
const void *key_array[8] = {&key[0], &key[1], &key[2], &key[3],
&key[4], &key[5], &key[6], &key[7]};
- rte_hash_lookup_multi(RTE_PER_LCORE(lcore_conf)->ipv4_lookup_struct,
+ rte_hash_lookup_bulk(RTE_PER_LCORE(lcore_conf)->ipv4_lookup_struct,
&key_array[0], 8, ret);
dst_port[0] = (uint8_t) ((ret[0] < 0) ? portid :
ipv4_l3fwd_out_if[ret[0]]);
dst_port[1] = (uint8_t) ((ret[1] < 0) ? portid :
ipv4_l3fwd_out_if[ret[1]]);
@@ -1150,7 +1150,7 @@ simple_ipv6_fwd_8pkts(struct rte_mbuf *m[8], uint8_t
portid)
const void *key_array[8] = {&key[0], &key[1], &key[2], &key[3],
&key[4], &key[5], &key[6], &key[7]};
- rte_hash_lookup_multi(RTE_PER_LCORE(lcore_conf)->ipv6_lookup_struct,
+ rte_hash_lookup_bulk(RTE_PER_LCORE(lcore_conf)->ipv6_lookup_struct,
&key_array[0], 4, ret);
dst_port[0] = (uint8_t) ((ret[0] < 0) ? portid :
ipv6_l3fwd_out_if[ret[0]]);
dst_port[1] = (uint8_t) ((ret[1] < 0) ? portid :
ipv6_l3fwd_out_if[ret[1]]);
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index ae00b65..724315a 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -362,8 +362,6 @@ rte_hash_lookup_with_hash(const struct rte_hash *h,
hash_sig_t
rte_hash
[dpdk-dev] basic forwarding example not working
I am using two virtio network adapter on VM on KVM host. As in following output, I have bound both interface with igb_uio driver ./dpdk_nic_bind.py --bind=igb_uio 00:0a.0 ./dpdk_nic_bind.py --bind=igb_uio 00:0b.0 [root at localhost tools]# ./dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :00:0a.0 'Virtio network device' drv=igb_uio unused= :00:0b.0 'Virtio network device' drv=igb_uio unused= Network devices using kernel driver === :00:03.0 'RTL-8100/8101L/8139 PCI Fast Ethernet Adapter' if=ens3 drv=8139cp unused=igb_uio *Active* :00:08.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio :00:09.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio Other network devices = But when I run basic fowarding example from skeleton, I get following error ./basicfwd -c 1 -n 2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 1 lcore(s) EAL: Probing VFIO support... EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or directory) EAL: VFIO modules not loaded, skipping VFIO support... EAL: Setting up physically contiguous memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75de40 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75de00 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75ddc0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75dd80 (size = 0x20) EAL: Ask a virtual area of 0x2740 bytes EAL: Virtual area found at 0x7f75b620 (size = 0x2740) EAL: Ask a virtual area of 0x4a0 bytes EAL: Virtual area found at 0x7f75b160 (size = 0x4a0) EAL: Ask a virtual area of 0x120 bytes EAL: Virtual area found at 0x7f75b020 (size = 0x120) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75afe0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75afa0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75af60 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75af20 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75aee0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f75aea0 (size = 0x20) EAL: Requesting 370 pages of size 2MB from socket 0 EAL: TSC frequency is ~1696081 KHz EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! EAL: Master lcore 0 is ready (tid=df5298c0;cpuset=[0]) EAL: PCI device :00:08.0 on NUMA socket -1 EAL: probe driver: 1af4:1000 rte_virtio_pmd EAL: Not managed by a supported kernel driver, skipped Segmentation fault Please let me know what is the correct method to run the basic forwarding application.
[dpdk-dev] [PATCH v2 1/2] mempool: allow for user-owned mempool caches
Hi Konstantin,
Thanks for the review.
Regards,
Lazaros.
On Mon, Apr 18, 2016 at 4:17 PM, Ananyev, Konstantin
wrote:
> Hi Lazaros,
>
> Looks ok to me in general, few comments below.
> One more generic question - did you observe any performance impact
> caused by these changes?
> Konstantin
I didn't observe any notable difference to the default per-lcore cache
case. Here is an excerpt from the mempool_perf test:
$ egrep '(^start|n_get_bulk=32 n_put_bulk=32 n_keep=128)'
x86_64-native-linuxapp-gcc.log
start performance test (without cache)
mempool_autotest cache=0 cores=1 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=714958438
mempool_autotest cache=0 cores=2 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=795738111
mempool_autotest cache=0 cores=4 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=313655295
start performance test (with cache)
mempool_autotest cache=512 cores=1 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=780455116
mempool_autotest cache=512 cores=2 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=1046937599
mempool_autotest cache=512 cores=4 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=1988362238
start performance test (with user-owned cache)
mempool_autotest cache=512 cores=1 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=787519897
mempool_autotest cache=512 cores=2 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=1047029350
mempool_autotest cache=512 cores=4 n_get_bulk=32 n_put_bulk=32
n_keep=128 rate_persec=1965896498
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lazaros Koromilas
>> Sent: Monday, April 04, 2016 4:43 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH v2 1/2] mempool: allow for user-owned mempool
>> caches
>>
>> The mempool cache is only available to EAL threads as a per-lcore
>> resource. Change this so that the user can create and provide their own
>> cache on mempool get and put operations. This works with non-EAL threads
>> too. This commit introduces the new API calls:
>>
>> rte_mempool_cache_create(size, socket_id)
>> rte_mempool_cache_flush(cache, mp)
>> rte_mempool_cache_free(cache)
>> rte_mempool_default_cache(mp, lcore_id)
>> rte_mempool_generic_put(mp, obj_table, n, cache, is_mp)
>> rte_mempool_generic_get(mp, obj_table, n, cache, is_mc)
>>
>> Removes the API calls:
>>
>> rte_mempool_sp_put_bulk(mp, obj_table, n)
>> rte_mempool_sc_get_bulk(mp, obj_table, n)
>> rte_mempool_sp_put(mp, obj)
>> rte_mempool_sc_get(mp, obj)
>
>
> Hmm, shouldn't we deprecate it first for a release before removing completely?
> Let say for now you can just make them macros that calls the remaining
> functions or so.
How do we mark the calls as deprecated? The librte_compat stuff don't
apply here as we don't have a different version of the same symbol or
something. Do I need to put them as a notice?
>
>>
>> And the remaining API calls use the per-lcore default local cache:
>>
>> rte_mempool_put_bulk(mp, obj_table, n)
>> rte_mempool_get_bulk(mp, obj_table, n)
>> rte_mempool_put(mp, obj)
>> rte_mempool_get(mp, obj)
>>
>> Signed-off-by: Lazaros Koromilas
>> ---
>> app/test/test_mempool.c| 58 +--
>> app/test/test_mempool_perf.c | 46 +-
>> lib/librte_eal/common/eal_common_log.c | 8 +-
>> lib/librte_mempool/rte_mempool.c | 76 -
>> lib/librte_mempool/rte_mempool.h | 291
>> +
>> 5 files changed, 275 insertions(+), 204 deletions(-)
>>
>>
>> diff --git a/lib/librte_mempool/rte_mempool.c
>> b/lib/librte_mempool/rte_mempool.c
>> index 73ca770..4d977c1 100644
>> --- a/lib/librte_mempool/rte_mempool.c
>> +++ b/lib/librte_mempool/rte_mempool.c
>> @@ -375,6 +375,63 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num,
>> size_t elt_sz,
>> return usz;
>> }
>>
>> +static void
>> +mempool_cache_init(struct rte_mempool_cache *cache, uint32_t size)
>> +{
>> + cache->size = size;
>> + cache->flushthresh = CALC_CACHE_FLUSHTHRESH(size);
>> + cache->len = 0;
>> +}
>> +
>> +/*
>> + * Create and initialize a cache for objects that are retrieved from and
>> + * returned to an underlying mempool. This structure is identical to the
>> + * local_cache[lcore_id] pointed to by the mempool structure.
>> + */
>> +struct rte_mempool_cache *
>> +rte_mempool_cache_create(uint32_t size, int socket_id)
>> +{
>> + struct rte_mempool_cache *cache;
>> +
>> + if (size > RTE_MEMPOOL_CACHE_MAX_SIZE) {
>> + rte_errno = EINVAL;
>> + return NULL;
>> + }
>> +
>> + cache = rte_zmalloc_socket("MEMPOOL_CACHE", sizeof(*cache),
>> +RTE_CACHE_LINE_SIZE, socket_id);
>> + if (cache == NULL) {
>> + RTE_LOG(ERR, MEMPOOL, "Cannot allocate mempool cache!\n");
>> + rte_errno = ENOMEM;
>> + return NULL;
>> + }
>> +
>> + mempool_cache_init(cache, size);
>> +
>> + retur
[dpdk-dev] Memory leak when adding/removing vhost_user ports
Hi,
thanks for the patch.
I backported it this way to my DPDK 2.2 based environment for now (see
below):
With that applied one (and only one) of my two guests looses connectivity
after removing the ports the first time.
No traffic seems to pass, setting the device in the guest down/up doesn't
get anything.
But It isn't totally broken - stopping/starting the guest gets it working
again.
So openvswitch/dpdk is still somewhat working - it just seems the guest
lost something, after tapping on that vhost_user interface again it works.
I will check tomorrow and let you know:
- if I'm more lucky with that patch on top of 16.04
- if it looses connectivity after the first or a certain amount of port
removes
If you find issues with my backport adaption let me know.
---
Backport and reasoning:
new fix relies on a lot of new code, vhost_destroy_device looks totally
different from the former destroy_device.
History on todays function content:
4796ad63 - original code moved from examples to lib
a90ca1a1 - this replaces ops->destroy_device with vhost_destroy_device
71dc571e - simple check against null pointers
45ca9c6f - this changed the code from linked list to arrays
New code cleans with:
notify_ops->destroy_device (callback into the parent)
cleanup_device was existing before even in 2.2 code
free_device as well existing before even in 2.2 code
Old code cleans with:
notify_ops->destroy_device - still there
rm_config_ll_entry -> eventually calls cleanup_device and free_device
(just in the more complex linked list way)
So the "only" adaption for backporting needed is to replace
vhost_destroy_device
with ops->destroy_device(ctx)
Index: dpdk/lib/librte_vhost/vhost_user/vhost-net-user.c
===
--- dpdk.orig/lib/librte_vhost/vhost_user/vhost-net-user.c
+++ dpdk/lib/librte_vhost/vhost_user/vhost-net-user.c
@@ -310,6 +310,7 @@ vserver_new_vq_conn(int fd, void *dat, _
}
vdev_ctx.fh = fh;
+ vserver->fh = fh;
size = strnlen(vserver->path, PATH_MAX);
ops->set_ifname(vdev_ctx, vserver->path,
size);
@@ -516,6 +517,11 @@ rte_vhost_driver_unregister(const char *
for (i = 0; i < g_vhost_server.vserver_cnt; i++) {
if (!strcmp(g_vhost_server.server[i]->path, path)) {
+ struct vhost_device_ctx ctx;
+
+ ctx.fh = g_vhost_server.server[i]->fh;
+ ops->destroy_device(ctx);
+
fdset_del(&g_vhost_server.fdset,
g_vhost_server.server[i]->listenfd);
Index: dpdk/lib/librte_vhost/vhost_user/vhost-net-user.h
===
--- dpdk.orig/lib/librte_vhost/vhost_user/vhost-net-user.h
+++ dpdk/lib/librte_vhost/vhost_user/vhost-net-user.h
@@ -43,6 +43,7 @@
struct vhost_server {
char *path; /**< The path the uds is bind to. */
int listenfd; /**< The listener sockfd. */
+ uint32_t fh;
};
/* refer to hw/virtio/vhost-user.c */
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
On Mon, Apr 18, 2016 at 8:14 PM, Yuanhan Liu
wrote:
> On Mon, Apr 18, 2016 at 10:46:50AM -0700, Yuanhan Liu wrote:
> > On Mon, Apr 18, 2016 at 07:18:05PM +0200, Christian Ehrhardt wrote:
> > > I assume there is a leak somewhere on adding/removing vhost_user ports.
> > > Although it could also be "only" a fragmentation issue.
> > >
> > > Reproduction is easy:
> > > I set up a pair of nicely working OVS-DPDK connected KVM Guests.
> > > Then in a loop I
> > >- add up to more 512 ports
> > >- test connectivity between the two guests
> > >- remove up to 512 ports
> > >
> > > Depending on memory and the amount of multiqueue/rxq I use it seems to
> > > slightly change when exactly it breaks. But for my default setup of 4
> > > queues and 5G Hugepages initialized by DPDK it always breaks at the
> sixth
> > > iteration.
> > > Here a link to the stack trace indicating a memory shortage (TBC):
> > > https://launchpadlibrarian.net/253916410/apport-retrace.log
> > >
> > > Known Todos:
> > > - I want to track it down more, and will try to come up with a non
> > > openvswitch based looping testcase that might show it as well to
> simplify
> > > debugging.
> > > - in use were Openvswitch-dpdk 2.5 and DPDK 2.2; Retest with DPDK
> 16.04 and
> > > Openvswitch master is planned.
> > >
> > > I will go on debugging this and let you know, but I wanted to give a
> heads
> > > up to everyone.
> >
> > Thanks for the report.
> >
> > > In case this is a known issue for some of you please let me know.
> >
> > Yeah, it might be. I'm wondering that virtio_net struct is not freed.
> > It will be freed only (if I'm not mistaken) when guest quits, by far.
>
> Would you try following diff and to see if it fix your issue?
>
> --yliu
>
> ---
> lib/librte_vhost/vhost_user/vhost-net-user.c | 6 ++
> lib/librte_vhost/vhost_user/vhost-net-user.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/lib/librte_vhost/vhost_user/vhost-net-user.c
> b/lib/librte_vhost/vhost_user/
[dpdk-dev] [PATCH 1/1] lib/librte_eal: fix resource leak
Fix issue reported by Coverity.
Coverity ID 13295, 13296, 13303:
Resource leak: The system resource will not be reclaimed
and reused, reducing the future availability of the resource.
In rte_eal_hugepage_attach: Leak of memory or pointers to system
resources.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Marcin Kerlin
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5b9132c..6320aa0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1475,13 +1475,17 @@ rte_eal_hugepage_attach(void)
"and retry running both primary "
"and secondary processes\n");
}
+
+ if (base_addr != MAP_FAILED)
+ munmap((void *)(uintptr_t)base_addr,
mcfg->memseg[s].len);
+
goto error;
}
}
size = getFileSize(fd_hugepage);
hp = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd_hugepage, 0);
- if (hp == NULL) {
+ if (hp == MAP_FAILED) {
RTE_LOG(ERR, EAL, "Could not mmap %s\n",
eal_hugepage_info_path());
goto error;
}
@@ -1535,6 +1539,10 @@ rte_eal_hugepage_attach(void)
addr != RTE_PTR_ADD(base_addr,
offset)) {
RTE_LOG(ERR, EAL, "Could not mmap %s\n",
hp[i].filepath);
+
+ if (addr != MAP_FAILED)
+ munmap((void *)(uintptr_t)addr,
mapping_size);
+
goto error;
}
offset+=mapping_size;
@@ -1551,6 +1559,8 @@ rte_eal_hugepage_attach(void)
return 0;
error:
+ if (hp != NULL && hp != MAP_FAILED)
+ munmap((void *) (uintptr_t) hp, size);
if (fd_zero >= 0)
close(fd_zero);
if (fd_hugepage >= 0)
--
1.9.1
[dpdk-dev] lpm rule subsystem's perfomance
Hi.
Doing some tests with rte_lpm (adding/deleting bgp full table rules) I
noticed that
rule subsystem is very slow even considering that probably it was never
designed for using
in a data forwarding plane. So I want to propose some changes to it.
I reimplemented "rule" part ot the lib using rte_hash, and perfomance of
adding/deleted routes have increased dramatically.
If increasing speed of adding deleting routes makes sence for anybody else
I would like to discuss my patch.
The patch also include changes that make next_hop 64 bit, so please just
ignore them. The rule changes are in the following
functions only:
rte_lpm2_create
rule_find
rule_add
rule_delete
find_previous_rule
delete_depth_small
delete_depth_big
rte_lpm2_add
rte_lpm2_delete
rte_lpm2_is_rule_present
rte_lpm2_delete_all
P.S. the patch was made for 2.2.0 version.
P.P.S. Would it be more convinient to include full source file instead of
patch?
Alex Kiselev.
Patch
--- ./rte_lpm.c 2016-04-19 13:58:44.670649240 +0300
+++ ./rte_lpm2.c 2016-04-19 13:58:44.686649240 +0300
@@ -45,6 +45,9 @@
#include /* for definition of RTE_CACHE_LINE_SIZE */
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -53,14 +56,14 @@
#include
#include
-#include "rte_lpm.h"
+#include "rte_lpm2.h"
-TAILQ_HEAD(rte_lpm_list, rte_tailq_entry);
+TAILQ_HEAD(RTE_LPM2_list, rte_tailq_entry);
-static struct rte_tailq_elem rte_lpm_tailq = {
- .name = "RTE_LPM",
+static struct rte_tailq_elem RTE_LPM2_tailq = {
+ .name = "RTE_LPM2",
};
-EAL_REGISTER_TAILQ(rte_lpm_tailq)
+EAL_REGISTER_TAILQ(RTE_LPM2_tailq)
#define MAX_DEPTH_TBL24 24
@@ -70,10 +73,10 @@
};
/* Macro to enable/disable run-time checks. */
-#if defined(RTE_LIBRTE_LPM_DEBUG)
+#if defined(RTE_LIBRTE_LPM2_DEBUG)
#include
#define VERIFY_DEPTH(depth) do {\
- if ((depth == 0) || (depth > RTE_LPM_MAX_DEPTH))\
+ if ((depth == 0) || (depth > RTE_LPM2_MAX_DEPTH))\
rte_panic("LPM: Invalid depth (%u) at line %d", \
(unsigned)(depth), __LINE__); \
} while (0)
@@ -113,25 +116,25 @@
return 1 << (MAX_DEPTH_TBL24 - depth);
/* Else if depth is greater than 24 */
- return (1 << (RTE_LPM_MAX_DEPTH - depth));
+ return (1 << (RTE_LPM2_MAX_DEPTH - depth));
}
/*
* Find an existing lpm table and return a pointer to it.
*/
-struct rte_lpm *
-rte_lpm_find_existing(const char *name)
+struct rte_lpm2 *
+rte_lpm2_find_existing(const char *name)
{
- struct rte_lpm *l = NULL;
+ struct rte_lpm2 *l = NULL;
struct rte_tailq_entry *te;
- struct rte_lpm_list *lpm_list;
+ struct RTE_LPM2_list *lpm_list;
- lpm_list = RTE_TAILQ_CAST(rte_lpm_tailq.head, rte_lpm_list);
+ lpm_list = RTE_TAILQ_CAST(RTE_LPM2_tailq.head, RTE_LPM2_list);
rte_rwlock_read_lock(RTE_EAL_TAILQ_RWLOCK);
TAILQ_FOREACH(te, lpm_list, next) {
- l = (struct rte_lpm *) te->data;
- if (strncmp(name, l->name, RTE_LPM_NAMESIZE) == 0)
+ l = (struct rte_lpm2 *) te->data;
+ if (strncmp(name, l->name, RTE_LPM2_NAMESIZE) == 0)
break;
}
rte_rwlock_read_unlock(RTE_EAL_TAILQ_RWLOCK);
@@ -145,22 +148,148 @@
}
/*
+ * Finds a rule in rule table.
+ * NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
+ */
+static inline struct RTE_LPM2_rule*
+rule_find(struct rte_lpm2 *lpm, uint32_t ip_masked, uint8_t depth)
+{
+ VERIFY_DEPTH(depth);
+
+ lpm_rule_key_t rule_key;
+ rule_key.net = ip_masked;
+ rule_key.mask = (uint32_t) depth;
+
+ struct RTE_LPM2_rule* rule;
+
+ int ret = rte_hash_lookup_data(lpm->rules_hash_tbl, (void*) &rule_key,
+ (void**) &rule);
+
+ if (ret >= 0) {
+ return rule;
+ }
+
+ /* rule is not found */
+ return NULL;
+}
+
+/*
+ * Finds a rule in rule table.
+ * NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
+ */
+static inline struct RTE_LPM2_rule*
+rule_find_by_key(struct rte_lpm2 *lpm, lpm_rule_key_t* rule_key)
+{
+ struct RTE_LPM2_rule* rule;
+
+ int ret = rte_hash_lookup_data(lpm->rules_hash_tbl, (void*) rule_key,
+ (void**) &rule);
+
+ if (ret >= 0) {
+ return rule;
+ }
+
+ /* rule is not found */
+ return NULL;
+}
+
+/*
+ * Finds a rule in rule table.
+ * NOTE: Valid range for depth parameter is 1 .. 32 inclusive.
+ */
+static inline struct RTE_LPM2_rule*
+rule_find_by_key_with_hash(struct rte_lpm2 *lpm, lpm_rule_key_t* rule_key,
+ hash_sig_t sig)
+{
+ struct RTE_LPM2_rule* rule;
+
+ int ret = rte_hash_lookup_with_hash_data(lpm->rules_hash_tbl, (void*)
rule_key,
+ sig, (void**) &rule);
+
+ if (ret >= 0) {
+ return rule;
+ }
+
+ /* rule is not found */
+ return NULL;
+}
+
+/*
+ * hash function for rules hash table
+ */
+static inline uint32_t lpm_prefix_hash_crc(const void *data,
+ __rte_unused uint32_t data_len, uint32_t init_val)
+{
+ // printf("lpm_prefix_hash_crc init: %ul\n", init_val);
+
+ init_val = rte_hash_crc_8byte(*((uint64_t*) data), init_val);
+
+ // printf("lpm_prefix_hash_crc result: %ul\n", init_val);
+
+ return init_val;
+}
+
+/*
* Allocates memory for LPM object
*/
[dpdk-dev] basic forwarding example not working
Hi, for virtio-pci devices you should either just unbind them or bind them to one of the generic drivers like uio_pci_generic. At least I never saw igb_uio on virtio-pci devices. There might be more complete answers, but I think that should get you going. Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Tue, Apr 19, 2016 at 6:00 PM, Subbu CS wrote: > I am using two virtio network adapter on VM on KVM host. > > As in following output, I have bound both interface with igb_uio driver > > ./dpdk_nic_bind.py --bind=igb_uio 00:0a.0 > ./dpdk_nic_bind.py --bind=igb_uio 00:0b.0 > > [root at localhost tools]# ./dpdk_nic_bind.py --status > > Network devices using DPDK-compatible driver > > :00:0a.0 'Virtio network device' drv=igb_uio unused= > :00:0b.0 'Virtio network device' drv=igb_uio unused= > > Network devices using kernel driver > === > :00:03.0 'RTL-8100/8101L/8139 PCI Fast Ethernet Adapter' if=ens3 > drv=8139cp unused=igb_uio *Active* > :00:08.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio > :00:09.0 'Virtio network device' if= drv=virtio-pci unused=igb_uio > > Other network devices > = > > > > But when I run basic fowarding example from skeleton, I get following error > > ./basicfwd -c 1 -n 2 > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Support maximum 128 logical core(s) by configuration. > EAL: Detected 1 lcore(s) > EAL: Probing VFIO support... > EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or > directory) > EAL: VFIO modules not loaded, skipping VFIO support... > EAL: Setting up physically contiguous memory... > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75de40 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75de00 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75ddc0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75dd80 (size = 0x20) > EAL: Ask a virtual area of 0x2740 bytes > EAL: Virtual area found at 0x7f75b620 (size = 0x2740) > EAL: Ask a virtual area of 0x4a0 bytes > EAL: Virtual area found at 0x7f75b160 (size = 0x4a0) > EAL: Ask a virtual area of 0x120 bytes > EAL: Virtual area found at 0x7f75b020 (size = 0x120) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75afe0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75afa0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75af60 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75af20 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75aee0 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7f75aea0 (size = 0x20) > EAL: Requesting 370 pages of size 2MB from socket 0 > EAL: TSC frequency is ~1696081 KHz > EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable > clock cycles ! > EAL: Master lcore 0 is ready (tid=df5298c0;cpuset=[0]) > EAL: PCI device :00:08.0 on NUMA socket -1 > EAL: probe driver: 1af4:1000 rte_virtio_pmd > EAL: Not managed by a supported kernel driver, skipped > Segmentation fault > > Please let me know what is the correct method to run the basic forwarding > application. >
[dpdk-dev] [PATCH v2 1/2] mempool: allow for user-owned mempool caches
2016-04-19 18:39, Lazaros Koromilas: > >> Removes the API calls: > >> > >> rte_mempool_sp_put_bulk(mp, obj_table, n) > >> rte_mempool_sc_get_bulk(mp, obj_table, n) > >> rte_mempool_sp_put(mp, obj) > >> rte_mempool_sc_get(mp, obj) > > > > Hmm, shouldn't we deprecate it first for a release before removing > > completely? > > Let say for now you can just make them macros that calls the remaining > > functions or so. > > How do we mark the calls as deprecated? The librte_compat stuff don't > apply here as we don't have a different version of the same symbol or > something. Do I need to put them as a notice? Yes a notice and add __rte_deprecated.
[dpdk-dev] [PATCH] scripts: add script for generating customised build config
On Tue, Apr 19, 2016 at 02:30:08PM +0200, Thomas Monjalon wrote: > Hi Bruce, > > Thanks for pushing this idea. > > 2016-04-19 11:27, Bruce Richardson: > > This patch adds in the dpdk_config.py script file. It can be used > > to generate custom build-time configurations for DPDK either manually on > > the commandline or by calling it from other scripts. It takes as parameters > > the base config template to use, and output directory to which the modified > > configuration will be written. Other optional parameters are then taken > > as y/n values which should be adjusted in the config file, and a special > > -m flag is provided to override the default RTE_MACHINE setting in the > > config template too. > > > > Example, to create a build configuration with extra non-default PMDs > > enabled, and the kernel modules disabled: > > > > ./scripts/dpdk_config.py -b $RTE_TARGET -o $RTE_TARGET PMD_PCAP=y \ > > IGB_UIO=n KNI_KMOD=n MLX4_PMD=y MLX5_PMD=y SZEDATA2=y \ > > NFP_PMD=y BNX2X_PMD=y > > Would it be possible to use it without -b option to update a configuration? > Interesting idea, but what would that really give us over manual editing? If calling from a script, the user can just rebuild the config from scratch. > Why not name it scripts/configure.py with a symlink ./configure in the > top directory? No objections here. It's just not really a "normal" configure script, instead it's one designed to make it easy for me to generate directories with lots of different build settings in them. If we do want to make it to be "the" way to build DPDK, we can perhaps look at additional enhancements to speed it up by working with the defconfigs directly, as I'm not happy right now with the speed of the "make config" step. On the other hand, I'm very happy with having it short and of limited scope. Actual code only takes up about 50% of the file. :-) > > Should we be able to list every options for a "-b defconfig"? > Good idea, I think. Under what conditions? Only if an invalid config is provided, or as part of regular help text or otherwise? > Would it be a good idea to manage dependencies checks in this script? > I'd rather not do so here. a) I don't think there are a huge number of dependencies to manage b) I'd like to keep it from getting too long and complicated. For 95% of use cases, being able to set a few y/n values on and off, and change the machine type should suffice. I wasn't going for a 100% solution. /Bruce
[dpdk-dev] [PATCH] ethdev: remove deprecated statistics
2016-04-19 16:03, Thomas Monjalon:
> Some statistics were deprecated since release 2.1 (49f386542af4).
>
> The last deprecated counter to be used was imcasts.
>
> The new counters should be added to extended statistics.
>
> Signed-off-by: Thomas Monjalon
[...]
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -200,27 +200,9 @@ struct rte_eth_stats {
> /**< Total of RX packets dropped by the HW,
>* because there are no available mbufs (i.e. RX queues are full).
>*/
> - uint64_t ibadcrc __rte_deprecated;
> - /**< Deprecated; Total of RX packets with CRC error. */
> - uint64_t ibadlen __rte_deprecated;
> - /**< Deprecated; Total of RX packets with bad length. */
> uint64_t ierrors; /**< Total number of erroneous received packets. */
> uint64_t oerrors; /**< Total number of failed transmitted packets. */
> - uint64_t imcasts;
> - /**< Deprecated; Total number of multicast received packets. */
> uint64_t rx_nombuf; /**< Total number of RX mbuf allocation failures. */
> - uint64_t fdirmatch __rte_deprecated;
> - /**< Deprecated; Total number of RX packets matching a filter. */
> - uint64_t fdirmiss __rte_deprecated;
> - /**< Deprecated; Total number of RX packets not matching any filter. */
> - uint64_t tx_pause_xon __rte_deprecated;
> - /**< Deprecated; Total nb. of XON pause frame sent. */
> - uint64_t rx_pause_xon __rte_deprecated;
> - /**< Deprecated; Total nb. of XON pause frame received. */
> - uint64_t tx_pause_xoff __rte_deprecated;
> - /**< Deprecated; Total nb. of XOFF pause frame sent. */
> - uint64_t rx_pause_xoff __rte_deprecated;
> - /**< Deprecated; Total nb. of XOFF pause frame received. */
> uint64_t q_ipackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
> /**< Total number of queue RX packets. */
> uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
I suggest to remove also the loopback statistics which are implemented only
for igbvf and available as extended stats:
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -213,14 +213,6 @@ struct rte_eth_stats {
/**< Total number of successfully transmitted queue bytes. */
uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS];
/**< Total number of queue packets received that are dropped. */
- uint64_t ilbpackets;
- /**< Total number of good packets received from loopback,VF Only */
- uint64_t olbpackets;
- /**< Total number of good packets transmitted to loopback,VF Only */
- uint64_t ilbbytes;
- /**< Total number of good bytes received from loopback,VF Only */
- uint64_t olbbytes;
- /**< Total number of good bytes transmitted to loopback,VF Only */
};
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1805,10 +1805,6 @@ eth_igbvf_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *rte_stats)
rte_stats->ibytes = hw_stats->gorc;
rte_stats->opackets = hw_stats->gptc;
rte_stats->obytes = hw_stats->gotc;
- rte_stats->ilbpackets = hw_stats->gprlbc;
- rte_stats->ilbbytes = hw_stats->gorlbc;
- rte_stats->olbpackets = hw_stats->gptlbc;
- rte_stats->olbbytes = hw_stats->gotlbc;
}
I'll send a v2 if no objection.
[dpdk-dev] [PATCH] ethdev: remove deprecated statistics
Some statistics were deprecated since release 2.1 (49f386542af4).
The last deprecated counter to be used was imcasts.
The new counters should be added to extended statistics.
Signed-off-by: Thomas Monjalon
---
doc/guides/rel_notes/deprecation.rst | 4
doc/guides/rel_notes/release_16_07.rst | 6 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 1 -
drivers/net/cxgbe/cxgbe_ethdev.c | 1 -
drivers/net/e1000/igb_ethdev.c | 1 -
drivers/net/ena/ena_ethdev.c | 2 --
drivers/net/ena/ena_ethdev.h | 1 -
drivers/net/enic/enic_main.c | 1 -
drivers/net/i40e/i40e_ethdev.c | 1 -
drivers/net/ixgbe/ixgbe_ethdev.c | 4
drivers/net/nfp/nfp_net.c | 18 --
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 -
lib/librte_ether/Makefile | 2 +-
lib/librte_ether/rte_ethdev.h | 18 --
14 files changed, 6 insertions(+), 55 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index c78cde7..fffe9c7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -26,10 +26,6 @@ Deprecation Notices
rte_pci_device. The release 16.04 does not contain these ABI changes, but
release 16.07 will.
-* The following fields have been deprecated in rte_eth_stats:
- ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
- tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
-
* The xstats API and rte_eth_xstats struct will be changed to allow retrieval
of values without any string copies or parsing.
No backwards compatibility is planned, as it would require code duplication
diff --git a/doc/guides/rel_notes/release_16_07.rst
b/doc/guides/rel_notes/release_16_07.rst
index 001888f..83c841b 100644
--- a/doc/guides/rel_notes/release_16_07.rst
+++ b/doc/guides/rel_notes/release_16_07.rst
@@ -86,6 +86,10 @@ This section should contain API changes. Sample format:
* Add a short 1-2 sentence description of the API change. Use fixed width
quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past
tense.
+* The following counters are removed from ``rte_eth_stats`` structure:
+ ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
+ tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff.
+
ABI Changes
---
@@ -107,7 +111,7 @@ The libraries prepended with a plus sign were incremented
in this version.
.. code-block:: diff
- libethdev.so.3
+ + libethdev.so.4
librte_acl.so.2
librte_cfgfile.so.2
librte_cmdline.so.2
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 54788cf..c897146 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1836,7 +1836,6 @@ bond_ethdev_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *stats)
stats->imissed += slave_stats.imissed;
stats->ierrors += slave_stats.ierrors;
stats->oerrors += slave_stats.oerrors;
- stats->imcasts += slave_stats.imcasts;
stats->rx_nombuf += slave_stats.rx_nombuf;
for (j = 0; j < RTE_ETHDEV_QUEUE_STAT_CNTRS; j++) {
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index bb134e5..04eddaf 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -656,7 +656,6 @@ static void cxgbe_dev_stats_get(struct rte_eth_dev *eth_dev,
/* RX Stats */
eth_stats->ipackets = ps.rx_frames;
eth_stats->ibytes = ps.rx_octets;
- eth_stats->imcasts = ps.rx_mcast_frames;
eth_stats->imissed = ps.rx_ovflow0 + ps.rx_ovflow1 +
ps.rx_ovflow2 + ps.rx_ovflow3 +
ps.rx_trunc0 + ps.rx_trunc1 +
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index e0053fe..e7682da 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1805,7 +1805,6 @@ eth_igbvf_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *rte_stats)
rte_stats->ibytes = hw_stats->gorc;
rte_stats->opackets = hw_stats->gptc;
rte_stats->obytes = hw_stats->gotc;
- rte_stats->imcasts = hw_stats->mprc;
rte_stats->ilbpackets = hw_stats->gprlbc;
rte_stats->ilbbytes = hw_stats->gorlbc;
rte_stats->olbpackets = hw_stats->gptlbc;
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index 02af67a..e157587 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -605,7 +605,6 @@ static void ena_stats_restart(struct rte_eth_dev *dev)
rte_atomic64_init(&adapter->drv_stats->ierrors);
rte_atomic64_init(&adapter->drv_stats->oerrors);
- rte_atomic64_init(&adapter->drv_stats->imcasts);
rte_atomic64_init(&adapter->drv_stats->rx_nombuf);
}
@@ -643,7 +642,6 @@ static void
[dpdk-dev] [PATCH] virtio: fix newline under debug mode
On Tue, Apr 19, 2016 at 05:22:37AM +, Jianfeng Tan wrote: > Issue: output of appliations and debug info of DPDK may be mixed up > in same line when enabling below debug options of virtio: > CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT > CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX > CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER > > This patch adds "\n" in the tail of definitions like PMD_RX_LOG, > PMD_TX_LOG, and PMD_DRV_LOG, and removes some "\n" when using these > macros. > > Signed-off-by: Jianfeng Tan Acked-by: Yuanhan Liu And applied to dpdk-next-virtio. Thanks. ---yliu
[dpdk-dev] [PATCH v3 3/7] drivers/net/bnxt new driver for Broadcom bnxt
On Fri, Mar 04, 2016 at 01:05:24PM -0800, Stephen Hurd wrote: > New driver for Broadcom bnxt (NexXtreme C-series) devices. > > Standards-compliant 10/25/50G support with 30MPPS full-duplex throughput > http://www.broadcom.com/press/release.php?id=s923886 > > Signed-off-by: Stephen Hurd > --- > v3: > * Fix incorrect format specifier compilation error on i686 > (PRIx64 instead of lx for uint64_t) on line 1337 > > drivers/net/bnxt/Makefile | 79 ++ > drivers/net/bnxt/bnxt.h | 217 > drivers/net/bnxt/bnxt_cpr.c | 138 +++ > drivers/net/bnxt/bnxt_cpr.h | 117 ++ > drivers/net/bnxt/bnxt_ethdev.c| 1381 ++ > drivers/net/bnxt/bnxt_filter.c| 175 +++ > drivers/net/bnxt/bnxt_filter.h| 74 ++ > drivers/net/bnxt/bnxt_hwrm.c | 1554 > drivers/net/bnxt/bnxt_hwrm.h | 105 ++ > drivers/net/bnxt/bnxt_irq.c | 154 +++ > drivers/net/bnxt/bnxt_irq.h | 51 + > drivers/net/bnxt/bnxt_ring.c | 306 + > drivers/net/bnxt/bnxt_ring.h | 104 ++ > drivers/net/bnxt/bnxt_rxq.c | 383 ++ > drivers/net/bnxt/bnxt_rxq.h | 75 ++ > drivers/net/bnxt/bnxt_rxr.c | 369 ++ > drivers/net/bnxt/bnxt_rxr.h | 73 ++ > drivers/net/bnxt/bnxt_stats.c | 190 +++ > drivers/net/bnxt/bnxt_stats.h | 44 + > drivers/net/bnxt/bnxt_txq.c | 164 +++ > drivers/net/bnxt/bnxt_txq.h | 76 ++ > drivers/net/bnxt/bnxt_txr.c | 326 + > drivers/net/bnxt/bnxt_txr.h | 71 ++ > drivers/net/bnxt/bnxt_vnic.c | 285 + > drivers/net/bnxt/bnxt_vnic.h | 80 ++ > drivers/net/bnxt/hsi_struct_def_dpdk.h| 1832 > + > drivers/net/bnxt/rte_pmd_bnxt_version.map |4 + > 27 files changed, 8427 insertions(+) > create mode 100644 drivers/net/bnxt/Makefile > create mode 100644 drivers/net/bnxt/bnxt.h > create mode 100644 drivers/net/bnxt/bnxt_cpr.c > create mode 100644 drivers/net/bnxt/bnxt_cpr.h > create mode 100644 drivers/net/bnxt/bnxt_ethdev.c > create mode 100644 drivers/net/bnxt/bnxt_filter.c > create mode 100644 drivers/net/bnxt/bnxt_filter.h > create mode 100644 drivers/net/bnxt/bnxt_hwrm.c > create mode 100644 drivers/net/bnxt/bnxt_hwrm.h > create mode 100644 drivers/net/bnxt/bnxt_irq.c > create mode 100644 drivers/net/bnxt/bnxt_irq.h > create mode 100644 drivers/net/bnxt/bnxt_ring.c > create mode 100644 drivers/net/bnxt/bnxt_ring.h > create mode 100644 drivers/net/bnxt/bnxt_rxq.c > create mode 100644 drivers/net/bnxt/bnxt_rxq.h > create mode 100644 drivers/net/bnxt/bnxt_rxr.c > create mode 100644 drivers/net/bnxt/bnxt_rxr.h > create mode 100644 drivers/net/bnxt/bnxt_stats.c > create mode 100644 drivers/net/bnxt/bnxt_stats.h > create mode 100644 drivers/net/bnxt/bnxt_txq.c > create mode 100644 drivers/net/bnxt/bnxt_txq.h > create mode 100644 drivers/net/bnxt/bnxt_txr.c > create mode 100644 drivers/net/bnxt/bnxt_txr.h > create mode 100644 drivers/net/bnxt/bnxt_vnic.c > create mode 100644 drivers/net/bnxt/bnxt_vnic.h > create mode 100644 drivers/net/bnxt/hsi_struct_def_dpdk.h > create mode 100644 drivers/net/bnxt/rte_pmd_bnxt_version.map This seems a single huge commit. Can this be split up into separate commits with self-contained changes in each one, e.g. a feature per commit, starting with basic init, then RX and TX etc. etc.? /Bruce
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
2016-03-31 19:15, Rasesh Mody: > The Qlogic Everest Driver for Ethernet(QEDE) Poll Mode Driver(PMD) is > the DPDK specific module for QLogic FastLinQ QL4 25G/40G CNA family > of adapters as well as their virtual functions (VF) in SR-IOV context. > > This patch adds QEDE PMD, which interacts with base driver and > initialises the HW. After removing the BIT_MACRO check (see http://dpdk.org/patch/12113) and other false positives, there is only one warning from checkpatches.sh: CHECK:CONCATENATED_STRING: Concatenated strings should use spaces between elements #1933: FILE: drivers/net/qede/qede_main.c:152: + DP_NOTICE(edev, false, "Invalid fw size: %" PRIu64"\n",
[dpdk-dev] Couple of PMD questions
In ixgbe_dev_rx_init(), there is this bit of code: /* * Configure the RX buffer size in the BSIZEPACKET field of * the SRRCTL register of the queue. * The value is in 1 KB resolution. Valid values can be from * 1 KB to 16 KB. */ buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) - RTE_PKTMBUF_HEADROOM); srrctl |= ((buf_size >> IXGBE_SRRCTL_BSIZEPKT_SHIFT) & IXGBE_SRRCTL_BSIZEPKT_MASK); IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); buf_size = (uint16_t) ((srrctl & IXGBE_SRRCTL_BSIZEPKT_MASK) << IXGBE_SRRCTL_BSIZEPKT_SHIFT); /* It adds dual VLAN length for supporting dual VLAN */ if (dev->data->dev_conf.rxmode.max_rx_pkt_len + 2 * IXGBE_VLAN_TAG_SIZE > buf_size) dev->data->scattered_rx = 1; Couple of questions I have about it: 1) If the caller configured the MBUF memory pool data room size to be something other than a multiple of 1K (+ RTE_PKTMBUF_HEADROOM), then the driver ends up silently programming the NIC to use a smaller max RX size than the caller specified. Should the driver error out in that case instead of only "sort of" working? If not, it seems like it should be logging an error message. 2) Second question is about the "/* It adds dual VLAN length for supporting dual VLAN */" bit... As I understand it, dev_conf.rxmode.max_rx_pkt_len is supposed to be set to the max frame size you support (although it says it's only used if jumbo frame is enabled). That same value is generally used when calculating the size that mbuf elements should be created at. The description for the data_room_size parameter of rte_pktmbuf_pool_create(): "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." If I support a max frame size of 9216 bytes (exactly a 1K multiple to make the NIC happy), then max_rx_pkt_len is going to be 9216 and data_room_size will be 9216 + RTE_PKTMBUF_HEADROOM. ixgbe_dev_rx_init() will calculate normalize that back to 9216, which will fail the dual VLAN length check. The really nasty part about that is it has a side-effect of enabling scattered RX regardless of the fact that I didn't enable scattered RX in dev_conf.rxmode. The code in the e1000 PMD is similar, so nothing unique to ixgbe. Is that check correct? It seems wrong to be adding space for q-in-q on top of your specified max frame size... Thanks, Jay
[dpdk-dev] [PATCH] scripts: ignore bit macro in checkpatch
It was suggesting to use a Linux macro: CHECK:BIT_MACRO: Prefer using the BIT macro It is ignored because it is a false positive in DPDK case. Signed-off-by: Thomas Monjalon --- scripts/checkpatches.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh index 5c58a20..4cae86d 100755 --- a/scripts/checkpatches.sh +++ b/scripts/checkpatches.sh @@ -42,7 +42,7 @@ options="--no-tree" options="$options --max-line-length=$length" options="$options --show-types" options="$options --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\ -VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,PREFER_KERNEL_TYPES,\ +VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,PREFER_KERNEL_TYPES,BIT_MACRO,\ SPLIT_STRING,LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\ NEW_TYPEDEFS,COMPARISON_TO_NULL" -- 2.7.0
[dpdk-dev] [PATCH] scripts: ignore bit macro in checkpatch
It was suggesting to use a Linux macro: CHECK:BIT_MACRO: Prefer using the BIT macro It is ignored because it is a false positive in DPDK case. Signed-off-by: Thomas Monjalon --- scripts/checkpatches.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh index 5c58a20..4cae86d 100755 --- a/scripts/checkpatches.sh +++ b/scripts/checkpatches.sh @@ -42,7 +42,7 @@ options="--no-tree" options="$options --max-line-length=$length" options="$options --show-types" options="$options --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\ -VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,PREFER_KERNEL_TYPES,\ +VOLATILE,PREFER_PACKED,PREFER_ALIGNED,PREFER_PRINTF,PREFER_KERNEL_TYPES,BIT_MACRO,\ SPLIT_STRING,LINE_SPACING,PARENTHESIS_ALIGNMENT,NETWORKING_BLOCK_COMMENT_STYLE,\ NEW_TYPEDEFS,COMPARISON_TO_NULL" -- 2.7.0
[dpdk-dev] [PATCH 2/2] examples/l2fwd: increase mempool cache size for better performance
l3fwd sets the mempool cache size to 256, selected the same value for l2fwd
Signed-off-by: Jerin Jacob
---
examples/l2fwd/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 7bdd1b5..24715e3 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -80,6 +80,7 @@ static volatile bool force_quit;
#define MAX_PKT_BURST 32
#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
+#define MEMPOOL_CACHE_SIZE 256
/*
* Configurable number of RX/TX ring descriptors
@@ -545,8 +546,9 @@ main(int argc, char **argv)
timer_period *= rte_get_timer_hz();
/* create the mbuf pool */
- l2fwd_pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF, 32,
- 0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_socket_id());
+ l2fwd_pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
+ MEMPOOL_CACHE_SIZE, 0, RTE_MBUF_DEFAULT_BUF_SIZE,
+ rte_socket_id());
if (l2fwd_pktmbuf_pool == NULL)
rte_exit(EXIT_FAILURE, "Cannot init mbuf pool\n");
--
2.1.0
[dpdk-dev] [PATCH 1/2] examples/l2fwd: remove number of cycles per second hardcording
Signed-off-by: Jerin Jacob
---
examples/l2fwd/main.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 1ad9488..7bdd1b5 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -134,10 +134,9 @@ struct l2fwd_port_statistics {
} __rte_cache_aligned;
struct l2fwd_port_statistics port_statistics[RTE_MAX_ETHPORTS];
-/* A tsc-based timer responsible for triggering statistics printout */
-#define TIMER_MILLISECOND 200ULL /* around 1ms at 2 Ghz */
#define MAX_TIMER_PERIOD 86400 /* 1 day max */
-static int64_t timer_period = 10 * TIMER_MILLISECOND * 1000; /* default period
is 10 seconds */
+/* A tsc-based timer responsible for triggering statistics printout */
+static uint64_t timer_period = 10; /* default period is 10 seconds */
/* Print out statistics on packets dropped */
static void
@@ -274,7 +273,7 @@ l2fwd_main_loop(void)
timer_tsc += diff_tsc;
/* if timer has reached its timeout */
- if (unlikely(timer_tsc >= (uint64_t)
timer_period)) {
+ if (unlikely(timer_tsc >= timer_period)) {
/* do this only on master core */
if (lcore_id == rte_get_master_lcore())
{
@@ -381,7 +380,7 @@ l2fwd_parse_timer_period(const char *q_arg)
static int
l2fwd_parse_args(int argc, char **argv)
{
- int opt, ret;
+ int opt, ret, timer_secs;
char **argvopt;
int option_index;
char *prgname = argv[0];
@@ -417,12 +416,13 @@ l2fwd_parse_args(int argc, char **argv)
/* timer period */
case 'T':
- timer_period = l2fwd_parse_timer_period(optarg) * 1000
* TIMER_MILLISECOND;
- if (timer_period < 0) {
+ timer_secs = l2fwd_parse_timer_period(optarg);
+ if (timer_secs < 0) {
printf("invalid timer period\n");
l2fwd_usage(prgname);
return -1;
}
+ timer_period = timer_secs;
break;
/* long options */
@@ -541,6 +541,9 @@ main(int argc, char **argv)
if (ret < 0)
rte_exit(EXIT_FAILURE, "Invalid L2FWD arguments\n");
+ /* convert to number of cycles */
+ timer_period *= rte_get_timer_hz();
+
/* create the mbuf pool */
l2fwd_pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF, 32,
0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_socket_id());
--
2.1.0
[dpdk-dev] [PATCH 0/2] l2fwd improvements
Jerin Jacob (2): examples/l2fwd: remove number of cycles per second hardcording examples/l2fwd: increase mempool cache size for better performance examples/l2fwd/main.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) -- 2.1.0
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
2016-03-31 19:15, Rasesh Mody: > +ifeq ($(OS_TYPE),Linux) > +CFLAGS_ECORE_DRIVER += -Wno-shift-negative-value > +endif I see an error with clang: fatal error: unknown warning option '-Wno-shift-negative-value'; did you mean '-Wno-shift-sign-overflow'?
[dpdk-dev] [PATCH v5 09/10] qede: Add DCBX support
2016-03-31 19:15, Rasesh Mody: > - case ECORE_PCI_ETH_ROCE: > - p_ramrod->personality = PERSONALITY_RDMA_AND_ETH; > - break; Better to remove it from the previous patches.
[dpdk-dev] [PATCH v5 05/10] qede: Add core driver
2016-03-31 19:15, Rasesh Mody: > +# > +# CFLAGS > +# > +CFLAGS_ECORE_DRIVER = -Wno-unused-parameter > +CFLAGS_ECORE_DRIVER += -Wno-unused-value > +CFLAGS_ECORE_DRIVER += -Wno-sign-compare > +CFLAGS_ECORE_DRIVER += -Wno-missing-prototypes > +CFLAGS_ECORE_DRIVER += -Wno-cast-qual > +CFLAGS_ECORE_DRIVER += -Wno-unused-function > +CFLAGS_ECORE_DRIVER += -Wno-unused-variable > +CFLAGS_ECORE_DRIVER += -Wno-strict-aliasing > +CFLAGS_ECORE_DRIVER += -Wno-missing-prototypes > +CFLAGS_ECORE_DRIVER += -Wno-format-nonliteral > +ifeq ($(OS_TYPE),Linux) > +CFLAGS_ECORE_DRIVER += -Wno-shift-negative-value > +endif > + > +ifneq (,$(filter gcc gcc48,$(CC))) > +CFLAGS_ECORE_DRIVER += -Wno-unused-but-set-variable > +CFLAGS_ECORE_DRIVER += -Wno-missing-declarations > +CFLAGS_ECORE_DRIVER += -Wno-maybe-uninitialized > +CFLAGS_ECORE_DRIVER += -Wno-strict-prototypes > +else ifeq ($(CC), clang) > +CFLAGS_ECORE_DRIVER += -Wno-format-extra-args > +CFLAGS_ECORE_DRIVER += -Wno-visibility > +CFLAGS_ECORE_DRIVER += -Wno-empty-body > +CFLAGS_ECORE_DRIVER += -Wno-invalid-source-encoding > +CFLAGS_ECORE_DRIVER += -Wno-sometimes-uninitialized > +CFLAGS_ECORE_DRIVER += -Wno-pointer-bool-conversion > +else > +#icc flags > +endif > + > +# > +# Add extra flags for base ecore driver files > +# to disable warnings in them > +# > +# > +ECORE_DRIVER_OBJS=$(patsubst %.c,%.o,$(notdir $(wildcard > $(SRCDIR)/base/*.c))) > +$(foreach obj, $(ECORE_DRIVER_OBJS), $(eval CFLAGS+=$(CFLAGS_ECORE_DRIVER))) CFLAGS_ECORE_DRIVER options apply only to base driver. So why not name it CFLAGS_BASE_DRIVER? This part of the Makefile should be in the patch importing the base driver.
[dpdk-dev] [PATCH 1/1] examples/distributor: fix unchecked return value
Fix issue reported by Coverity.
Coverity ID 13207:
Value returned from a function is not checked for errors before being
used.
Fixes: 07db4a975094 ("examples/distributor: new sample app")
Signed-off-by: Marcin Kerlin
---
examples/distributor/main.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index c0201a9..8238520 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -178,19 +178,25 @@ struct lcore_params {
struct rte_mempool *mem_pool;
};
-static void
+static int
quit_workers(struct rte_distributor *d, struct rte_mempool *p)
{
const unsigned num_workers = rte_lcore_count() - 2;
unsigned i;
struct rte_mbuf *bufs[num_workers];
- rte_mempool_get_bulk(p, (void *)bufs, num_workers);
+
+ if (rte_mempool_get_bulk(p, (void *)bufs, num_workers) != 0) {
+ printf("line %d: Error getting mbufs from pool\n", __LINE__);
+ return -1;
+ }
for (i = 0; i < num_workers; i++)
bufs[i]->hash.rss = i << 1;
rte_distributor_process(d, bufs, num_workers);
rte_mempool_put_bulk(p, (void *)bufs, num_workers);
+
+ return 0;
}
static int
@@ -258,7 +264,8 @@ lcore_rx(struct lcore_params *p)
* get packets till quit_signal is actually been
* received and they gracefully shutdown
*/
- quit_workers(d, mem_pool);
+ if (quit_workers(d, mem_pool) != 0)
+ return -1;
/* rx thread should quit at last */
return 0;
}
@@ -588,7 +595,9 @@ main(int argc, char *argv[])
}
/* call lcore_main on master core only */
struct lcore_params p = { 0, d, output_ring, mbuf_pool};
- lcore_rx(&p);
+
+ if (lcore_rx(&p) != 0)
+ return -1;
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
if (rte_eal_wait_lcore(lcore_id) < 0)
--
1.9.1
[dpdk-dev] [PATCH] scripts: add script for generating customised build config
Hi Bruce, Thanks for pushing this idea. 2016-04-19 11:27, Bruce Richardson: > This patch adds in the dpdk_config.py script file. It can be used > to generate custom build-time configurations for DPDK either manually on > the commandline or by calling it from other scripts. It takes as parameters > the base config template to use, and output directory to which the modified > configuration will be written. Other optional parameters are then taken > as y/n values which should be adjusted in the config file, and a special > -m flag is provided to override the default RTE_MACHINE setting in the > config template too. > > Example, to create a build configuration with extra non-default PMDs > enabled, and the kernel modules disabled: > > ./scripts/dpdk_config.py -b $RTE_TARGET -o $RTE_TARGET PMD_PCAP=y \ > IGB_UIO=n KNI_KMOD=n MLX4_PMD=y MLX5_PMD=y SZEDATA2=y \ > NFP_PMD=y BNX2X_PMD=y Would it be possible to use it without -b option to update a configuration? Why not name it scripts/configure.py with a symlink ./configure in the top directory? Should we be able to list every options for a "-b defconfig"? Would it be a good idea to manage dependencies checks in this script?
[dpdk-dev] [PATCH] i40e: fix packet stats getting
The statistics queried by calling rte_eth_stats_get are zero when
the API is first called on the port. The root cause is because of
offset_loaded flag is not set correctly after device started.
This patch fixes this issue by resetting statistics at initialization
time, at the meanwhile the resetting process will set offset_loaded
flag.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bc28d3c..3aaef07 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -934,6 +934,9 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
goto err_setup_pf_switch;
}
+ /* reset all stats of the device, including pf and main vsi */
+ i40e_dev_stats_reset(dev);
+
vsi = pf->main_vsi;
/* Disable double vlan by default */
--
2.4.0
[dpdk-dev] perfomance of rte_lpm rule subsystem
Hi. Doing some test with rte_lpm (adding/deleting bgp full table rules) I noticed that rule subsystem is very slow even considering that probably it was never designed for using in a data forwarding plane. So I want to propose some changes to the "rule" subsystem. I reimplemented rule part ot the lib using rte_hash, and perfomance of adding/deleted routes have increased dramatically. If increasing speed of adding deleting routes makes sence for anybody else I would like to discuss my patch. The patch also include changes that make next_hop 64 bit, so please just ignore them. The rule changes are in the following functions only: rte_lpm2_create rule_find rule_add rule_delete find_previous_rule delete_depth_small delete_depth_big rte_lpm2_add rte_lpm2_delete rte_lpm2_is_rule_present rte_lpm2_delete_all P.S. the patch was made for 2.2.0 version. P.P.S. Would it be more convinient to include full source file instead of patch?
[dpdk-dev] [PATCH v3 2/7] lib/librte_eal: Add PCI IDs for Broadcom bnxt
On Fri, Mar 04, 2016 at 01:05:23PM -0800, Stephen Hurd wrote: > Add Broadcom Vendor ID and RTE_PCI_DEV_ID_DECL_BNXT() macro. > Add Device IDs for Broadcom bnxt devices. > > Signed-off-by: Stephen Hurd > --- > lib/librte_eal/common/include/rte_pci_dev_ids.h | 45 > ++--- > 1 file changed, 40 insertions(+), 5 deletions(-) > > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h > b/lib/librte_eal/common/include/rte_pci_dev_ids.h > index d088191..9a8f254 100644 > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h > @@ -63,11 +63,11 @@ > * This file contains a list of the PCI device IDs recognised by DPDK, which > * can be used to fill out an array of structures describing the devices. > * > - * Currently four families of devices are recognised: those supported by the > - * IGB driver, by EM driver, those supported by the IXGBE driver, and by > virtio > - * driver which is a para virtualization driver running in guest virtual > machine. > - * The inclusion of these in an array built using this file depends on the > - * definition of > + * Currently five families of devices are recognised: those supported by the > + * IGB driver, by EM driver, those supported by the IXGBE driver, by BNXT > + * driver, and by virtio driver which is a para virtualization driver running > + * in guest virtual machine. The inclusion of these in an array built using > + * this file depends on the definition of > * RTE_PCI_DEV_ID_DECL_EM > * RTE_PCI_DEV_ID_DECL_IGB > * RTE_PCI_DEV_ID_DECL_IGBVF > @@ -76,6 +76,7 @@ > * RTE_PCI_DEV_ID_DECL_I40E > * RTE_PCI_DEV_ID_DECL_I40EVF > * RTE_PCI_DEV_ID_DECL_VIRTIO > + * RTE_PCI_DEV_ID_DECL_BNXT > * at the time when this file is included. > * > * In order to populate an array, the user of this file must define this > macro: > @@ -167,6 +168,15 @@ > #define PCI_VENDOR_ID_VMWARE 0x15AD > #endif > > +#ifndef PCI_VENDOR_ID_BROADCOM > +/** Vendor ID used by Broadcom devices */ > +#define PCI_VENDOR_ID_BROADCOM 0x14E4 > +#endif > + > +#ifndef RTE_PCI_DEV_ID_DECL_BNXT > +#define RTE_PCI_DEV_ID_DECL_BNXT(vendor, dev) > +#endif > + This macro definition looks to be in the wrong place in the file. The device definitions are all placed above the vendor declarations. /Bruce
[dpdk-dev] [PATCH v3 3/7] drivers/net/bnxt new driver for Broadcom bnxt
On Tue, Apr 19, 2016 at 7:19 AM, Bruce Richardson < bruce.richardson at intel.com> wrote: > On Fri, Mar 04, 2016 at 01:05:24PM -0800, Stephen Hurd wrote: > > New driver for Broadcom bnxt (NexXtreme C-series) devices. > > This seems a single huge commit. Can this be split up into separate commits > with self-contained changes in each one, e.g. a feature per commit, > starting > with basic init, then RX and TX etc. etc.? > I suppose it could, I'm not sure what the value of that approach would be though... it would just be a long process of copy/paste/commit/repeat. Internally, it was developed as a port/rewrite of another driver, so we don't actually have history without a large commit. Assuming each individual commit needs to be buildable, this will end up burning a lot of time, and I doubt each separate commit could be reasonably tested. -- Stephen Hurd
[dpdk-dev] [PATCH v3 1/7] lib/librte_ether: Add 2/2.5/25/50Gbps link speeds
On Fri, Mar 04, 2016 at 01:05:22PM -0800, Stephen Hurd wrote:
> Add additional ETH_LINK_SPEED_* macros for 2, 2.5, 25, and 50 Gbps links
>
> Signed-off-by: Stephen Hurd
> ---
> lib/librte_ether/rte_ethdev.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 16da821..cb40bbb 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -254,10 +254,14 @@ struct rte_eth_link {
> #define ETH_LINK_SPEED_10 10 /**< 10 megabits/second. */
> #define ETH_LINK_SPEED_100 100 /**< 100 megabits/second. */
> #define ETH_LINK_SPEED_1000 1000/**< 1 gigabits/second. */
> +#define ETH_LINK_SPEED_2000 2000/**< 2 gigabits/second. */
> +#define ETH_LINK_SPEED_2500 2500/**< 2.5 gigabits/second. */
> #define ETH_LINK_SPEED_11 /**< 10 gigabits/second. */
> #define ETH_LINK_SPEED_10G 1 /**< alias of 10 gigabits/second. */
> #define ETH_LINK_SPEED_20G 2 /**< 20 gigabits/second. */
> +#define ETH_LINK_SPEED_25G 25000/**< 25 gigabits/second. */
> #define ETH_LINK_SPEED_40G 4 /**< 40 gigabits/second. */
> +#define ETH_LINK_SPEED_50G 5 /**< 50 gigabits/second. */
>
> #define ETH_LINK_AUTONEG_DUPLEX 0 /**< Auto-negotiate duplex. */
> #define ETH_LINK_HALF_DUPLEX1 /**< Half-duplex connection. */
> --
Hi Stephen,
there were some link speed changes in Rel 16.04, so this patch needs an update
to apply. Hopefully most of the changes in it are no longer needed following the
rework.
Regards,
/Bruce
[dpdk-dev] rte_hash_del_key crash in multi-process environment
Hi all,
In the multi-process environment, before I met a bug when calling
rte_hash_lookup_with_hash. Using Dhana's patch fixed my problem. Now I need to
remove the flow in the multi-process environment, the system gets crashed when
calling rte_hash_del_key function. The following is the gdb trace. Does anybody
meet this problem or know how to fix it?
Program received signal SIGILL, Illegal instruction.
0x0048a0dd in rte_port_ring_reader_frag_free (port=0x7ffe113d4100) at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_port/rte_port_frag.c:266
266return -1;
(gdb) bt
#0 0x0048a0dd in rte_port_ring_reader_frag_free (port=0x7ffe113d4100)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_port/rte_port_frag.c:266
#1 0x0049c537 in rte_hash_del_key (h=0x7ffe113d4100,
key=0x7ffe092e1000)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:917
#2 0x0043716a in onvm_ft_remove_key (table=0x7ffe113c3e80,
key=0x7ffe092e1000) at
/home/zhangwei1984/onvm-shared-cpu/onvm/shared/onvm_flow_table.c:160
#3 0x0043767e in onvm_flow_dir_del_and_free_key (key=0x7ffe092e1000)
at /home/zhangwei1984/onvm-shared-cpu/onvm/shared/onvm_flow_dir.c:144
#4 0x00437619 in onvm_flow_dir_del_key (key=0x7ffe092e1000) at
/home/zhangwei1984/onvm-shared-cpu/onvm/shared/onvm_flow_dir.c:128
#5 0x00423ded in remove_flow_rule (idx=3) at
/home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:130
#6 0x00423e44 in clear_stat_remove_flow_rule (nf_info=0x7fff3e652100)
at /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:145
#7 0x004247e3 in alloc_nfs_install_flow_rule (services=0xd66e90
, pkt=0x7ffe13f56400)
at /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:186
#8 0x00424bdb in packet_handler (pkt=0x7ffe13f56400,
meta=0x7ffe13f56440) at
/home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:294
#9 0x0043001d in onvm_nf_run (info=0x7fff3e651b00, handler=0x424b21
) at
/home/zhangwei1984/onvm-shared-cpu/onvm/onvm_nf/onvm_nflib.c:462
#10 0x00424cc2 in main (argc=3, argv=0x7fffe660) at
/home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:323
At 2016-03-23 03:53:43, "De Lara Guarch, Pablo" wrote:
>Hi Thomas,
>
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Tuesday, March 22, 2016 11:42 AM
>> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio
>> Cc: dev at dpdk.org; Dhana Eadala; Richardson, Bruce; Qiu, Michael
>> Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-
>> process environment
>>
>> Hi,
>>
>> Pablo, Sergio, please could you help with this issue?
>
>I agree this is not the best way to fix this. I will try to have a fix without
>having to use ifdefs.
>
>Thanks,
>Pablo
>>
>> 2016-03-13 22:16, Dhana Eadala:
>> > We found a problem in dpdk-2.2 using under multi-process environment.
>> > Here is the brief description how we are using the dpdk:
>> >
>> > We have two processes proc1, proc2 using dpdk. These proc1 and proc2
>> are
>> > two different compiled binaries.
>> > proc1 is started as primary process and proc2 as secondary process.
>> >
>> > proc1:
>> > Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash
>> structure.
>> > As part of this, this api initalized the rte_hash structure and set the
>> > srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1
>> address space.
>> >
>> > proc2:
>> > calls srcHash = rte_hash_find_existing("src_hash_name").
>> > This function call returns the rte_hash created by proc1.
>> > This srcHash->rte_hash_cmp_eq still points to the address of
>> > memcmp() from proc1 address space.
>> > Later proc2 calls
>> > rte_hash_lookup_with_hash(srcHash, (const void*) &key, key.sig);
>> > rte_hash_lookup_with_hash() invokes __rte_hash_lookup_with_hash(),
>> > which in turn calls h->rte_hash_cmp_eq(key, k->key, h->key_len).
>> > This leads to a crash as h->rte_hash_cmp_eq is an address
>> > from proc1 address space and is invalid address in proc2 address space.
>> >
>> > We found, from dpdk documentation, that
>> >
>> > "
>> > The use of function pointers between multiple processes
>> > running based of different compiled
>> > binaries is not supported, since the location of a given function
>> > in one process may be different to
>> > its location in a second. This prevents the librte_hash library
>> > from behaving properly as in a multi-
>> > threaded instance, since it uses a pointer to the hash function
>> > internally.
>> >
>> > To work around this issue, it is recommended that
>> > multi-process applications perform the hash
>> > calculations by directly calling the hashing function
>> > from the code and then using the
>> > rte_hash_add_with_hash()/rte_hash_lookup_with_hash() functions
>> > instead of the functions which do
>> >
[dpdk-dev] [Announce] A new tree for vhost/virtio
Great! Thanks a lot, the tree will allow me to focus on development, and not waste the time on testing and maintenance. -- Victor - Original Message - > From: "Yuanhan Liu" > To: dev at dpdk.org > Cc: "Thomas Monjalon" , "Bruce Richardson" > , "Huawei Xie" > , "Victor Kaplansky" , "Rich > Lane" , "Tetsuya > Mukawa" , "Stephen Hemminger" networkplumber.org>, "vincent jardin" > , "Zhihong Wang" , > "Jianfeng Tan" > Sent: Monday, April 18, 2016 9:55:06 PM > Subject: [Announce] A new tree for vhost/virtio > > > Hi, > > Here I'd like to announce a new tree for vhost/virtio[0], and I'm > going to be the maintainer. > > [0]: http://dpdk.org/browse/next/dpdk-next-virtio/ > > This is done by a private request to Thomas few days ago (well, I'd > confess this should have been a public request/discussion, and you > can find it in the end of this email). > > And this is for merging patches a bit faster, especially for those > fix and cleanup patches. Note that it still takes time to merge > feature patches, even those from myself. Another note is that this > tree is meant to be rebaseable. > > You are suggested to make virtio/vhost patches based on this tree, > to reduce patch conflict chance. > > @Tetsuya, do you mind if I take over patches for vhost-pmd as well? > > Thanks. > > --yliu > > - Forwarded message from Yuanhan Liu > - > > Date: Wed, 13 Apr 2016 01:53:41 +0800 > From: Yuanhan Liu > To: Thomas Monjalon > Cc: Bruce Richardson , "Zhu, Heqing" > , > Yuanhan Liu > Subject: A request to take over vhost/virtio patches (was Re: [dpdk-dev] > dpdk: vhost/virtio > staging/testing tree) > User-Agent: Mutt/1.5.23 (2014-03-12) > > Hi Thomas, > > Due to the nature of vhost/virtio (being open standard), we have more > external contributors (not from intel) than other components: I just > wrote a script to count that (the number means the # of contributors > not from intel, and the date is got from this release only): > > vhost|virtio: 10 > doc: 10 > ethdev: 9 > eal: 9 > mlx: 8 > mk: 7 > mlx5: 6 > app/test: 6 > examples: 5 > config: 5 > tools: 4 > mlx4: 4 > eal/linux: 4 > bonding: 4 > vmxnet3: 3 > nfp: 3 > mbuf: 3 > lpm: 3 > ixgbe: 3 > igb: 3 > i40e: 3 > > As you can see, vhost/virtio is on the top of the list, which is a > great thing: it means we have a health community. We have done well > to achieve that, however, I'm thinking we could do better: to be > more active on patch reviewing/merging, to try to solve some problems > I found as I stated in my following email. > > Therefore, I'd like to request again to take over all vhost/virtio > patches. In another word, I'd like to maintain another tree, like > Bruce does for dpdk-next-net tree, and to apply patches in time. > > And now, I'd like to introduce myself a bit, and hopefully this > could convince you that I'm competent to the committer role, though > you might have already known that from my recent performs :) > > I have been working on open source projects since 2009. Till now, > it would be about 7 years of experience on open source. My first > project was Syslinux, later on, I have worked on few more projects, > including Linux Kernel, Mesa and so on. Therefore, I'm sure that > my rich experience on open source would definitely let me be > capable of the new role. > > Thanks. > > --yliu > > > On Tue, Feb 16, 2016 at 12:02:42PM +0800, Yuanhan Liu wrote: > > On Fri, Feb 12, 2016 at 01:54:21PM +0200, Victor Kaplansky wrote: > > > Hi! > > > > Hi Victor, > > > > > Since I was maintaining an internal tree with patches related to > > > vhost/virtio, I decided to make this staging tree public. It is > > > useful to me and I hope it will be useful to others. > > > > > > Collecting patches like this allows tracking dependencies between > > > patches, their improvement etc. I also rebase the tree so > > > contributors don't have to. > > > > I had same thoughts, before, aiming to speed the patch review and > > merge process. > > > > DPDK community, likely, has a culture of very slow patch review and > > merge process: I often saw patches not get reviewed for weeks, even > > months! I also saw that a patch has been ACK-ed, but not get merged > > until few weeks has been passed. While I am inside the team, I > > understand it's a very reasonable phenomenon: every one of us has > > lots of tasks to do, and we intend to do the review after all tasks > > have been finished. > > > > Despite the fact, I was thinking that I could maintain a tree, so > > that I could apply all virtio/vhost patches that has been ACKed in > > the first time. Later, I will send pull request to Thomas, from > > time to time. Thomas, on the other hand, only need to have a double > > check of the patches from my request. If he has any concerns on > > some specific patch (or patch set), I will drop them, and let the > > author to send a
[dpdk-dev] [Announce] A new tree for vhost/virtio
On 2016/04/19 3:55, Yuanhan Liu wrote: > Hi, > > Here I'd like to announce a new tree for vhost/virtio[0], and I'm > going to be the maintainer. > > [0]: http://dpdk.org/browse/next/dpdk-next-virtio/ > > This is done by a private request to Thomas few days ago (well, I'd > confess this should have been a public request/discussion, and you > can find it in the end of this email). > > And this is for merging patches a bit faster, especially for those > fix and cleanup patches. Note that it still takes time to merge > feature patches, even those from myself. Another note is that this > tree is meant to be rebaseable. > > You are suggested to make virtio/vhost patches based on this tree, > to reduce patch conflict chance. > > @Tetsuya, do you mind if I take over patches for vhost-pmd as well? Yes, could you please. Thanks, Tetsuya > > Thanks. > > --yliu > > - Forwarded message from Yuanhan Liu > - > > Date: Wed, 13 Apr 2016 01:53:41 +0800 > From: Yuanhan Liu > To: Thomas Monjalon > Cc: Bruce Richardson , "Zhu, Heqing" > , > Yuanhan Liu > Subject: A request to take over vhost/virtio patches (was Re: [dpdk-dev] > dpdk: vhost/virtio > staging/testing tree) > User-Agent: Mutt/1.5.23 (2014-03-12) > > Hi Thomas, > > Due to the nature of vhost/virtio (being open standard), we have more > external contributors (not from intel) than other components: I just > wrote a script to count that (the number means the # of contributors > not from intel, and the date is got from this release only): > > vhost|virtio: 10 > doc: 10 > ethdev: 9 > eal: 9 > mlx: 8 > mk: 7 > mlx5: 6 > app/test: 6 > examples: 5 > config: 5 > tools: 4 > mlx4: 4 > eal/linux: 4 > bonding: 4 > vmxnet3: 3 > nfp: 3 > mbuf: 3 > lpm: 3 > ixgbe: 3 > igb: 3 > i40e: 3 > > As you can see, vhost/virtio is on the top of the list, which is a > great thing: it means we have a health community. We have done well > to achieve that, however, I'm thinking we could do better: to be > more active on patch reviewing/merging, to try to solve some problems > I found as I stated in my following email. > > Therefore, I'd like to request again to take over all vhost/virtio > patches. In another word, I'd like to maintain another tree, like > Bruce does for dpdk-next-net tree, and to apply patches in time. > > And now, I'd like to introduce myself a bit, and hopefully this > could convince you that I'm competent to the committer role, though > you might have already known that from my recent performs :) > > I have been working on open source projects since 2009. Till now, > it would be about 7 years of experience on open source. My first > project was Syslinux, later on, I have worked on few more projects, > including Linux Kernel, Mesa and so on. Therefore, I'm sure that > my rich experience on open source would definitely let me be > capable of the new role. > > Thanks. > > --yliu > > > On Tue, Feb 16, 2016 at 12:02:42PM +0800, Yuanhan Liu wrote: >> On Fri, Feb 12, 2016 at 01:54:21PM +0200, Victor Kaplansky wrote: >>> Hi! >> Hi Victor, >> >>> Since I was maintaining an internal tree with patches related to >>> vhost/virtio, I decided to make this staging tree public. It is >>> useful to me and I hope it will be useful to others. >>> >>> Collecting patches like this allows tracking dependencies between >>> patches, their improvement etc. I also rebase the tree so >>> contributors don't have to. >> I had same thoughts, before, aiming to speed the patch review and >> merge process. >> >> DPDK community, likely, has a culture of very slow patch review and >> merge process: I often saw patches not get reviewed for weeks, even >> months! I also saw that a patch has been ACK-ed, but not get merged >> until few weeks has been passed. While I am inside the team, I >> understand it's a very reasonable phenomenon: every one of us has >> lots of tasks to do, and we intend to do the review after all tasks >> have been finished. >> >> Despite the fact, I was thinking that I could maintain a tree, so >> that I could apply all virtio/vhost patches that has been ACKed in >> the first time. Later, I will send pull request to Thomas, from >> time to time. Thomas, on the other hand, only need to have a double >> check of the patches from my request. If he has any concerns on >> some specific patch (or patch set), I will drop them, and let the >> author to send a new version. >> >> Put simply, it's a similar style Linux kernel (and QEMU) takes. >> >> Another thing worthy noting is that Bruce started to maintain >> a such tree recently: >> >> http://dpdk.org/browse/next/dpdk-next-net/ >> >> So, as long as Bruce merges patches quickly, it should not matter. >> >>> Before publishing, I test the tree so it can serve as a known >>> good state for people interested in preliminary testing of >>> patches that aren't yet upstream, improving testing/validation as >>> multiple pe
[dpdk-dev] [PATCH] scripts: add script for generating customised build config
This patch adds in the dpdk_config.py script file. It can be used
to generate custom build-time configurations for DPDK either manually on
the commandline or by calling it from other scripts. It takes as parameters
the base config template to use, and output directory to which the modified
configuration will be written. Other optional parameters are then taken
as y/n values which should be adjusted in the config file, and a special
-m flag is provided to override the default RTE_MACHINE setting in the
config template too.
Example, to create a build configuration with extra non-default PMDs
enabled, and the kernel modules disabled:
./scripts/dpdk_config.py -b $RTE_TARGET -o $RTE_TARGET PMD_PCAP=y \
IGB_UIO=n KNI_KMOD=n MLX4_PMD=y MLX5_PMD=y SZEDATA2=y \
NFP_PMD=y BNX2X_PMD=y
See the included help text in the script for more details.
Signed-off-by: Bruce Richardson
---
scripts/dpdk_config.py | 198 +
1 file changed, 198 insertions(+)
create mode 100755 scripts/dpdk_config.py
diff --git a/scripts/dpdk_config.py b/scripts/dpdk_config.py
new file mode 100755
index 000..01236d8
--- /dev/null
+++ b/scripts/dpdk_config.py
@@ -0,0 +1,198 @@
+#! /usr/bin/env python
+#
+# BSD LICENSE
+#
+# Copyright(c) 2016 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.
+#
+
+from __future__ import print_function
+import sys
+import os.path
+import getopt
+import subprocess
+
+out = "build"
+base = None
+machine = None
+
+
+def print_usage(cmd, f):
+print("""Usage: %s -b [-o ] [options...] """
+ % os.path.basename(cmd), file=f)
+
+
+def print_help(cmd):
+print_usage(cmd, sys.stdout)
+print("""
+Generates a new DPDK build time configuration in the given output directory,
+using as a starting point the provided base configuration. Once completed
+successfully, DPDK can then be built using that configuration by running the
+command "make -C ".
+
+-b, --base-config=CONFIG
+Use the configuration given by CONFIG as the starting point for the
+build configuration. CONFIG must be a valid DPDK default configuration
+provided by a file "defconfig_CONFIG" in the top level "config"
+directory.
+Example: "-b x86_64-native-linuxapp-gcc"
+
+-o, --output-dir=DIR
+Use DIR as the resulting output directory. If unspecified the default
+value of "build" is used.
+
+-m, --machine-type=TYPE
+Override the machine-type value given in the default configuration by
+setting it to TYPE. Using regular options, regular y/n values can be
+changed, but not string options, so this explicit override for machine
+type exists to allow changing it.
+
+-h, --help
+Print this help text and then exit
+
+Other options passed after these on the commandline should be in the format of
+"name=y|n" and are overrides to be applied to the configuration to toggle the
+y|n settings in the file.
+
+Matches are applied on partial values, so for example "DEBUG=y" will turn on
+all options ending in "DEBUG". This means that a full option need not always be
+specified, for example, "CONFIG_RTE_LIBRTE_" prefixes can generally be omitted.
+
+Examples:
+
+To generate a configuration for DPDK
+- based off x86_64-native-linuxapp-gcc,
+- changing the machine type to "default",
+- turning on the pcap PMD,
+- disabling the KNI and igb_uio kernel modules, and
+- placing the output in a suitably
[dpdk-dev] [PATCH] examples: fix CID 30693 unchecked return value
It fix coverity issue:
CID 30693 (#1 of 1): Unchecked return value (CHECKED_RETURN)
2. check_return: Calling rte_meter_srtcm_config without checking return value
(as is done elsewhere 16 out of 17 times).
Fixes: e6541fdec8b2 ("meter: initial import")
Signed-off-by: Slawomir Mrozowicz
---
examples/qos_meter/main.c | 15 ++-
examples/qos_meter/main.h | 2 +-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/examples/qos_meter/main.c b/examples/qos_meter/main.c
index b968b00..16b0b87 100644
--- a/examples/qos_meter/main.c
+++ b/examples/qos_meter/main.c
@@ -133,14 +133,17 @@ struct rte_meter_trtcm_params app_trtcm_params[] = {
FLOW_METER app_flows[APP_FLOWS_MAX];
-static void
+static int
app_configure_flow_table(void)
{
uint32_t i, j;
+ int ret = 0;
- for (i = 0, j = 0; i < APP_FLOWS_MAX; i ++, j = (j + 1) %
RTE_DIM(PARAMS)){
- FUNC_CONFIG(&app_flows[i], &PARAMS[j]);
- }
+ for (i = 0, j = 0; i < APP_FLOWS_MAX;
+ i ++, j = (j + 1) % RTE_DIM(PARAMS))
+ ret |= FUNC_CONFIG(&app_flows[i], &PARAMS[j]);
+
+ return ret;
}
static inline void
@@ -381,7 +384,9 @@ main(int argc, char **argv)
rte_eth_promiscuous_enable(port_tx);
/* App configuration */
- app_configure_flow_table();
+ ret = app_configure_flow_table();
+ if (ret < 0)
+ rte_exit(EXIT_FAILURE, "Invalid configure flow table\n");
/* Launch per-lcore init on every lcore */
rte_eal_mp_remote_launch(main_loop, NULL, CALL_MASTER);
diff --git a/examples/qos_meter/main.h b/examples/qos_meter/main.h
index 530bf69..54867dc 100644
--- a/examples/qos_meter/main.h
+++ b/examples/qos_meter/main.h
@@ -51,7 +51,7 @@ enum policer_action
policer_table[e_RTE_METER_COLORS][e_RTE_METER_COLORS] =
#if APP_MODE == APP_MODE_FWD
#define FUNC_METER(a,b,c,d) color, flow_id=flow_id, pkt_len=pkt_len, time=time
-#define FUNC_CONFIG(a,b)
+#define FUNC_CONFIG(a, b) 0
#define PARAMS app_srtcm_params
#define FLOW_METER int
--
1.9.1
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
[dpdk-dev] perfomance of rte_lpm rule subsystem
On Tue, 19 Apr 2016 14:11:11 +0300 ? ??? wrote: > Hi. > > Doing some test with rte_lpm (adding/deleting bgp full table rules) I > noticed that > rule subsystem is very slow even considering that probably it was never > designed for using > in a data forwarding plane. So I want to propose some changes to the "rule" > subsystem. > > I reimplemented rule part ot the lib using rte_hash, and perfomance of > adding/deleted routes have increased dramatically. > If increasing speed of adding deleting routes makes sence for anybody else > I would like to discuss my patch. > The patch also include changes that make next_hop 64 bit, so please just > ignore them. The rule changes are in the following > functions only: > > rte_lpm2_create > > rule_find > rule_add > rule_delete > find_previous_rule > delete_depth_small > delete_depth_big > > rte_lpm2_add > rte_lpm2_delete > rte_lpm2_is_rule_present > rte_lpm2_delete_all > We forked LPM back several versions ago. I sent the patches to use BSD red-black tree for rules but the patches were ignored. mostly because it broke ABI.
[dpdk-dev] [PATCH] l2fwd-crypto: fix supported key size check
Tested-by: Min Cao
- Tested Commit: b3b9719f18ee83773c6ed7adda300c5ac63c37e9
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 1 cases, 1 passed, 0 failed
- test case 1: l2fwd-crypto with 64 bytes auth_key
Total 1 cases, 1 passed, 0 failed
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Tuesday, April 12, 2016 6:04 PM
To: dev at dpdk.org
Cc: Doherty, Declan; De Lara Guarch, Pablo
Subject: [dpdk-dev] [PATCH] l2fwd-crypto: fix supported key size check
When initializing crypto devices within the app, the provided key sizes are
checked against the supported sizes from the crypto device capabilities.
When the supported sizes are not a range, but a single value, the check may
become an infinite loop (when size is not supported).
Fixes: a061e50a0d97 ("examples/l2fwd-crypto: fix ambiguous input key size")
Signed-off-by: Pablo de Lara
---
examples/l2fwd-crypto/main.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c index
d4e2d8d..e273f2f 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1486,6 +1486,15 @@ check_supported_size(uint16_t length, uint16_t min,
uint16_t max, {
uint16_t supp_size;
+ /* Single value */
+ if (increment == 0) {
+ if (length == min)
+ return 0;
+ else
+ return -1;
+ }
+
+ /* Range of values */
for (supp_size = min; supp_size <= max; supp_size += increment) {
if (length == supp_size)
return 0;
--
2.5.5
[dpdk-dev] rte_hash_del_key crash in multi-process environment
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ??
> Sent: Tuesday, April 19, 2016 5:58 AM
> To: De Lara Guarch, Pablo
> Cc: Thomas Monjalon; Gonzalez Monroy, Sergio; dev at dpdk.org; Dhana
> Eadala; Richardson, Bruce; Qiu, Michael
> Subject: [dpdk-dev] rte_hash_del_key crash in multi-process environment
>
> Hi all,
>
>
> In the multi-process environment, before I met a bug when calling
> rte_hash_lookup_with_hash. Using Dhana's patch fixed my problem. Now I
> need to remove the flow in the multi-process environment, the system gets
> crashed when calling rte_hash_del_key function. The following is the gdb
> trace. Does anybody meet this problem or know how to fix it?
First of all, another fix for the multi-process support was implemented and
merged for 16.04 release,
so take a look at it, if you can.
Regarding the rte_hash_del_key() function, you should use
rte_hash_del_key_with_hash,
if you want to use it in a multi-process environment (as you did for the lookup
function).
Thanks,
Pablo
>
>
>
>
> Program received signal SIGILL, Illegal instruction.
>
> 0x0048a0dd in rte_port_ring_reader_frag_free
> (port=0x7ffe113d4100) at /home/zhangwei1984/timopenNetVM/dpdk-
> 2.2.0/lib/librte_port/rte_port_frag.c:266
>
> 266return -1;
>
> (gdb) bt
>
> #0 0x0048a0dd in rte_port_ring_reader_frag_free
> (port=0x7ffe113d4100) at /home/zhangwei1984/timopenNetVM/dpdk-
> 2.2.0/lib/librte_port/rte_port_frag.c:266
>
> #1 0x0049c537 in rte_hash_del_key (h=0x7ffe113d4100,
> key=0x7ffe092e1000)
>
>at /home/zhangwei1984/timopenNetVM/dpdk-
> 2.2.0/lib/librte_hash/rte_cuckoo_hash.c:917
>
> #2 0x0043716a in onvm_ft_remove_key (table=0x7ffe113c3e80,
> key=0x7ffe092e1000) at /home/zhangwei1984/onvm-shared-
> cpu/onvm/shared/onvm_flow_table.c:160
>
> #3 0x0043767e in onvm_flow_dir_del_and_free_key
> (key=0x7ffe092e1000) at /home/zhangwei1984/onvm-shared-
> cpu/onvm/shared/onvm_flow_dir.c:144
>
> #4 0x00437619 in onvm_flow_dir_del_key (key=0x7ffe092e1000) at
> /home/zhangwei1984/onvm-shared-
> cpu/onvm/shared/onvm_flow_dir.c:128
>
> #5 0x00423ded in remove_flow_rule (idx=3) at
> /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:130
>
> #6 0x00423e44 in clear_stat_remove_flow_rule
> (nf_info=0x7fff3e652100) at /home/zhangwei1984/onvm-shared-
> cpu/examples/flow_dir/flow_dir.c:145
>
> #7 0x004247e3 in alloc_nfs_install_flow_rule (services=0xd66e90
> , pkt=0x7ffe13f56400)
>
>at /home/zhangwei1984/onvm-shared-
> cpu/examples/flow_dir/flow_dir.c:186
>
> #8 0x00424bdb in packet_handler (pkt=0x7ffe13f56400,
> meta=0x7ffe13f56440) at /home/zhangwei1984/onvm-shared-
> cpu/examples/flow_dir/flow_dir.c:294
>
> #9 0x0043001d in onvm_nf_run (info=0x7fff3e651b00,
> handler=0x424b21 ) at /home/zhangwei1984/onvm-
> shared-cpu/onvm/onvm_nf/onvm_nflib.c:462
>
> #10 0x00424cc2 in main (argc=3, argv=0x7fffe660) at
> /home/zhangwei1984/onvm-shared-cpu/examples/flow_dir/flow_dir.c:323
>
>
>
>
>
>
>
>
> At 2016-03-23 03:53:43, "De Lara Guarch, Pablo"
> wrote:
> >Hi Thomas,
> >
> >> -Original Message-
> >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> >> Sent: Tuesday, March 22, 2016 11:42 AM
> >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio
> >> Cc: dev at dpdk.org; Dhana Eadala; Richardson, Bruce; Qiu, Michael
> >> Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in
> multi-
> >> process environment
> >>
> >> Hi,
> >>
> >> Pablo, Sergio, please could you help with this issue?
> >
> >I agree this is not the best way to fix this. I will try to have a fix
> >without
> having to use ifdefs.
> >
> >Thanks,
> >Pablo
> >>
> >> 2016-03-13 22:16, Dhana Eadala:
> >> > We found a problem in dpdk-2.2 using under multi-process
> environment.
> >> > Here is the brief description how we are using the dpdk:
> >> >
> >> > We have two processes proc1, proc2 using dpdk. These proc1 and proc2
> >> are
> >> > two different compiled binaries.
> >> > proc1 is started as primary process and proc2 as secondary process.
> >> >
> >> > proc1:
> >> > Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash
> >> structure.
> >> > As part of this, this api initalized the rte_hash structure and set the
> >> > srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1
> >> address space.
> >> >
> >> > proc2:
> >> > calls srcHash = rte_hash_find_existing("src_hash_name").
> >> > This function call returns the rte_hash created by proc1.
> >> > This srcHash->rte_hash_cmp_eq still points to the address of
> >> > memcmp() from proc1 address space.
> >> > Later proc2 calls
> >> > rte_hash_lookup_with_hash(srcHash, (const void*) &key, key.sig);
> >> > rte_hash_lookup_with_hash() invokes __rte_hash_lookup_with_hash(),
> >> > which in turn calls h->rte_hash_cmp_eq(key, k->key, h->key_len).
> >> > This leads to a cr
[dpdk-dev] [PATCH] i40e: fix packet stats getting
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, April 19, 2016 2:11 PM
> To: Richardson, Bruce
> Cc: dev at dpdk.org; Wu, Jingjing ; Zhang, Helin
>
> Subject: [PATCH] i40e: fix packet stats getting
>
> The statistics queried by calling rte_eth_stats_get are zero when the API is
> first
> called on the port. The root cause is because of offset_loaded flag is not set
> correctly after device started.
> This patch fixes this issue by resetting statistics at initialization time,
> at the
> meanwhile the resetting process will set offset_loaded flag.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Signed-off-by: Jingjing Wu
Acked-by: Helin Zhang
[dpdk-dev] [PATCH] virtio: fix newline under debug mode
Issue: output of appliations and debug info of DPDK may be mixed up
in same line when enabling below debug options of virtio:
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER
This patch adds "\n" in the tail of definitions like PMD_RX_LOG,
PMD_TX_LOG, and PMD_DRV_LOG, and removes some "\n" when using these
macros.
Signed-off-by: Jianfeng Tan
---
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_logs.h | 6 +++---
drivers/net/virtio/virtio_rxtx.c | 12 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 63a368a..a0ef0a1 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -827,7 +827,7 @@ virtio_mac_table_set(struct virtio_hw *hw,
int err, len[2];
if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_MAC_ADDR)) {
- PMD_DRV_LOG(INFO, "host does not support mac table\n");
+ PMD_DRV_LOG(INFO, "host does not support mac table");
return;
}
diff --git a/drivers/net/virtio/virtio_logs.h b/drivers/net/virtio/virtio_logs.h
index d6c33f7..90a79ea 100644
--- a/drivers/net/virtio/virtio_logs.h
+++ b/drivers/net/virtio/virtio_logs.h
@@ -47,14 +47,14 @@
#ifdef RTE_LIBRTE_VIRTIO_DEBUG_RX
#define PMD_RX_LOG(level, fmt, args...) \
- RTE_LOG(level, PMD, "%s() rx: " fmt , __func__, ## args)
+ RTE_LOG(level, PMD, "%s() rx: " fmt "\n", __func__, ## args)
#else
#define PMD_RX_LOG(level, fmt, args...) do { } while(0)
#endif
#ifdef RTE_LIBRTE_VIRTIO_DEBUG_TX
#define PMD_TX_LOG(level, fmt, args...) \
- RTE_LOG(level, PMD, "%s() tx: " fmt , __func__, ## args)
+ RTE_LOG(level, PMD, "%s() tx: " fmt "\n", __func__, ## args)
#else
#define PMD_TX_LOG(level, fmt, args...) do { } while(0)
#endif
@@ -62,7 +62,7 @@
#ifdef RTE_LIBRTE_VIRTIO_DEBUG_DRIVER
#define PMD_DRV_LOG(level, fmt, args...) \
- RTE_LOG(level, PMD, "%s(): " fmt , __func__, ## args)
+ RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args)
#else
#define PMD_DRV_LOG(level, fmt, args...) do { } while(0)
#endif
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index ef21d8e..2dafebd 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -680,7 +680,7 @@ virtio_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
if (unlikely(virtqueue_kick_prepare(rxvq))) {
virtqueue_notify(rxvq);
- PMD_RX_LOG(DEBUG, "Notified\n");
+ PMD_RX_LOG(DEBUG, "Notified");
}
}
@@ -710,7 +710,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
virtio_rmb();
- PMD_RX_LOG(DEBUG, "used:%d\n", nb_used);
+ PMD_RX_LOG(DEBUG, "used:%d", nb_used);
hw = rxvq->hw;
nb_rx = 0;
@@ -733,13 +733,13 @@ virtio_recv_mergeable_pkts(void *rx_queue,
i++;
- PMD_RX_LOG(DEBUG, "dequeue:%d\n", num);
- PMD_RX_LOG(DEBUG, "packet len:%d\n", len[0]);
+ PMD_RX_LOG(DEBUG, "dequeue:%d", num);
+ PMD_RX_LOG(DEBUG, "packet len:%d", len[0]);
rxm = rcv_pkts[0];
if (unlikely(len[0] < hdr_size + ETHER_HDR_LEN)) {
- PMD_RX_LOG(ERR, "Packet drop\n");
+ PMD_RX_LOG(ERR, "Packet drop");
nb_enqueued++;
virtio_discard_rxbuf(rxvq, rxm);
rxvq->errors++;
@@ -781,7 +781,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
rcv_cnt = rx_num;
} else {
PMD_RX_LOG(ERR,
- "No enough segments for packet.\n");
+ "No enough segments for packet.");
nb_enqueued++;
virtio_discard_rxbuf(rxvq, rxm);
rxvq->errors++;
--
2.1.4
[dpdk-dev] [PATCH] i40evf: Ignore disabled HW CRC strip for Linux PF hosts
> -Original Message- > From: Topel, Bjorn > Sent: Tuesday, April 19, 2016 2:47 AM > To: Zhang, Helin ; David Marchand > > Cc: dev at dpdk.org; Wu, Jingjing > Subject: RE: [dpdk-dev] [PATCH] i40evf: Ignore disabled HW CRC strip for > Linux PF > hosts > > >> Not sure this is the right way to handle it. The driver should > >> return an error rather than silently discard what the application > >> asked. > > > > I also think it should return an error with checking if the host is > > kernel driver, and crc strip is disabled in VF. Thank you David! > > Thanks for reviewing my patch, Helin and David. > > I agree that it's subtle to ignore the error, and just log the error. This is > how > ixgbevf behaves (refer to ixgbevf_dev_configure), so I figured that i40evf > should > behave analogous. > > I'll submit a v2 of the patch that returns an EINVAL and logs the failure. > > Would it make sense to change the ixgbevf_dev_configure as well, in a separate > patch? Yes, I agree with you that ixgbe and i40e should be consistent. Thank you! /Helin > > > >> - > >> - > >> Intel Sweden AB > >> Registered Office: Isafjordsgatan 30B, 164 40 Kista, Stockholm, > >> Sweden Registration Number: 556189-6027 > >> > >> This e-mail and any attachments may contain confidential material for > >> the sole use of the intended recipient(s). Any review or distribution > >> by others is strictly prohibited. If you are not the intended > >> recipient, please contact the sender and delete all copies. > > > > Please, remove this. > > Noted. Will make sure to fix that for future revisions. Thanks! > > > Bj?rn
