On 2014/12/9 14:33, Tetsuya Mukawa wrote:
> The patch fixes rte_eal_devargs_add() not to register same device twice.
>
> Signed-off-by: Tetsuya Mukawa
> ---
> lib/librte_eal/common/eal_common_devargs.c | 35
> ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/lib
On Mon, Dec 08, 2014 at 04:59:37PM +0800, Zhigang Lu wrote:
> Tile processor doesn't have CPU flag hardware registers, so this patch
> turns off cpu flag checks for tile.
>
> Signed-off-by: Zhigang Lu
> Signed-off-by: Cyril Chemparathy
> ---
> app/test/test_cpuflags.c | 2 +-
> 1 file changed,
On Tue, Dec 09, 2014 at 09:53:18AM +0100, Olivier MATZ wrote:
> Hi Neil,
>
> On 12/08/2014 04:04 PM, Neil Horman wrote:
> >On Fri, Nov 07, 2014 at 09:28:09AM -0800, Jia Yu wrote:
> >>Include rte_memory.h for lib files that use __rte_cache_aligned
> >>attribute.
> >>
> >>Signed-off-by: Jia Yu
> >>
On Mon, Dec 08, 2014 at 07:02:38PM +, Karmarkar Suyash wrote:
> Hello,
>
> In DPDK when we use mmap why are we passing the MAP_FIXED flag when Linux man
> page itself says that the option is discouraged? Any specific reason for
> passing the MAP_FIXED flag?
>
Because theres nothing wrong wi
I don't know if other reviewers ask you to split so many patches. But I
would like merge some of them, because some are doing same affairs(just
using different args), others should be add/remove affairs. Those could
be merge to one patch, although it is much more easier for review.
Actually, it is
On 2014/12/9 14:33, Tetsuya Mukawa wrote:
> The patch adds rte_eal_dev_init_one() and rte_eal_dev_close_one().
> These are used for attaching and detaching virtual devices.
>
> Signed-off-by: Tetsuya Mukawa
> ---
> lib/librte_eal/common/eal_common_dev.c | 66
> +
On 2014/12/9 22:19, Ouyang, Changchun wrote:
> Hi Bruce,
>
>> -Original Message-
>> From: Richardson, Bruce
>> Sent: Tuesday, December 9, 2014 5:47 PM
>> To: Ouyang, Changchun
>> Cc: Thomas Monjalon; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH 00/17] Single virtio implementation
>
On Tue, Dec 09, 2014 at 10:26:34AM -0500, Neil Horman wrote:
> On Mon, Dec 08, 2014 at 07:02:38PM +, Karmarkar Suyash wrote:
> > Hello,
> >
> > In DPDK when we use mmap why are we passing the MAP_FIXED flag when Linux
> > man page itself says that the option is discouraged? Any specific reaso
Hey Folks,
Our DPDK application deals with very large in memory data structures, and
can potentially use tens or even hundreds of gigabytes of hugepage memory.
During the course of development, we've noticed that as the number of huge
pages increases, the memory initialization time during EAL init
The read/seek/close stub functions are unnecessary on the
log stream. Per glibc fopencookie man page:
cookie_read_function_t *read
If *read is a null pointer, then reads from the custom stream
always return end of file.
cookie_seek_function_t *seek
Add missing setup for X540 MAC type when setting up VF.
Additional check exists in Linux driver but not in DPDK.
Signed-off-yb: Bill Hong
Signed-off-by: Stephen Hemminger
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 2014-12-08 09:26:18.150170081 -0800
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 2014-12
Add new statistic to keep track of drops due to RED.
Signed-off-by: Stephen Hemminger
--- a/lib/librte_sched/rte_sched.c 2014-12-08 09:28:37.810590895 -0800
+++ b/lib/librte_sched/rte_sched.c 2014-12-08 09:28:37.810590895 -0800
@@ -1028,7 +1028,9 @@ rte_sched_port_update_subport_stats(
We want to be able to build with RTE_SCHED_RED enabled but
allow disabling RED on a per-queue basis at runtime. This is
handled by allowing RED min/max to be zero to indicate that
RED is not being used.
Signed-off-by: Stephen Hemminger
--- a/lib/librte_sched/rte_sched.c 2014-12-08 09:28:20.
Make rte_sched statistics API work like the ethernet statistics API.
Don't auto-clear statistics when read.
Signed-off-by: Stephen Hemminger
--- a/lib/librte_sched/rte_sched.c 2014-12-08 09:29:49.014821607 -0800
+++ b/lib/librte_sched/rte_sched.c 2014-12-08 09:35:45.568568267 -0800
@@
syslog does not like tabs in log messages; tab gets translated to #011
Signed-off-by: Stephen Hemminger
--- a/lib/librte_sched/rte_sched.c 2014-12-08 09:37:08.741006405 -0800
+++ b/lib/librte_sched/rte_sched.c 2014-12-08 09:37:56.641264631 -0800
@@ -495,10 +495,10 @@ rte_sched_port_lo
Hi
> Hey Folks,
>
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage
> memory.
> During the course of development, we've noticed that as the number of
> huge pages increases, the memory initialization ti
Hi,
This patch resolves a compilation issue that arises when DPDK1.8-rc3
is linked with OVS on Fedora 20, kernel v3.16.4-200.
Specifically, the name of rte_eth_fdir_flow's
rte_eth_ipv6_flow attribute, 'ip6_flow', clashes with a macro defined
in /usr/include/netinet/ip6.h, such that when DPDK is l
The name of the rte_eth_fdir_flow's rte_eth_ipv6_flow attribute,
'ip6_flow', clashes with a macro defined in
/usr/include/netinet/ip6.h, such that when DPDK is linked with an
application that uses the afforementioned header, the macro is
expanded within the DPDK struct, causing a compilation error.
I had replied to this message, but my reply never got to the list.
Let's try again.
I wonder if this might be papering over a bug in the host cpufreq
driver. If the guest is not doing much and leaving a lot of idle CPU
time, the host should scale down the frequency of that CPU. In the case
of pi
From: Miroslaw Walukiewicz
The patch fixes a minor issue with setting up of TSO feature for
ixgbe NICs.
The values for l4_len and tso_segsz was chagned first by txoffload mask
and next set up in the NIC descriptor.
Signed-off-by: Mirek Walukiewicz
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c |4
On Tue, Dec 09, 2014 at 04:04:11PM +, Bruce Richardson wrote:
> On Tue, Dec 09, 2014 at 10:26:34AM -0500, Neil Horman wrote:
> > On Mon, Dec 08, 2014 at 07:02:38PM +, Karmarkar Suyash wrote:
> > > Hello,
> > >
> > > In DPDK when we use mmap why are we passing the MAP_FIXED flag when Linux
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, December 09, 2014 2:55 AM
> To: Karmarkar Suyash
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] DDPK use of MAP_FIXED in mmap
>
> On Mon, Dec 08, 2014 at 07:02:38PM +, Ka
You are completely right. I did not catch the mask. I will remove the patch.
Mirek
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, December 9, 2014 7:41 PM
> To: Walukiewicz, Miroslaw; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] ixgbe: fix a problem with NIC TSO of
On Tue, Dec 09, 2014 at 05:32:08PM +, Mark Kavanagh wrote:
> The name of the rte_eth_fdir_flow's rte_eth_ipv6_flow attribute,
> 'ip6_flow', clashes with a macro defined in
> /usr/include/netinet/ip6.h, such that when DPDK is linked with an
> application that uses the afforementioned header, the
On Tue, Dec 09, 2014 at 10:33:59AM -0600, Matt Laswell wrote:
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage memory.
What you're doing is an unusual use case and this is open source code where
nobody
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of miroslaw.walukiewicz
> at intel.com
> Sent: Tuesday, December 09, 2014 5:15 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ixgbe: fix a problem with NIC TSO offload
>
> From: Miroslaw Walukiewicz
>
> The patch fixes a minor issue
> Hey Folks,
>
> Our DPDK application deals with very large in memory data structures, and
> can potentially use tens or even hundreds of gigabytes of hugepage memory.
> During the course of development, we've noticed that as the number of huge
> pages increases, the memory initialization time duri
Subject: [PATCH] Small fixes in rte_common.h
Fix a bug in power_of_2 since zero is not.
Avoid branching in RTE_MIN and RTE_MAX macros.
Ravi Kerur (1):
Fix power_of_2 macro.
Avoid branching when calculating RTE_MIN and RTE_MAX.
lib/librte_eal/common/include/rte_common.h | 6 +++---
lib/librt
Subject: [PATCH] Fix power_of_2 macro. Avoid branching when
calculating RTE_MIN and RTE_MAX.
---
lib/librte_eal/common/include/rte_common.h | 6 +++---
lib/librte_pmd_e1000/igb_pf.c | 4 ++--
lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
3 files changed, 7 insertions(+), 7 del
Hey Everybody,
Thanks for the feedback. Yeah, we're pretty sure that the amount of memory
we work with is atypical, and we're hitting something that isn't an issue
for most DPDK users.
To clarify, yes, we're using 1GB hugepages, and we set them up via
hugepagesz and hugepages= in our kernel's gr
On Tue, 9 Dec 2014 11:45:07 -0800
&rew wrote:
> > Hey Folks,
> >
> > Our DPDK application deals with very large in memory data structures, and
> > can potentially use tens or even hundreds of gigabytes of hugepage memory.
> > During the course of development, we've noticed that as the number of h
101 - 131 of 131 matches
Mail list logo
