Hi John,
2016-07-29 12:59, John McNamara:
> Convert the NIC feature table in the overview doc into a set of ini
> files and add functions into the Sphinx conf.py file to auto-generate
> them back into an RST table.
I have not reviewed the Python code which generate the RST table.
It works so it c
When a rule with depth > 24 is added into an existing
rule with depth <=24, a new tbl8 is allocated, the existing
rule first fulfill whole new tbl8, so the filed vaild of
each entry in this tbl8 is always true and depth of each
entry is always < 24 before adding new rule with depth > 24.
Signed-of
-Original Message-
From: users [mailto:users-boun...@dpdk.org] On Behalf Of Glynn, Michael J
Sent: Thursday, July 28, 2016 5:46 PM
Hi all
As part of our ongoing efforts to improve DPDK, we'd like to hear your feedback!
We have created a number of DPDK-related questions here
https://ww
Hi Sagi,
On Mon, Aug 01, 2016 at 11:44:21AM +0300, Sagi Grimberg wrote:
> The user is allowed to call ->rx_pkt_burst() even without free
> mbufs in the pool. In this scenario we'll fail allocating a rep mbuf
> on the first iteration (where pkt is still NULL). This would cause us
> to deref a NULL
Thank you. Hope to find some time this week to do my part.
Jan
On Mon, 1 Aug 2016 16:15:15 +0530
Shreyansh Jain wrote:
> * Original patch series is from David Marchand [1], [2].
> * Link with patch series [4] from Jan Viktorin for a more complete picture
> of proposed EAL device heirarchy cha
Problem: When adding a slave or starting a bond device, the bond
device configures slave devices via function slave_configure().
However, settings configured in the bond device's rte_eth_conf are
not propagated to the slaves. For example, VLAN and CRC stripping
are not working as expected.
The pro
The following log message may appear after a slave is idle (or nearly
idle) for a few minutes: "PMD: Failed to allocate LACP packet from
pool".
Problem: All mbufs from a slave's private pool (used exclusively for
transmitting LACPDUs) have been allocated and are still sitting in
the device's tx de
Rename macros that calculate a mempool cache flush threshold, and
move them from rte_mempool.c to rte_mempool.h, so that the bonding
driver can accurately calculate its mbuf requirements.
Signed-off-by: Robert Sanford
---
lib/librte_mempool/rte_mempool.c |8 ++--
lib/librte_mempool/rte_m
Problem: When there is little or no TX traffic on an LACP port
(bonding mode 4), we don't call its tx burst function in a timely
manner, and thus we don't transmit LACPDUs when we should.
Solution: Add and maintain an "lacp_master" flag in rte_port struct.
In the main packet forwarding loop, if po
In this patch series, we fix two bonding driver bugs and
enhance testpmd so that bonding mode 4 (LACP) ports remain
operational even when idle.
1. Problem: testpmd does not call bonding mode 4 (LACP) ports' tx
burst function at least every 100 ms, as mandated.
Solution: Enhance testpmd's pac
Hi Jan,
On Saturday 30 July 2016 01:44 PM, Jan Viktorin wrote:
> On Thu, 28 Jul 2016 15:06:10 +0530
> Shreyansh Jain wrote:
>
>> Hi Jan,
>>
>> On Friday 15 July 2016 04:18 PM, Shreyansh jain wrote:
>>> On Thursday 14 July 2016 09:27 PM, Jan Viktorin wrote:
>
> [...]
>
>>> (drv).n
>> Neil
>>
> Sorry for the delayed response, I've been on vacation.
>
>> Your modified copy of make has no bearing on the topic we are taking about
>> customers using dpdk in standard distros right?
>>
> !? I really don't know what you're saying here. My only reason for
> commenting
> on my
Now that hotplug has been moved to eal, there is no reason to keep the device
type in this layer.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
app/test/virtual_pmd.c| 2 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/bonding/rte_eth_bon
Remove bus logic from ethdev hotplug by using eal for this.
Current api is preserved:
- the last port that has been created is tracked to return it to the
application when attaching,
- the internal device name is reused when detaching.
We can not get rid of ethdev hotplug yet since we still nee
Hotplug invocations, which deals with devices, should come from the layer that
already handles them, i.e. EAL.
For both attach and detach operations, 'name' is used to select the bus
that will handle the request.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_eal/bs
No need to scan all devices, we only need to update the device being
attached.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_eal/common/eal_common_pci.c | 11 ---
lib/librte_ether/rte_ethdev.c | 3 ---
2 files changed, 8 insertions(+), 6 deletions(
This helper updates a pci device object with latest information it can
find.
It will be used mainly for hotplug code.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 49 +++
lib/librte_eal/common/eal_private
Eal is a better place than crypto / ethdev to name devices.
Add a helper in eal and make use of it in crypto / ethdev.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_cryptodev/rte_cryptodev.c| 27 ---
lib/librte_eal/common/include/rte_pci.
Now that virtio pci driver is initialized in a constructor, iopl() stuff
happens early enough so that interrupt thread can be created right after
plugin loading.
This way, chelsio driver should be happy again [1].
[1] http://dpdk.org/ml/archives/dev/2015-November/028289.html
Signed-off-by: David
Now that all pdev are pci drivers, we don't need to register ethdev drivers
through a dedicated channel.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_ether/rte_ethdev.c | 22 --
lib/librte_ether/rte_ethdev.h | 12
2 files changed, 3
Now that all pdev are pci drivers, we don't need to register crypto drivers
through a dedicated channel.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_cryptodev/rte_cryptodev.c | 22 ---
lib/librte_cryptodev/rte_cryptodev_pmd.h | 30 -
Simplify crypto and ethdev pci drivers init by using newly introduced
init macros and helpers.
Those drivers then don't need to register as "rte_driver"s anymore.
Exceptions:
- virtio and mlx* use RTE_INIT directly as they have custom initialization
steps.
- VDEV devices are not modified - they
Preparing for getting rid of eth_drv, here are two wrappers that can be
used by pci drivers that assume a 1 to 1 association between pci resource and
upper interface.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_ether/rte_ethdev.c | 14 +++---
lib/
Preparing for getting rid of rte_cryptodev_driver, here are two wrappers
that can be used by pci drivers that assume a 1 to 1 association between
pci resource and upper interface.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_cryptodev/rte_cryptodev.c | 16
Introduce a RTE_INIT macro used to mark an init function as a constructor.
Current eal macros have been converted to use this (no functional impact).
DRIVER_REGISTER_PCI is added as a helper for pci drivers.
Suggested-by: Jan Viktorin
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
introduction.
This function has been exported in ABI, so remove it from eal_private.h
Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and pci
devices")
Signed-off-by: David Marchand
Signed-off-by:
Pure coding style, but it might make it easier later if we want to move
fields in rte_cryptodev_driver and eth_driver structures.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
drivers/net/ena/ena_ethdev.c | 2 +-
drivers
This information is not used and just adds noise.
Signed-off-by: David Marchand
Signed-off-by: Shreyansh Jain
---
lib/librte_cryptodev/rte_cryptodev.c | 8 +++-
lib/librte_cryptodev/rte_cryptodev.h | 2 --
lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +--
3 files changed, 4 insertio
These lists can be initialized once and for all at build time.
With this, those lists are only manipulated in a common place
(and we could even make them private).
A nice side effect is that pci drivers can now register in constructors.
Signed-off-by: David Marchand
Reviewed-by: Jan Viktorin
Si
* Original patch series is from David Marchand [1], [2].
* Link with patch series [4] from Jan Viktorin for a more complete picture
of proposed EAL device heirarchy changes.
* This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is
removed [7].
David created the original patchset b
Apologies for coming a little late to this thread about the proposed new
API for filtering etc.
I've reviewed it based on Solarflare's needs and hardware capabilities,
and think the proposal is likely to be a big improvement on the current
system.
I worry slightly that the goal of having applicat
Hi Raja,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raja Jayapal
> Sent: Monday, August 01, 2016 2:32 AM
> To: dev at dpdk.org
> Cc: Rafat Jahan; Nagaratna Patagar
> Subject: [dpdk-dev] l3fwd LPM memory allocation failed
>
> Hi All,
>
> I have installe
> On Aug 1, 2016, at 5:04 AM, Thomas Monjalon
> wrote:
>
> Hi,
>
> Thanks for explaining your context.
> Your concerns are known under the term "usability enhancements".
> As they require some API changes, we won't make them in the release 16.11.
> But we must work on it now to be able to anno
2016-08-01 15:12, Christian Ehrhardt:
> On Mon, Aug 1, 2016 at 2:50 PM, Thomas Monjalon
> wrote:
> > 2016-08-01 14:28, Christian Ehrhardt:
> > > Due to regular lintian checks in Debian packaging it surfaced that these
> > > two scripts had a space in their #! statement which renders it to be
> > >
Hi Thomas,
I agree on both changes you suggested, but not being the scripts author I
wanted to change as few as possible.
Also thanks for taking it into consideration even if just for lintian :-)
If acceptable to you I'd ask to accept this as-is and consider the patch a
head-up for all script owne
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, August 1, 2016 2:26 PM
> To: Christian Ehrhardt
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples: fix unusual-interpreter
>
> 2016-08-01 15:12, Christian Ehrhardt
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Christian Ehrhardt
> Sent: Monday, August 1, 2016 1:29 PM
> To: christian.ehrhardt at canonical.com; dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] examples: fix unusual-interpreter
>
> Due to regular lintian c
The function __rte_mbuf_raw_alloc was reserved for internal use and
has been deprecated in favor of the public function rte_mbuf_raw_alloc.
It can be safely removed now.
Signed-off-by: Thomas Monjalon
---
lib/librte_mbuf/rte_mbuf.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/lib/li
As a bug-fix for lpm tlb8 recycle is introduced,
add a test case to verify tlb8 group is correctly
freed when it only includes a rule with depth=24.
Signed-off-by: Wei Dai
---
app/test/test_lpm.c | 81 -
1 file changed, 80 insertions(+), 1 dele
When all rules with depth > 24 are deleted in a same tlb8 group
and only leave a rule with depth <= 24 in this group, the tlb8
group should be recycled.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Wei Dai
---
lib/librte_lpm/rte_lpm.c | 4 ++--
1 file changed, 2 insertions(+), 2
Hi All,
I have installed dpdk-2.2.0 on VM and when i try to run l3fwd sample
application, facing the below memory error.
root at
tcs-Standard-PC-i440FX-PIIX-1996:/home/tcs/Downloads/dpdk-2.2.0/examples/l3fwd#
./build/l3fwd -c 0x1 -n 1 -- -p 0x3 --config="(0,0,0),(1,0,0)"
EAL: Detected lcore 0
2016-08-01 14:28, Christian Ehrhardt:
> Due to regular lintian checks in Debian packaging it surfaced that these
> two scripts had a space in their #! statement which renders it to be
> human, but not shell readable.
[...]
> -#! /usr/bin/python2
> +#!/usr/bin/python2
I think we can have a space in
Due to regular lintian checks in Debian packaging it surfaced that these
two scripts had a space in their #! statement which renders it to be
human, but not shell readable.
Fixes: 8673a3e8 ("examples/ip_pipeline: add config diagram generator")
Fixes: fa667b46 ("examples/ip_pipeline: add core mappi
Well, for my purpose I just ended up creating a seperate/smaller pool
earlier during bootup to try to guarantee its from one memseg.
But I am assuming that this KNI restriction is something thats "currently"
not fixed and is "fixable" ? Any ideas on what the summary of the reason
for this restrict
License information is already in LICENSE.GPL.
Remove two extra copies and change referred filename in the files.
Signed-off-by: Christian Ehrhardt
---
lib/librte_eal/linuxapp/kni/ethtool/igb/COPYING| 339 -
.../linuxapp/kni/ethtool/igb/e1000_82575.c | 2 +-
...
On Mon, Aug 01, 2016 at 04:16:12PM +, Wiles, Keith wrote:
>
> >> Neil
> >>
> > Sorry for the delayed response, I've been on vacation.
> >
> >> Your modified copy of make has no bearing on the topic we are taking about
> >> customers using dpdk in standard distros right?
> >>
> > !? I real
Signed-off-by: Aleksey Katargin
---
lib/librte_table/rte_table_version.map | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_table/rte_table_version.map
b/lib/librte_table/rte_table_version.map
index 2138698..459c2da 100644
--- a/lib/librte_table/rte_table_version.map
+++ b/lib/l
Hi,
Thanks for explaining your context.
Your concerns are known under the term "usability enhancements".
As they require some API changes, we won't make them in the release 16.11.
But we must work on it now to be able to announce the API changes for 17.02
before the 16.11 release.
2016-08-01 10:1
The user is allowed to call ->rx_pkt_burst() even without free
mbufs in the pool. In this scenario we'll fail allocating a rep mbuf
on the first iteration (where pkt is still NULL). This would cause us
to deref a NULL pkt (reset refcount and free).
Fix this by checking the pkt before freeing it.
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index bd770cf..f63f2f8 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -664,12 +664,6 @@ eal_check_mem_on_local_socket(void)
"memory on local socket!
>From c3be5420d921325559de9b1079354e1c4314220a Mon Sep 17 00:00:00 2001
From: Steffen Bauch
Date: Mon, 25 Jul 2016 16:13:02 +0200
Subject: [PATCH] allow the call to rte_openlog_stream() before
rte_eal_init()
- only initialize the default_log_stream if it was not initialized
before main initial
This patch fixes a typo in the eth device API doc, device
config. not stored between calls to rte_eth_dev_start/stop()
should be restored before a call to rte_eth_dev_start()
instead of after a call to rte_eth_dev_start().
Signed-off-by: Nikhil Rao
---
lib/librte_ether/rte_ethdev.h | 2 +-
1 fil
Hi,
as a developer of a product that uses DPDK I inherited a custom changeset
towards DPDK 2.0 to allow better integration into our application stack. I
am currently underway of updating the used DPDK release and would like to
get rid of these local changes in the future by influencing the upstrea
2016/7/30 21:30, Wiles, Keith :
>> On Jul 30, 2016, at 1:03 AM, linhaifeng wrote:
>>
>> hi
>>
>> I use 6 ports to send pkts in VM, but can only 4 ports work, how to enable
>> more ports to work?
>>
> In the help screen the command ?ppp [1-6]? is ports per page.
>
>
Thank you very much.
It wor
Hi, Kyle Larose
The core problem is i40e has no statistic of discard bytes, that means even
if when ports are not stopped, the
statistic rx_good_bytes is consist of discard bytes?is that reasonable? In
other words, I can just minus discard bytes
from rx_good_bytes if I can get discard by
Self-Nack this patch because the commit log needs change.
> -Original Message-
> From: Kerlin, MarcinX
> Sent: Friday, July 29, 2016 5:57 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo ;
> thomas.monjalon at 6wind.com; Kerlin, MarcinX
> Subject: [PATCH 0/2] add ensure consistent dev
This patch fixes a typo in a comment in i40e_ethdev.c: use Fortville instead of
IXGBE.
Signed-off-by: Rami Rosen
---
drivers/net/i40e/i40e_ethdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index d0aeb70.
On Sun, Jul 24, 2016 at 06:08:00PM +, Wiles, Keith wrote:
>
>
> Sent from my iPhone
>
> > On Jul 21, 2016, at 1:34 PM, Neil Horman wrote:
> >
> >> On Thu, Jul 21, 2016 at 03:22:45PM +, Wiles, Keith wrote:
> >>
> >>> On Jul 21, 2016, at 10:06 AM, Neil Horman wrote:
> >>>
> >>> On Thu
Please ignore this message. It works. I just made a mistake by myself. Sorry.
At 2016-08-01 06:10:24, "??" wrote:
>Hi,
>
>
>I want to compile and run dpdk example qos_meter. But it shows compile errors.
>
>
>qos_meter/rte_policer.h:34:20: error: #include nested too deeply
>
>qos_meter/r
Hi,
I want to compile and run dpdk example qos_meter. But it shows compile errors.
qos_meter/rte_policer.h:34:20: error: #include nested too deeply
qos_meter/rte_policer.h:35:25: error: #include nested too deeply
qos_meter/rte_policer.h:38:43: error: unknown type name ?uint32_t?
...
I am
Tx offload on tunneling packet now requires applications to correctly
set tunneling type. Without setting it, i40e driver does not parse
tunneling parameters. Besides that, add a check to see if NIC supports
TSO on tunneling packet when executing "csum parse_tunnel on _port"
after "tso set _size _p
To enable Tx side offload on tunneling packet, driver should set
correct tunneling parameters: (1) EIPT, External IP header type;
(2) EIPLEN, External IP; (3) L4TUNT; (4) L4TUNLEN. This parsing
behavior is based on (ol_flag & PKT_TX_TUNNEL_MASK). And when
it's a tunneling packet, MACLEN defines the
To support tunneling packet offload capabilities on Tx side, PMDs
(e.g., i40e) need to know what kind of tunneling type of this packet.
Instead of analyzing the packet itself, we depend on applications to
correctly set the tunneling type. These flags are defined inside
rte_mbuf.ol_flags.
Signed-of
Patch 1: mbuf: add Tx side tunneling type
Patch 2: net/i40e: add TSO support on tunneling packet
Patch 3: app/testpmd: fix Tx offload on tunneling packet
v4:
- According to tunnel type flag to parse tunneling parameters.
- Add new capabilities to indicate support of TSO on tunneling packets.
Garik
Currently the permanent mac address of VF should be configured from host side.
If you are using Linux kernel driver as the host driver. 'ip link set' is the
right way to do that.
Regards,
Helin
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Garik E
Hi Garik,
From: Garik E [mailto:kira...@gmail.com]
Sent: Monday, August 1, 2016 12:40 AM
To: dev at dpdk.org
Cc: Lu, Wenzhuo
Subject: VF default MAC change
Hello,
I'm looking for API to update default VF MAC address during DPDK port
initialization.
The API should replace shell command `ip link
66 matches
Mail list logo
