Hi, Bruce
Your patch works! I applied the patch, and the problem disappeared.
Thanks ^_^
/ChenXiaodong
> Date: Wed, 22 Apr 2015 14:34:17 +0100
> From: bruce.richardson at intel.com
> To: ch.xd at live.cn
> CC: pablo.de.lara.guarch at intel.com; dev at dpdk.org
> Subject: Re: [dpdk-dev] problem: Ca
Try going here and you can input your email and password to unsubscribe.
http://dpdk.org/ml/listinfo/dev
Or just here for all email lists:
http://dpdk.org/ml
Regards,
++Keith
On 4/22/15, 5:23 PM, "Vipin Agrawal" wrote:
>What do I need to do to not receive any more emails?
>
>Thanks,
>Vipin
What do I need to do to not receive any more emails?
Thanks,
Vipin
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise confidential information. If you have received it in
error, please notify the sender im
Incidentally, this information is contained in the List-Unsubscribe
header which Mailman adds to the email headers of every message. "View
message source" for the full set (I always use List-Id for mailing list
filters).
Dave.
On 04/22/2015 07:10 PM, Wiles, Keith wrote:
> Try going here and you c
Thanks for you reply! There is actually only one NUMA node. here is what the
commands return:
[root at test dpdk-2.0.0]# tools/cpu_layout.py
Core and Socket Information (as reported by '/proc/cpuinfo')
Hi, every one
Is there any one who can help me ? I'm new to DPDK, here is a problem that I
don't know how to deal with. The program is running on an machine with two
Intel 82576 NICs. One of the NICs is binded with the uio_pci_generic
driver?1024 2M hugepages have been setup.
Any suggestion
On Wed, Apr 22, 2015 at 05:39:40PM -0700, Stephen Hemminger wrote:
> In our application we already use setname and have a policy for what the
> names look like.
> This won't help
Not everybody does.
In our application we already use setname and have a policy for what the
names look like.
This won't help
On Wed, Apr 22, 2015 at 5:19 PM, Matthew Hall wrote:
> On Wed, Apr 22, 2015 at 03:57:44PM -0700, Stephen Hemminger wrote:
> > Since it possible to have multiple DPDK applications in same env
On Wed, Apr 22, 2015 at 03:57:44PM -0700, Stephen Hemminger wrote:
> Since it possible to have multiple DPDK applications in same environment,
> and the thread name size is so limited, I wonder if this is a good idea.
Why not try to opportunistically make the code easier to debug? DPDK is not
alw
Enabled Doxygen option to add links to the source code
in documented entities.
Signed-off-by: John McNamara
---
doc/api/doxy-api.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index da03e9b..c445f80 100644
--- a/doc/api/doxy-api.conf
+++ b/
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John McNamara
> Sent: Wednesday, April 22, 2015 5:10 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: link doxygen docs to source code
>
> Enabled Doxygen option to add links to the source code in d
> -Original Message-
> From: Mcnamara, John
> Sent: Wednesday, April 22, 2015 5:10 PM
> To: dev at dpdk.org
> Cc: Mcnamara, John
> Subject: [PATCH] doc: link doxygen docs to source code
>
> Enabled Doxygen option to add links to the source code in documented
> entities.
Hi,
This patch i
On Wed, 22 Apr 2015 14:05:48 -0700
Ravi Kerur wrote:
> Add code to set names to threads via pthread APIs.
> In Linux corresponding _getname_ is available, however, FreeBSD
> doesn't have corresponding _get_name API available yet. Hence _getname_
> is not yet used in the code.
>
> Ravi Kerur (1):
On Wed, Apr 22, 2015 at 09:27:42AM -0700, Eric Kinzie wrote:
> From: Eric Kinzie
>
> Provide functions to allow an external 802.3ad state machine to transmit
> and recieve LACPDUs and to set the collection/distribution flags on
> slave interfaces.
>
> Signed-off-by: Eric Kinzie
> ---
> l
It wouldn't check the configured maximum packet length, and then
the scattered receiving function wouldn't be selected at all even
if it wants to receive a jumbo frame. The fix is to select the
correct RX function according to the configurations.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40
Does anybody have any input or comments on this?
> -Original Message-
> From: O'Driscoll, Tim
> Sent: Thursday, April 16, 2015 11:39 AM
> To: dev at dpdk.org
> Subject: Beyond DPDK 2.0
>
> Following the launch of DPDK by Intel as an internal development
> project, the launch of dpdk.org
On Wed, Apr 22, 2015 at 07:36:59PM +0800, ChenXiaodong wrote:
> Thanks for you reply! There is actually only one NUMA node. here is what the
> commands return:
>
Hi,
there seems to be a mismatch in terms of the numa node the memory is reported
as being on (node 0) and the numa node that the co
Using the "physical_package_id" as a fallback for determining the
numa node of a core tends to be unreliable. Fix this by using a
detection routine which reads the numa information from
/sys/devices/system/node and just returns a numa node of 0 on
failure.
Signed-off-by: Bruce Richardson
---
lib
use pthread_setname_np and pthread_set_name_np for Linux and
FreeBSD respectively.
Restrict pthread name len to 16 via config for both Linux and FreeBSD.
Testing:
Linux:
Compiled with both clang and gcc (x86_64-native-linuxapp-gcc and
x86_64-native-linuxapp-clang).
Compiled examples/vhost.
make te
Add code to set names to threads via pthread APIs.
In Linux corresponding _getname_ is available, however, FreeBSD
doesn't have corresponding _get_name API available yet. Hence _getname_
is not yet used in the code.
Ravi Kerur (1):
Use pthread_setname apis
config/common_bsdapp
On 04/22/15 08:28, Zhang, Helin wrote:
> Vlad, how about the new elements added? E.g. rx_vec_allowed was added in
> struct ixgbe_hw in ixgbe_type.h.
If memory (and sight) serves me well this wasn't in this series... I
suggest we move to the relevant thread ("bug fixes in the ixgbe PF PMD
Rx f
On Wed, 22 Apr 2015 08:59:51 +
"Burakov, Anatoly" wrote:
> Hi Stephen,
>
> > > Hi Stephen,
> > >
> > > > The VFIO_PRESENT #define was a landmine and we hit it.
> > > > The DPDK has a config system and it should be used rather than
> > > > silently dropping a feature during build only to have
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, April 22, 2015 10:57 AM
> To: dev at dpdk.org
> Cc: Ananyev, Konstantin; zoltan.kiss at linaro.org; Richardson, Bruce;
> nhorman at tuxdriver.com; olivier.matz at 6wind.com
> Subject: [PATCH v
Verify that we can attach a mbuf to another one that does not have
the same data room size and priv_size.
Signed-off-by: Olivier Matz
---
app/test/test_mbuf.c | 124 ++-
1 file changed, 123 insertions(+), 1 deletion(-)
diff --git a/app/test/test_m
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
app/test/test_mbuf.c | 28
1 file changed, 28 insertions(+)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index a16ec53..68564ee 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -126,6 +
Check that the data in the cloned mbuf is the same than in the
reference mbuf.
Check that the reference counter is incremented for each segment.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
app/test/test_mbuf.c | 39 +++
1 file changed, 39 insertions
It's better to name the mbuf 'm' instead of 'mc' as it's not a clone.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
app/test/test_mbuf.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 4774
Remove one limitation of rte_pktmbuf_attach(): "mbuf we're attaching to
must be direct".
Now, when we attach to an indirect mbuf:
- copy the all relevant fields (addr, len, offload, ...) as before
- get the pointer to the mbuf that embeds the data buffer (direct mbuf),
and increase the reference
Add a new priv_size field in mbuf structure that should
be initialized at mbuf pool creation. This field contains the
size of the application private data in mbufs.
Introduce new static inline functions rte_mbuf_from_indirect()
and rte_mbuf_to_baddr() to replace the existing macros, which
take the
When it's possible, use the new helper to create the mbuf pools.
Most of the patch is trivial, except for the following files that
have some specifics (indirect mbufs):
- ip_fragmentation
- ip_pipeline
- ipv4_multicast
- vhost
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
app/test-pipel
Add a new wrapper to rte_mempool_create() to simplify the creation
of a packet mbuf pool.
This wrapper can be used if there is no specific mempool flags, and
no specific mbuf or pool constructor function, which is most of the
use cases.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
doc
The rte_pktmbuf_pool_init() and rte_pktmbuf_init() functions now
support to have a non-hardcoded buffer length. We can remove the
specific functions used in testpmd and replace them by the standard
ones.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
app/test-pmd/testpmd.c | 74 +
Allow the user to use the default rte_pktmbuf_init() function even
if the mbuf private size is not 0.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
lib/librte_mbuf/rte_mbuf.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.c b/l
This code retrieving the pool private area is duplicated in many
places, we can use of function for it.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
lib/librte_ether/rte_ethdev.c| 4 +--
lib/librte_mbuf/rte_mbuf.h | 41
li
The mbuf pool private area must always be populated in a mbuf pool.
The applications or drivers may expect that for a mbuf pool, the mbuf
pool private area (mbuf_data_room_size and mbuf_priv_size) are
properly filled.
Signed-off-by: Olivier Matz
Acked-by: Neil Horman
---
examples/ip_fragmentati
Deduct the mbuf data room size from mempool->elt_size and priv_size,
instead of using an hardcoded value that is not related to the real
buffer size.
To use rte_pktmbuf_pool_init(), the user can either:
- give a NULL parameter to rte_pktmbuf_pool_init(): in this case, the
private size is assumed
The first objective of this series is to fix the support of indirect
mbufs when the application reserves a private area in mbufs. It also
removes the limitation that rte_pktmbuf_clone() is only allowed on
direct (non-cloned) mbufs. The series also contains some enhancements
and fixes in the mbuf ar
3KS, Olga,
I try you suggestion and it can't start yet. My Mellanox ConnectX-3 card
is "ConnectX?-3 VPI adapter card, dual-port QSFP, FDR IB (56Gb/s) and
40/56GbE, PCIe3.0 x8 8GT/s, tall bracket,RoHS R6". May be the problem?
# mstflint -d 02:00.0 q
Image type: FS2
FW Version:
Hi ,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ChenXiaodong
> Sent: Wednesday, April 22, 2015 11:33 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] problem: Cannot allocate memzone for ethernet port
> data
>
> Hi, every one
>
> Is there any one who can
On Tue, Apr 21, 2015 at 12:13:22PM -0700, Ravi Kerur wrote:
> On Tue, Apr 21, 2015 at 7:36 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Sat, Apr 18, 2015 at 12:43:07PM -0700, Ravi Kerur wrote:
> > > Changes in v6
> > > Split eal_common_system.c and eal_common_runtime.c i
On Tue, Apr 21, 2015 at 10:44:54AM -0700, Matthew Hall wrote:
> On Tue, Apr 21, 2015 at 10:27:48AM +0100, Bruce Richardson wrote:
> > Can you perhaps comment on the use-case where you find this binding
> > limiting? Modern platforms have multiple NUMA nodes, but they also
> > generally
> > have
On Tue, Apr 21, 2015 at 12:28:24PM -0700, Ravi Kerur wrote:
> On Tue, Apr 21, 2015 at 7:25 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Sat, Apr 18, 2015 at 12:43:06PM -0700, Ravi Kerur wrote:
> > > Changes in v6
> > > Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c
On 2015-04-20 16:37, Ravi Kumar Iyer wrote:
> Hi,
> We were doing some code optimizations , running DPDK based applications, and
> chanced upon the rte_rdtsc function [ to read tsc timestamp register value ]
> consuming cpu cycles of the order of 100clock cycles with a delta of upto
> 40cycles a
From: Eric Kinzie
This adds test cases for exercising the external state machine API to
the mode 4 autotest.
Signed-off-by: Eric Kinzie
---
app/test/test_link_bonding_mode4.c | 210 ++--
1 file changed, 201 insertions(+), 9 deletions(-)
diff --git a/app/te
From: Eric Kinzie
Provide functions to allow an external 802.3ad state machine to transmit
and recieve LACPDUs and to set the collection/distribution flags on
slave interfaces.
Signed-off-by: Eric Kinzie
---
lib/librte_pmd_bond/rte_eth_bond_8023ad.c | 173 +
From: Eric Kinzie
The bonding PMD in mode 4 puts all enslaved interfaces into promiscuous
mode in order to receive LACPDUs and must filter unwanted packets
after the traffic has been "collected". Allow broadcast and multicast
through so that ARP and IPv6 neighbor discovery continue to work.
Fix
From: Eric Kinzie
Copy all needed fields from the mode8023ad_private structure in
bond_mode_8023ad_conf_get(). This help ensure that a subsequent call
to rte_eth_bond_8023ad_setup() is not passed uninitialized data that
would result in either incorrect behavior or a failed sanity check.
This patchset makes a couple of small corrections to the bonding driver
and introduces the ability to use an external state machine for mode
4 operation.
Changes in v2:
. eliminate external_sm field in 802.3ad configuration
(rte_eth_bond_8023ad_conf).
. stop bonding device before changing
Hi Stephen,
> > Hi Stephen,
> >
> > > The VFIO_PRESENT #define was a landmine and we hit it.
> > > The DPDK has a config system and it should be used rather than
> > > silently dropping a feature during build only to have it fail at run time.
> > >
> > > If VFIO is configured, and the kernel heade
On Wed, 22 Apr 2015 14:31:55 +0100
Bruce Richardson wrote:
> Using the "physical_package_id" as a fallback for determining the
> numa node of a core tends to be unreliable. Fix this by using a
> detection routine which reads the numa information from
> /sys/devices/system/node and just returns a
On Wed, 22 Apr 2015 14:34:17 +0100
Bruce Richardson wrote:
> On Wed, Apr 22, 2015 at 07:36:59PM +0800, ChenXiaodong wrote:
> > Thanks for you reply! There is actually only one NUMA node. here is what
> > the commands return:
> >
>
> Hi,
>
> there seems to be a mismatch in terms of the numa n
On Wed, Apr 22, 2015 at 2:03 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Tue, Apr 21, 2015 at 12:28:24PM -0700, Ravi Kerur wrote:
> > On Tue, Apr 21, 2015 at 7:25 AM, Bruce Richardson <
> > bruce.richardson at intel.com> wrote:
> >
> > > On Sat, Apr 18, 2015 at 12:43:06PM -07
On Wed, Apr 22, 2015 at 2:21 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Tue, Apr 21, 2015 at 12:13:22PM -0700, Ravi Kerur wrote:
> > On Tue, Apr 21, 2015 at 7:36 AM, Bruce Richardson <
> > bruce.richardson at intel.com> wrote:
> >
> > > On Sat, Apr 18, 2015 at 12:43:07PM -07
This patch replaces memcmp and strncmp in librte_hash with rte_memcmp which
is implemented with AVX/SSE instructions.
Preliminary results on Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, Ubuntu
14.04 x86_64 shows
1 second improvement when hash key length <= 64
4 seconds improvement when hash key lengt
Background:
After preliminary discussion with John (Zhihong) and Tim from Intel it was
decided that it would be beneficial to use AVX/SSE instructions for memcmp
similar to memcpy being implemeneted. In addition, we decided to use
librte_hash as a test candidate to test both functionality and perfo
This does a good job of stating the need for action without getting into
the details.
Perhaps this would be better resolved by some more interactive discussion.
I know it is hard to all get together, but there needs to be more some more
creative and focused
thought on this. A phone conference is ju
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, April 20, 2015 11:00 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [RFC PATCH] ethdev: remove old flow director API
>
> 2015-04-20 14:32, Wu, Jingjing:
> > From: Thomas Monjalo
On 04/22/15 04:23, Zhang, Helin wrote:
> Hi Vlad
>
> I have a concern about the code changes you added in ixgbe_type.h.
Helin, v9 of this series has addressed exactly this "issue" all new
macros have been moved to ixgbe_ethdev.h.
> For ixgbe, all source files in librte_pmd_ixgbe/ixgbe, except
Tested-by: Min Cao
Patch name: [PATCH 00/18] i40e base driver update
Test Flag: Tested-by
Tester name:min.cao at intel.com
Result summary: total 60 cases, 60passed, 0 failed
Test Case 1:
Name: ipfrag
Vlad, how about the new elements added? E.g. rx_vec_allowed was added in struct
ixgbe_hw in ixgbe_type.h.
Regards,
Helin
> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Wednesday, April 22, 2015 12:59 PM
> To: Zhang, Helin; dev at dpdk.org
> Cc:
On 4/8/2015 6:03 PM, Bernard Iremonger wrote:
> This patch depends on the Port Hotplug Framework.
> It implements the eth_dev_uninit functions for rte_ixgbe_pmd and
> rte_ixgbevf_pmd.pmd.
>
> Signed-off-by: Bernard Iremonger
> ---
Tested-by: Michael Qiu
> lib/librte_pmd_ixgbe/ixgbe_ethdev.c |
The ?base driver? was not developed for DPDK only. So any code changes
specifically for DPDK shouldn?t be part of it. We should think of moving it to
other place than that ?base driver?.
For the bug fixes, I think it is feasible to report the issue back to the ?base
driver? owners, and get it on
Hi Vlad
I have a concern about the code changes you added in ixgbe_type.h.
For ixgbe, all source files in librte_pmd_ixgbe/ixgbe, except ixgbe_osdep.h
were called as "base driver", which was not developed by DPDK developers, and
released by the other team. We never modify any code in those base
63 matches
Mail list logo
