On Fri, 26 Jul 2013, jinho hwang wrote:
>> Thanks for the tips. I don't think I'm running out of mbufs, but I'll check
>> that again. I am using these values from one of the examples - which claim
>> to be correct for the 82599EB.
>>
>> /*
>> * These default values are optimized for use with th
On Fri, Jul 26, 2013 at 4:04 PM, Scott Talbert wrote:
> On Fri, 26 Jul 2013, Stephen Hemminger wrote:
>
>>> I'm writing an application using DPDK that transmits a large number of
>>> packets (it doesn't receive any). When I transmit at 2 Gb/sec,
>>> everything
>>> will run fine for several second
The new release can be downloaded here:
http://dpdk.org/browse/dpdk/tag/?id=v1.3.1r2
Changelog
- fixes for:
* KNI build
* detection of CPU cores
- enhancements:
* real "make install"
* improved malloc library
26/07/2013 16:57, Damien Millescamps :
> On 07/26/2013 04:56 PM, Thomas Monjalon wrote:
> > In some cases, it is possible to not use hugepages.
> > So a simple malloc is used to initialize DPDK memory.
> >
> > Signed-off-by: Thomas Monjalon
> > ---
> >
> > lib/librte_eal/linuxapp/eal/eal_memory
26/07/2013 16:59, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 04:39:13PM +0200, Damien Millescamps wrote:
> > In --no-huge mode, mempool provides objects with their associated
> > header/trailer fitting in a standard page (usually 4KB).
> > This means all non-UIO driver should work correctly in th
26/07/2013 16:59, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 04:39:12PM +0200, Damien Millescamps wrote:
> > Allow external libraries and applications to know if hugepages
> > are enabled.
> >
> > Signed-off-by: Thomas Monjalon
> > Signed-off-by: Damien Millescamps
> > ---
> >
> > lib/librte
26/07/2013 16:56, Damien Millescamps :
> On 07/26/2013 04:35 PM, Adrien Mazarguil wrote:
> > When huge pages are disabled, memory is allocated for a single, undefined
> > CPU socket using malloc(), causing rte_memzone_reserve_aligned() to fail
> > most of the time.
> >
> > This patch causes that m
26/07/2013 16:55, Thomas Monjalon :
> From: Olivier Matz
>
> Before this patch, rte_malloc(SOCKET_ID_ANY) was equivalent to
> rte_malloc(this_socket). If the user specifies SOCKET_ID_ANY, it means that
> memory can be allocated on any socket. So fix the behavior of rte_malloc()
> in order to do t
26/07/2013 16:54, Thomas Monjalon :
> From: Olivier Matz
>
> Remove an error log in memzone_reserve_aligned_thread_unsafe().
> It is up to the caller to log the error, and this is already done
> in DPDK code (especially in network drivers).
>
> Signed-off-by: Olivier Matz
> Acked-by: Thomas Mon
On Fri, Jul 26, 2013 at 04:39:13PM +0200, Damien Millescamps wrote:
> In --no-huge mode, mempool provides objects with their associated
> header/trailer fitting in a standard page (usually 4KB).
> This means all non-UIO driver should work correctly in this mode,
> since UIO drivers allocate ring si
On Fri, Jul 26, 2013 at 04:39:12PM +0200, Damien Millescamps wrote:
> Allow external libraries and applications to know if hugepages
> are enabled.
>
> Signed-off-by: Thomas Monjalon
> Signed-off-by: Damien Millescamps
> ---
> lib/librte_eal/common/include/rte_eal.h | 13 -
> lib/
On 07/26/2013 04:56 PM, Thomas Monjalon wrote:
> In some cases, it is possible to not use hugepages.
> So a simple malloc is used to initialize DPDK memory.
>
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On 07/26/2013 04:35 PM, Adrien Mazarguil wrote:
> When huge pages are disabled, memory is allocated for a single, undefined
> CPU socket using malloc(), causing rte_memzone_reserve_aligned() to fail
> most of the time.
>
> This patch causes that memory to use SOCKET_ID_ANY instead of 0, and allow
>
In some cases, it is possible to not use hugepages.
So a simple malloc is used to initialize DPDK memory.
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/linuxapp/eal/eal_memory.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
b
From: Olivier Matz
Before this patch, rte_malloc(SOCKET_ID_ANY) was equivalent to
rte_malloc(this_socket). If the user specifies SOCKET_ID_ANY, it means that
memory can be allocated on any socket. So fix the behavior of rte_malloc() in
order to do that. The current CPU socket is still the default
From: Olivier Matz
Remove an error log in memzone_reserve_aligned_thread_unsafe().
It is up to the caller to log the error, and this is already done
in DPDK code (especially in network drivers).
Signed-off-by: Olivier Matz
Acked-by: Thomas Monjalon
---
lib/librte_eal/common/eal_common_memzone
26/07/2013 16:25, Didier Pallard :
> Get physical address of any rte_malloc allocated buffer using
> function rte_malloc_virt2phy(addr).
> The rte_memzone pointer is now stored in each allocated memory block
> header to allow simple computation of physical address of a block
> using the memzone it
26/07/2013 16:37, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 04:06:40PM +0200, Thomas Monjalon wrote:
> > Some functions don't modify their parameter which should be marked as
> > const.
> >
> > Signed-off-by: Thomas Monjalon
> > ---
> >
> > lib/librte_malloc/malloc_elem.h |6 +++---
> >
In --no-huge mode, mempool provides objects with their associated
header/trailer fitting in a standard page (usually 4KB).
This means all non-UIO driver should work correctly in this mode,
since UIO drivers allocate ring sizes that cannot fit in a page.
Extend rte_mempool_virt2phy to obtain the co
Allow external libraries and applications to know if hugepages
are enabled.
Signed-off-by: Thomas Monjalon
Signed-off-by: Damien Millescamps
---
lib/librte_eal/common/include/rte_eal.h | 13 -
lib/librte_eal/linuxapp/eal/eal.c |4
2 files changed, 16 insertions(+),
This set of patch permits to use the --no-huge option to create valid mempools.
However, drivers necessitating a physically contiguous memory larger than a
standard
page won't work in this mode.
Only vmxnet3-usermap will work in this mode among the available open source PMD.
This can be useful fo
On Fri, Jul 26, 2013 at 04:06:40PM +0200, Thomas Monjalon wrote:
> Some functions don't modify their parameter which should be marked as const.
>
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_malloc/malloc_elem.h |6 +++---
> lib/librte_malloc/malloc_heap.c |2 +-
> lib/librte_mall
When huge pages are disabled, memory is allocated for a single, undefined
CPU socket using malloc(), causing rte_memzone_reserve_aligned() to fail
most of the time.
This patch causes that memory to use SOCKET_ID_ANY instead of 0, and allow
it to be used in place of any socket ID specified by user.
Get physical address of any rte_malloc allocated buffer using
function rte_malloc_virt2phy(addr).
The rte_memzone pointer is now stored in each allocated memory block
header to allow simple computation of physical address of a block
using the memzone it comes from.
Declaration of memzone in malloc_
Some functions don't modify their parameter which should be marked as const.
Signed-off-by: Thomas Monjalon
---
lib/librte_malloc/malloc_elem.h |6 +++---
lib/librte_malloc/malloc_heap.c |2 +-
lib/librte_malloc/malloc_heap.h |2 +-
lib/librte_malloc/rte_malloc.c |4 ++--
lib/li
On Fri, 26 Jul 2013, Stephen Hemminger wrote:
>> I'm writing an application using DPDK that transmits a large number of
>> packets (it doesn't receive any). When I transmit at 2 Gb/sec, everything
>> will run fine for several seconds (receiver is receiving at correct rate),
>> but then the NIC ap
Hi,
I'm writing an application using DPDK that transmits a large number of
packets (it doesn't receive any). When I transmit at 2 Gb/sec, everything
will run fine for several seconds (receiver is receiving at correct rate),
but then the NIC appears to get 'stuck' and doesn't transmit any more
26/07/2013 15:13, Thomas Monjalon :
> The current "make install" rule don't install anything.
> It builds one or more targets with different configurations.
>
> These patches allow to install only files needed to build and run a DPDK
> appplication. The old behaviour is kept for compatibility and
26/07/2013 13:55, Thomas Monjalon :
> From: Ivan Boule
>
> 1) In the EAL initialization phase, invoke the function rte_eal_cpu_init
>to detect the set of running cores (and enable them by default) before
>processing the [enabled] core mask option that is performed during the
>parsing
26/07/2013 14:12, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 01:34:00PM +0200, Thomas Monjalon wrote:
> > Adding or subtracting a value to a pointer makes a new pointer
> > of unknown type.
> > So typeof() is replaced by (void*) in RTE_PTR_ADD() and RTE_PTR_SUB().
> >
> > But RTE_PTR_ALIGN_* mac
26/07/2013 13:25, Adrien Mazarguil :
> The netdev_features_t typedef appeared in Linux 3.3, but checking the
> kernel version isn't enough with some distributions (such as Debian
> Wheezy) that backported it into 3.2, causing a compilation failure due to
> redefinition.
>
> Since the presence of a
26/07/2013 14:12, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 11:51:15AM +0200, Thomas Monjalon wrote:
> > C90 compilers forbid mixed declaration and code.
> >
> > Signed-off-by: Thomas Monjalon
> > ---
> >
> > lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c |7 +--
> > 1 file c
26/07/2013 14:11, Adrien Mazarguil :
> On Fri, Jul 26, 2013 at 11:49:59AM +0200, Thomas Monjalon wrote:
> > From: Jean-Mickael Guerin
> >
> > This is not supported, disable to avoid compilation error like:
> > lib/librte_eal/linuxapp/kni/kni_misc.c:304:2: error:
> > format '%llx'
From: Olivier Matz
This will install the binary sdk (bin + modules + libs + headers + mk)
in the specified directory.
This directory can be used as RTE_SDK by external applications.
Signed-off-by: Olivier Matz
Acked-by: Thomas Monjalon
---
doc/build-sdk-quick.txt | 13 +++--
mk/rte.
From: Olivier Matz
This allows the user to prepare a configuration with make config
before using make install.
Signed-off-by: Olivier Matz
Acked-by: Thomas Monjalon
---
mk/rte.sdkinstall.mk |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte
From: Olivier Matz
This variable $(O) can be used to specify a build directory
when doing an "install" procedure. The default is ".", which
means that targets will be built in the source dpdk.
This option is useful to compile outside of the source tree that may be
read-only.
Signed-off-by: Oliv
The current "make install" rule don't install anything.
It builds one or more targets with different configurations.
These patches allow to install only files needed to build and run a DPDK
appplication.
The old behaviour is kept for compatibility and the new behaviour is
a second stage triggered
On Fri, Jul 26, 2013 at 01:55:49PM +0200, Thomas Monjalon wrote:
> From: Ivan Boule
>
> 1) In the EAL initialization phase, invoke the function rte_eal_cpu_init
>to detect the set of running cores (and enable them by default) before
>processing the [enabled] core mask option that is perfo
On Fri, Jul 26, 2013 at 01:34:00PM +0200, Thomas Monjalon wrote:
> Adding or subtracting a value to a pointer makes a new pointer
> of unknown type.
> So typeof() is replaced by (void*) in RTE_PTR_ADD() and RTE_PTR_SUB().
>
> But RTE_PTR_ALIGN_* macros have in their explicit API to return a pointe
On Fri, Jul 26, 2013 at 11:51:15AM +0200, Thomas Monjalon wrote:
> C90 compilers forbid mixed declaration and code.
>
> Signed-off-by: Thomas Monjalon
> ---
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Acked-by: Adrie
On Fri, Jul 26, 2013 at 11:49:59AM +0200, Thomas Monjalon wrote:
> From: Jean-Mickael Guerin
>
> This is not supported, disable to avoid compilation error like:
> lib/librte_eal/linuxapp/kni/kni_misc.c:304:2: error:
> format '%llx' expects argument of type 'long long unsigned
From: Ivan Boule
1) In the EAL initialization phase, invoke the function rte_eal_cpu_init
to detect the set of running cores (and enable them by default) before
processing the [enabled] core mask option that is performed during the
parsing of EAL arguments.
2) In the function rte_eal_cp
Adding or subtracting a value to a pointer makes a new pointer
of unknown type.
So typeof() is replaced by (void*) in RTE_PTR_ADD() and RTE_PTR_SUB().
But RTE_PTR_ALIGN_* macros have in their explicit API to return a pointer
of the same type. Since RTE_PTR_ALIGN_CEIL is based on RTE_PTR_ADD, a
typ
The netdev_features_t typedef appeared in Linux 3.3, but checking the kernel
version isn't enough with some distributions (such as Debian Wheezy) that
backported it into 3.2, causing a compilation failure due to redefinition.
Since the presence of a typedef can't be tested at compile time, this co
On Fri, 26 Jul 2013 15:39:18 -0400 (EDT)
Scott Talbert wrote:
> Hi,
>
> I'm writing an application using DPDK that transmits a large number of
> packets (it doesn't receive any). When I transmit at 2 Gb/sec, everything
> will run fine for several seconds (receiver is receiving at correct rate
C90 compilers forbid mixed declaration and code.
Signed-off-by: Thomas Monjalon
---
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_main.c
b/lib/librte_eal/linuxa
From: Jean-Mickael Guerin
This is not supported, disable to avoid compilation error like:
lib/librte_eal/linuxapp/kni/kni_misc.c:304:2: error:
format '%llx' expects argument of type 'long long unsigned int',
but argument 2 has type 'phys_addr_t' [-Werror=fo
The new releases can be downloaded here:
http://dpdk.org/browse/virtio-net-pmd/tag/?id=v1.1
http://dpdk.org/browse/vmxnet3-usermap/tag/?id=v1.1
These new versions are compatible with DPDK 1.3.1r1.
--
Thomas
26/07/2013 11:05, Adrien Mazarguil :
> On Thu, Jul 25, 2013 at 10:40:56PM +0200, Thomas Monjalon wrote:
> > From: Damien Millescamps
> >
> > API changes in DPDK 1.3:
> > - queue arrays are already allocated by rte_ethdev
> > - queue release must be handled by the PMD
> > - queue struct becomes an
26/07/2013 11:02, Damien Millescamps :
> On 07/25/2013 10:39 PM, Thomas Monjalon wrote:
> > API changes in DPDK 1.3:
> > - queue arrays are already allocated by rte_ethdev
> > - queue could be released for reconfiguration (not supported)
> > - queue struct becomes an opaque pointer
> > - vlan_filte
26/07/2013 11:01, Damien Millescamps :
> On 07/25/2013 10:39 PM, Thomas Monjalon wrote:
> > Print title before running driver initialization.
>
> ack
pushed
--
Thomas
26/07/2013 11:01, Damien Millescamps :
> On 07/25/2013 10:38 PM, Thomas Monjalon wrote:
> > Be more verbose on kernel dependency about version and parameters.
> > And add description of DPDK parameter for VMware.
>
> ack
pushed
--
Thomas
On Thu, Jul 25, 2013 at 10:40:56PM +0200, Thomas Monjalon wrote:
> From: Damien Millescamps
>
> API changes in DPDK 1.3:
> - queue arrays are already allocated by rte_ethdev
> - queue release must be handled by the PMD
> - queue struct becomes an opaque pointer
> - vlan_filter_set can return an e
On 07/25/2013 10:39 PM, Thomas Monjalon wrote:
> API changes in DPDK 1.3:
> - queue arrays are already allocated by rte_ethdev
> - queue could be released for reconfiguration (not supported)
> - queue struct becomes an opaque pointer
> - vlan_filter_set can return an error
> - bit-fields vlan_macip
On 07/25/2013 10:39 PM, Thomas Monjalon wrote:
> Print title before running driver initialization.
>
> Signed-off-by: Thomas Monjalon
ack
On 07/25/2013 10:38 PM, Thomas Monjalon wrote:
> Be more verbose on kernel dependency about version and parameters.
> And add description of DPDK parameter for VMware.
>
> Signed-off-by: Thomas Monjalon
> ---
> README.rst | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-
Hi all,
Any ideas would be helpful, I have an application that uses a rte_ring
for queuing packets to be sent (a single consumer - multiple producer).
The problem I am facing is with rte_eth_tx_burst(), once I dequeue N
packets from tx ring, there is no guaranty that all packets will be
sent,
57 matches
Mail list logo
