I was able to build it without any issues earlier yesterday but all of a
sudden, it started to give me this error. All I did was add the boot options
in grub.con : default_hugepagesz=1G hugepagesz=1G hugepages=4 hpet_mmap
Even after removing them, this problem still persists.
[root at localhos
From: Stephen Hemminger
The ixgbe driver was including CRC in the transmit packet byte
count, but not for packets received. This was notice when forwarding and
the number of bytes received was greater than the number of bytes transmitted
for the same number of packets. Make the driver behave like
From: Stephen Hemminger
In some cases application may want to have additional rules
for clean. This can be handled by allowing the double colon
form of rule.
https://www.gnu.org/software/make/manual/html_node/Double_002dColon.html
Single colon and double colon rules for same target causes
an e
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Thursday, January 22, 2015 6:55 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 00/18] ACL: New AVX2 classify method and
> several other enhancements.
>
> On Tue, Ja
On Wed, Jan 21, 2015 at 8:02 PM, Andrey Korolyov wrote:
> Hello,
>
> I observed that the latest OVS with dpdk-1.8.0 and igb_uio starts to
> drop packets earlier than a regular Linux ixgbe 10G interface, setup
> follows:
>
> receiver/forwarder:
> - 8 core/2 head system with E5-2603v2, cores 1-3 are
On 2015/1/22 19:34, Bruce Richardson wrote:
> On Thu, Jan 22, 2015 at 07:23:49PM +0900, Tetsuya Mukawa wrote:
>> On 2015/01/22 16:35, Matthew Hall wrote:
>>> On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
Do you mean if call rte_memcpy before rte_eal_init() would crash?why?
>>>
On Wed, Jan 21, 2015 at 7:19 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote:
> > Hi again,
> >
> > I did some further testing and it seems like this issue is linked to
> > jumbo frames. I think a similar issue has alread
On 22 January 2015 at 14:29, Jay Rolette wrote:
> Microseconds matter. Scaling up to 100GbE, nanoseconds matter.
>
True. Is there a cut-off point though? Does one nanosecond matter?
AVX512 will fit a 64-byte packet in one register and move that to or from
memory with one instruction. L1/L2 cach
On 2015/01/22 16:35, Matthew Hall wrote:
> On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
>> Do you mean if call rte_memcpy before rte_eal_init() would crash?why?
> No guarantee. But a theory. It might use some things from the EAL init to
> figure out which version of the accelerated
Hi Michael,
On 2015/01/22 17:12, Qiu, Michael wrote:
> On 1/21/2015 6:01 PM, Tetsuya Mukawa wrote:
>> Hi Michael,
>>
>> On 2015/01/20 18:23, Qiu, Michael wrote:
>>> On 1/19/2015 6:42 PM, Tetsuya Mukawa wrote:
The patch adds functions for unmapping igb_uio resources. The patch is only
for
On 2015-01-21, 3:54 PM, "Neil Horman" wrote:
>On Wed, Jan 21, 2015 at 11:49:47AM -0800, Stephen Hemminger wrote:
>> On Wed, 21 Jan 2015 13:26:20 +
>> Bruce Richardson wrote:
>>
>> > On Wed, Jan 21, 2015 at 02:21:25PM +0100, Marc Sune wrote:
>> > >
>> > > On 21/01/15 14:02, Bruce Richards
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, January 22, 2015 3:49 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v8 4/4] docs: Add ABI documentation
>
> Adding a document describing rudimentary ABI policy and adding n
Hello,
Is there some way to purge all keys in an rte_hash while maintaining read
concurrency?
I am assuming that I can?t do a free/create step while other threads may still
be doing lookups on it.
What I can do is store the key as part of the value in the array of user data,
iterate this arra
Allow to setup timers only for EAL (lcore) threads (__lcore_id < MAX_LCORE_ID).
E.g. ? dynamically created thread will be able to reset/stop timer for lcore
thread,
but it will be not allowed to setup timer for itself or another non-lcore
thread.
rte_timer_manage() for non-lcore thread would simp
ring debug stat won't take care non-EAL thread.
Signed-off-by: Cunming Liang
---
lib/librte_ring/rte_ring.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 7cd5f2d..39bacdd 100644
--- a/lib/librte_ring/r
For non-EAL thread, bypass per lcore cache, directly use ring pool.
It allows using rte_mempool in either EAL thread or any user pthread.
As in non-EAL thread, it directly rely on rte_ring and it's none preemptive.
It doesn't suggest to run multi-pthread/cpu which compete the rte_mempool.
It will g
In non-EAL thread, lcore_id alrways be LCORE_ID_ANY.
It cann't be used as unique id for recursive spinlock.
Then use rte_gettid() to replace it.
Signed-off-by: Cunming Liang
---
lib/librte_eal/common/include/generic/rte_spinlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
For those none EAL thread, *_lcore_id* shall always be LCORE_ID_ANY.
The libraries using *_lcore_id* as index need to take care.
*_socket_id* always be SOCKET_ID_ANY unitl the thread changes the affinity
by rte_thread_set_affinity()
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/eal_
For those non-EAL thread, *_lcore_id* is invalid and probably larger than
RTE_MAX_LCORE.
The patch adds the check and allows only EAL thread using EAL per thread log
level and log type.
Others shares the global log level.
Signed-off-by: Cunming Liang
---
lib/librte_eal/common/eal_common_log.c
Add check for rte_socket_id(), avoid get unexpected return like (-1).
Signed-off-by: Cunming Liang
---
lib/librte_malloc/malloc_heap.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/librte_malloc/malloc_heap.h b/lib/librte_malloc/malloc_heap.h
index b4aec45..a47136
Some macro already been defined by freebsd 'sys/param.h'.
Signed-off-by: Cunming Liang
---
lib/librte_pmd_enic/enic.h| 1 +
lib/librte_pmd_enic/enic_compat.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
index c43417c..189c3
EAL threads use assigned cpuset to set core affinity during startup.
It keeps 1:1 mapping, if no '--lcores' option is used.
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/eal.c | 13 ---
lib/librte_eal/bsdapp/eal/eal_thread.c | 63 +-
lib/li
The rte_gettid() wraps the linux and freebsd syscall gettid().
It provides a persistent unique thread id for the calling thread.
It will save the unique id in TLS on the first time.
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/eal_thread.c | 9 +
lib/librte_eal/common/in
The API works for both EAL thread and none EAL thread.
When calling rte_thread_set_affinity, the *_socket_id* and
*_cpuset* of calling thread will be updated if the thread
successful set the cpu affinity.
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/Makefile| 1 +
lib/lib
1. add two TLS *_socket_id* and *_cpuset*
2. add two external API rte_thread_set/get_affinity
3. add one internal API eal_thread_dump_affinity
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/eal_thread.c| 2 ++
lib/librte_eal/common/eal_thread.h| 14 ++
lib/li
It returns the socket_id if all cpus in the cpuset belongs
to the same NUMA node, otherwise it will return SOCKET_ID_ANY.
Signed-off-by: Cunming Liang
---
lib/librte_eal/bsdapp/eal/eal_lcore.c | 7 +
lib/librte_eal/common/eal_thread.h | 52 +
lib/librt
It supports one new eal long option '--lcores' for EAL thread cpuset assignment.
The format pattern:
--lcores='lcores[@cpus]<,lcores[@cpus]>'
lcores, cpus could be a single digit or a group.
'(' and ')' are necessary if it's a group.
If not supply '@cpus', the value of cpus uses the same a
The patch adds 'cpuset' into per-lcore configure 'lcore_config[]',
as the lcore no longer always 1:1 pinning with physical cpu.
The lcore now stands for a EAL thread rather than a logical cpu.
It doesn't change the default behavior of 1:1 mapping, but allows to
affinity the EAL thread to multiple
The patch series contain the enhancements of EAL and fixes for libraries
to run multi-pthreads(either EAL or non-EAL thread) per physical core.
Two major changes list as below:
- Extend the core affinity of each EAL thread to 1:n.
Each lcore stands for a EAL thread rather than a logical core.
document of new commands:
- 2tuple_filter (port_id) (add|del)
dst_port (dst_port_value) protocol (protocol_value)
mask (mask_value) tcp_flags (tcp_flags_value)
priority (prio_value) queue (queue_id)
- 5tuple_filter (port_id) (add|del)
dst_ip (dst_address) src_ip (src_address)
dst_p
Following structures are removed:
- rte_2tuple_filter
- rte_5tuple_filter
Following APIs are removed:
- rte_eth_dev_add_2tuple_filter
- rte_eth_dev_remove_2tuple_filter
- rte_eth_dev_get_2tuple_filter
- rte_eth_dev_add_5tuple_filter
- rte_eth_dev_remove_5tuple_filter
- rte_eth_dev_get_5tupl
Following commands of 5tuple and 2tuple filter are removed:
- add_2tuple_filter (port_id) protocol (pro_value) (pro_mask)
dst_port (port_value) (port_mask) flags (flg_value) priority (prio
queue (queue_id) index (idx)
- remove_2tuple_filter (port_id) index (idx)
- get_2tuple_filter (port_i
This patch defines new functions dealing with ntuple filters which is
corresponding to 2tuple filter for 82580 and i350 in HW, and to 5tuple
filter for 82576 in HW.
It removes old functions which deal with 2tuple and 5tuple filters in igb
driver.
Ntuple filter is dealt with through entrance eth_ig
This patch defines new functions dealing with ntuple filters which is
corresponding to 5tuple in HW.
It removes old functions which deal with 5tuple filters.
Ntuple filter ie dealt with through entrance ixgbe_dev_filter_ctrl.
Signed-off-by: Jingjing Wu
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 4
This patch defines ntuple filter type RTE_ETH_FILTER_NTUPLE and its structure
rte_eth_ntuple_filter.
It also corrects the typo TCP_UGR_FLAG to TCP_URG_FLAG
Signed-off-by: Jingjing Wu
---
lib/librte_ether/rte_eth_ctrl.h | 50 +
lib/librte_ether/rte_ethdev.
v2 changes:
- remove the code which is already applied in patch "Integrate ethertype
filter in igb/ixgbe driver to new API".
- modify commands' description in doc testpmd_funcs.rst.
The patch set uses filter_ctrl API to replace old 2tuple and 5tuple filter APIs.
It defines ntuple filter to
To demonstrate the hash filter control, commands are added.
They are,
- get_sym_hash_ena_per_port
- set_sym_hash_ena_per_port
- get_hash_global_config
- set_hash_global_config
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 333 +
1 file ch
Hash filter control has been implemented for i40e. It includes
getting/setting,
- global hash configurations (hash function type, and symmetric
hash enable per flow type)
- symmetric hash enable per port
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 294 +++
In order to support hash filter configuration, filter type of hash
is added, also the corresponding structures, macros and definitions
are added.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_eth_ctrl.h | 63 +
1 file changed, 63 insertions(+)
v9 ch
Added code style fixes.
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_eth_ctrl.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 5d9c387..4b3c5fc 100644
--- a/lib/librte_ether/rte_eth_ctrl.
Calculating the default RSS hash keys at run time is not needed
at all, and may have race conditions. The alternative is to use
array of random values which were generated manually as the
default hash keys.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 14 +++---
1 f
These patches mainly support configuring hash functions. In detail,
- It can get/set global hash configurations.
* Get/set symmetric hash enable per flow type.
* Get/set hash function type.
- It can get/set symmetric hash enable per port.
- Four commands have been implemented in testpmd to s
On Thu, Jan 22, 2015 at 02:34:07PM +, Ananyev, Konstantin wrote:
> Hi Bruce,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Thursday, January 22, 2015 12:19 PM
> > To: Liang, Cunming
> > Cc: dev at dpdk.org
> > Subject: R
On Thu, Jan 22, 2015 at 08:53:13PM +0800, Linhaifeng wrote:
>
>
> On 2015/1/22 19:34, Bruce Richardson wrote:
> > On Thu, Jan 22, 2015 at 07:23:49PM +0900, Tetsuya Mukawa wrote:
> >> On 2015/01/22 16:35, Matthew Hall wrote:
> >>> On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
>
On Thu, Jan 22, 2015 at 07:35:45PM +0530, Prashant Upadhyaya wrote:
> On Wed, Jan 21, 2015 at 7:19 PM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
>
> > On Tue, Jan 20, 2015 at 11:39:03AM +0100, Martin Weiser wrote:
> > > Hi again,
> > >
> > > I did some further testing and it seems
Hi,
I want to mention that similar but for me much more readable syntax have
Pktgen-DPDK for defining core - port mapping. Maybe we can adopt this syntax
for new '--lcores' parameter.
See '-m' parameter syntax on Pktgen readme.
https://github.com/pktgen/Pktgen-DPDK/blob/master/dpdk/examples/pktge
Removes the dependency that this memzone reserve has on the
socket currently running on. Following the socket of the master
core will yield more predictable results when calling this
function after initialisation.
Signed-off-by: Cian Ferriter
Reviewed-by: Maryam Tahhan
Reviewed-by: Bruce Richard
On 01/21/15 10:44, Wodkowski, PawelX wrote:
>
>> -Original Message-
>> From: Ouyang, Changchun
>> Sent: Wednesday, January 21, 2015 3:44 AM
>> To: Wodkowski, PawelX; dev at dpdk.org
>> Cc: Ouyang, Changchun
>> Subject: RE: [dpdk-dev] [PATCH v6 5/6] ixgbe: Config VF RSS
>>
>>
>>
>>> -Or
Hi Bruce,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, January 22, 2015 12:19 PM
> To: Liang, Cunming
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 02/15] eal: new eal option '--lcores' for
> cpu assignment
>
On Wed, Jan 21, 2015 at 11:24:12PM +0100, Thomas Monjalon wrote:
> 2015-01-21 14:43, Neil Horman:
> > On Wed, Jan 21, 2015 at 05:05:51PM +0100, Thomas Monjalon wrote:
> > > 2015-01-21 09:59, Neil Horman:
> > > > Considered and answered already. I'm in favor of listing macros and
> > > > structure
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> Sent: Thursday, January 22, 2015 8:16 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 00/15] support multi-pthread per core
>
> The patch series contain the enhancements of EAL and fix
Hi Miroslaw,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Walukiewicz, Miroslaw
> Sent: Thursday, January 22, 2015 12:45 PM
> To: Liang, Cunming; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 13/15] mempool: add support to non-EAL
> thread
>
>
>
On Tue, Jan 20, 2015 at 06:40:49PM +, Konstantin Ananyev wrote:
> v3 changes:
> Applied review comments from Thomas:
> - fix spelling errors reported by codespell.
> - split last patch into two:
> first to remove unused macros,
> second to add some comments about ACL internal layout.
>
On Thu, Jan 22, 2015 at 12:27 PM, Luke Gorrie wrote:
> On 22 January 2015 at 14:29, Jay Rolette wrote:
>
>> Microseconds matter. Scaling up to 100GbE, nanoseconds matter.
>>
>
> True. Is there a cut-off point though?
>
There are always engineering trade-offs that have to be made. If I'm
optimiz
On 2015/1/22 12:45, Matthew Hall wrote:
> One theory. Many DPDK functions crash if they are called before
> rte_eal_init()
> is called. So perhaps this could be a cause, since that won't have been
> called
> when working on a constant
Hi, Matthew
Thank you for your response.
Do you mean if
>
> I'm new on the list and my experience with DPDK is about two months so,
> pls., don't judge me too harsh... ;)
> I tried to cover the obvious things and actually learned the code while
> reviewing. The things u say, Pavel(X?) make sense and I obviously missed
I am really puzzled about mail cl
> -Original Message-
> From: Liang, Cunming
> Sent: Thursday, January 22, 2015 1:20 PM
> To: Walukiewicz, Miroslaw; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 13/15] mempool: add support to non-EAL
> thread
>
>
>
> > -Original Message-
> > From: Walukiewicz, Miroslaw
>
> -Original Message-
> From: Walukiewicz, Miroslaw
> Sent: Thursday, January 22, 2015 5:58 PM
> To: Liang, Cunming; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 15/15] timer: add support to non-EAL thread
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at
> -Original Message-
> From: Walukiewicz, Miroslaw
> Sent: Thursday, January 22, 2015 5:53 PM
> To: Liang, Cunming; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v1 13/15] mempool: add support to non-EAL
> thread
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces
On Thu, Jan 22, 2015 at 04:16:25PM +0800, Cunming Liang wrote:
> It supports one new eal long option '--lcores' for EAL thread cpuset
> assignment.
>
> The format pattern:
> --lcores='lcores[@cpus]<,lcores[@cpus]>'
> lcores, cpus could be a single digit or a group.
> '(' and ')' are necessa
Hi Jingjing,
Few comments about how to send a v2 patch (as described in
http://dpdk.org/dev#send):
--subject-prefix 'PATCH v2' to make it clear that it supersedes a previous
version
--annotate to add a changelog below the three dashes
--in-reply-to to have the versions threaded together
http://
#define rte_memcpy(dst, src, n) \
((__builtin_constant_p(n)) ? \
memcpy((dst), (src), (n)) : \
rte_memcpy_func((dst), (src), (n)))
Why call memcpy when n is constant variable?
Can i change them to the follow codes?
#define rte_memcpy(dst, sr
2015-01-22 10:03, Gonzalez Monroy, Sergio:
> > From: Gonzalez Monroy, Sergio
> > Sent: Monday, January 12, 2015 5:22 PM
> > To: Thomas Monjalon
> > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
> >
> > Hi Thomas,
> >
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com
On Thu, Jan 22, 2015 at 07:23:49PM +0900, Tetsuya Mukawa wrote:
> On 2015/01/22 16:35, Matthew Hall wrote:
> > On Thu, Jan 22, 2015 at 01:32:04PM +0800, Linhaifeng wrote:
> >> Do you mean if call rte_memcpy before rte_eal_init() would crash?why?
> > No guarantee. But a theory. It might use some thi
On Thu, Jan 22, 2015 at 09:56:48AM +, Ferriter, Cian wrote:
> Hey guys,
>
> I just wanted to ask is there anything more that can be done with this patch
> or is it in an acceptable state for pushing?
>
> Cian
At this stage I think I'm ok with the patch contents, unless anyone else
objects.
On Thu, Jan 22, 2015 at 09:05:34AM +, Chi, Xiaobo (NSN - CN/Hangzhou) wrote:
> Hi, Bruce,
> Since the DPDK2.0 merge window is opened now, so is it possible for this
> patch to be one candidate for v2.0?
> I searched in the DPDK
> patchwork(http://www.dpdk.org/dev/patchwork/project/dpdk/list/?
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu
> Sent: Thursday, January 22, 2015 1:09 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: commands changed in testpmd_funcs for
> ethertype filter
>
> new commands for ethertype filter
>
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, January 22, 2015 10:39 AM
> To: Gonzalez Monroy, Sergio
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
>
> 2015-01-22 10:03, Gonzalez Monroy, Sergio:
> > > From: Gonzalez Monroy,
esc: not available
URL:
<http://dpdk.org/ml/archives/dev/attachments/20150122/0115fb4b/attachment-0001.py>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Wednesday, January 21, 2015 9:00 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v7 4/4] docs: Add ABI documentation
>
> Adding a document describing rudimentary ABI policy and adding
This patch add Support for ICC 15.
ICC 15 changed inline-max-size and inline-max-total-size default values,
so for ICC 15 flags -no-inline-max-size -no-inline-max-total-size must be added.
additionally disable compile error for:
13368 - loop was not vectorized with "vector always assert"
15527 -
Adding a document describing rudimentary ABI policy and adding notice space for
any deprecation announcements
Signed-off-by: Neil Horman
CC: Thomas Monjalon
CC: "Richardson, Bruce"
---
Change notes:
v5) Updated documentation to add notes from Thomas M.
v6) Moved abi.txt to guides/rel_notes/a
To differentiate libraries that break ABI, we add a library version number
suffix to the library, which must be incremented when a given libraries ABI is
broken. This patch enforces that addition, sets the initial abi soname
extension to 1 for each library and creates a symlink to the base SONAME
Add linker version script files to each DPDK library to put a stake in the
ground from which we can start cleaning up API's
Signed-off-by: Neil Horman
CC: Thomas Monjalon
CC: "Richardson, Bruce"
---
Change Notes:
v2)
* Updated export map to not require full path
---
lib/librte_acl/Ma
Add initial pass header files to support symbol versioning.
Signed-off-by: Neil Horman
CC: Thomas Monjalon
CC: "Richardson, Bruce"
CC: "Gonzalez Monroy, Sergio"
---
Change Notes:
V2)
Moved ifeq to _INSTALL target
V3)
Undo V2 changes and make librte_compat use the rte.install.
2015-01-21 16:49, Stephen Hemminger:
> On Thu, 15 Jan 2015 12:02:11 +0100
> Thomas Monjalon wrote:
>
> > Someone to review these patches?
>
> Any comments from
> Bruce Richardson
Sorry, what do you mean?
Is there some comments I missed?
--
Thomas
On Thu, Jan 22, 2015 at 10:56:08AM +, Iremonger, Bernard wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Wednesday, January 21, 2015 9:00 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH v7 4/4] docs: Add ABI
While VFIO doesn't allow us to map complete BARs with MSI-X tables,
it does allow us to map around them in PAGE_SIZE granularity. There
might be adapters that provide their registers in the same BAR
but on a different page. For example, Intel's NVME adapter, though
not a network adapter, provides o
Howdy!
This memcpy discussion is absolutely fascinating. Glad to be a fly on the
wall!
On 21 January 2015 at 22:25, Jim Thompson wrote:
>
> The differences with DPDK are that a) entire cores (including the AVX/SSE
> units and even AES-NI (FPU) are dedicated to DPDK, and b) DPDK is a library,
>
> From: Gonzalez Monroy, Sergio
> Sent: Monday, January 12, 2015 5:22 PM
> To: Thomas Monjalon
> Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
>
> Hi Thomas,
>
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Monday, January 12, 2015 4:52 PM
> >
> > Hi Ser
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> Sent: Thursday, January 22, 2015 9:17 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 15/15] timer: add support to non-EAL thread
>
> Allow to setup timers only for EAL (lcore) threads
Hey guys,
I just wanted to ask is there anything more that can be done with this patch or
is it in an acceptable state for pushing?
Cian
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferriter, Cian
Sent: Monday, January 19, 2015 6:39 PM
To: Richardson, Bruce
Cc
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming Liang
> Sent: Thursday, January 22, 2015 9:17 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 13/15] mempool: add support to non-EAL
> thread
>
> For non-EAL thread, bypass per lcore cache, di
new commands for ethertype filter
- ethertype_filter (port_id) (add|del) (mac_addr|mac_ignr)
(mac_address) ethertype (ether_type) (drop|fwd) queue (queue_id)
Signed-off-by: Jingjing Wu
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 51 +++--
1 file changed, 12 in
Hi, Bruce,
Since the DPDK2.0 merge window is opened now, so is it possible for this patch
to be one candidate for v2.0?
I searched in the DPDK
patchwork(http://www.dpdk.org/dev/patchwork/project/dpdk/list/?state=*&q=memory-only&archive=both
), but can not find this V2 patch. Can you please help
Thanks, I had validated the 'rx_drop_en' setting. It's worked.
Regards,/Liang--From:Bruce
Richardson Time:2015 Jan 19 (Mon) 18:58To:??
Cc:dev Subject:Re: [dpdk-dev] Should
the other queues at same port work when one queue is full ?
On 1/21/2015 6:01 PM, Tetsuya Mukawa wrote:
> Hi Michael,
>
> On 2015/01/20 18:23, Qiu, Michael wrote:
>> On 1/19/2015 6:42 PM, Tetsuya Mukawa wrote:
>>> The patch adds functions for unmapping igb_uio resources. The patch is only
>>> for Linux and igb_uio environment. VFIO and BSD are not supported
> -Original Message-
> From: Zhang, Helin
> Sent: Monday, January 19, 2015 2:56 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Cao, Waterman; Zhang, Helin
> Subject: [PATCH 0/7] unification of flow types and RSS offload types
>
> It unifies the flow types and RSS offload types for all PMDs
Hi Thomas
I have sent out v9 of this patch set, with adopting your comments. Thank you
very much!
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, January 20, 2015 3:54 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev
On Thu, Jan 22, 2015 at 3:06 AM, Luke Gorrie wrote:
Here is another thought: when is it time to start thinking of packet copy
> as a cheap unit-time operation?
>
Pretty much never short of changes to memory architecture, IMO. Frankly,
there are never enough cycles for deep packet inspection appl
2015-01-22 11:17, Bruce Richardson:
> On Thu, Jan 22, 2015 at 09:05:34AM +, Chi, Xiaobo (NSN - CN/Hangzhou)
> wrote:
> > Hi, Bruce,
> > Since the DPDK2.0 merge window is opened now, so is it possible for this
> > patch to be one candidate for v2.0?
> > I searched in the DPDK
> > patchwork(ht
Hi,
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Thursday, January 22, 2015 3:45 AM
> To: Liu, Jijiang
> Cc: Olivier MATZ; Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and
> csum f
-- next part --
A non-text attachment was scrubbed...
Name: i40e_case1.cap
Type: application/vnd.tcpdump.pcap
Size: 60080 bytes
Desc: not available
URL:
<http://dpdk.org/ml/archives/dev/attachments/20150122/5639b261/attachment-0010.cap>
-- next part ---
Add support for IP over IP tunnels.
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/csumonly.c | 40 ++--
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 930420
Add support for Ethernet over GRE and IP over GRE tunnels.
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 6 ++--
app/test-pmd/csumonly.c | 87 +
2 files changed, 84 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/a
Move code parsing vxlan into a function. It will ease the support
of GRE tunnels and IPIP tunnels in next commits.
Signed-off-by: Olivier Matz
---
app/test-pmd/csumonly.c | 68 +++--
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/app/t
To simplify the API of parse_* functions, store all the offload
information for the current packet in a structure.
No functional change.
Signed-off-by: Olivier Matz
---
app/test-pmd/csumonly.c | 222 +---
1 file changed, 115 insertions(+), 107 deletio
These functions may be used to parse encapsulated layers
when we will support IP over GRE tunnels.
No functional change.
Signed-off-by: Olivier Matz
---
app/test-pmd/csumonly.c | 51 +
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git
The tx_checksum command concerns outer IP checksum, not VxLAN checksum.
Actually there is no checkum in VxLAN header, there is one checksum in
outer IP header, and one checksum in outer UDP header. This option only
controls the outer IP checksum.
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdl
Add a new command related to csum forward engine:
csum parse-tunnel (on|off) (port_id)
If enabled, the tunnel packets received by the csum forward engine are
parsed and seen as "outer-headers/inner-headers/data".
If disabled, the parsing of the csum forward engine stops at the first
l4 layer.
1 - 100 of 111 matches
Mail list logo
