A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v16.11-rc2
The release 16.11 is going to be small.
We should try to speed up testing and fixing bugs in order to start
the next cycle timely.
Please shout if you are aware of an important bug.
Now, prio
Hello Ferruh,
On Wednesday 26 October 2016 07:55 PM, Ferruh Yigit wrote:
> Hi Shreyansh,
>
> On 10/26/2016 2:12 PM, Shreyansh Jain wrote:
>> On Wednesday 26 October 2016 06:30 PM, Shreyansh Jain wrote:
>>> rte_device/driver generalization patches [1] were merged without a change
>>> in the LIBABIV
On Wednesday 26 October 2016 08:53 PM, Thomas Monjalon wrote:
> 2016-10-26 15:25, Ferruh Yigit:
>> eal version seems already increased for this release, 2 => 3, in:
>> d7e61ad3ae36 ("log: remove deprecated history dump")
>
> Yes thanks.
>
>> So NO need to increase it again, sorry for late notice, I
multi-process support has been verified on non IA such as ARMv8.
Signed-off-by: Jerin Jacob
---
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/multi_proc_support.rst
b/doc/guides/prog_guide/multi_proc_suppor
Hi,
we would like to include Solarflare libefx-based PMD in the DPDK 17.02
and start the upstreaming process.
The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
Gbps adapters.
The driver has base driver. It is just fresh version of the same code
which is used in the FreeBSD [1
rte_device/driver generalization patches [1] were merged without a change
in the LIBABIVER macro. This patches bumps the macro of affected libs.
(librte_eal was already bumped; libcryptodev and libetherdev have been
bumped).
Details of ABI/API changes:
- EAL (version not bumped)
|- type field wa
Hi Maxime,
Seems indirect desc feature is causing serious performance
degradation on Haswell platform, about 20% drop for both
mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
both iofwd and macfwd.
I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz.
Could you please verify if thi
Hi Zhihong,
On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> Hi Maxime,
>
> Seems indirect desc feature is causing serious performance
> degradation on Haswell platform, about 20% drop for both
> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
> both iofwd and macfwd.
I tested PVP (with m
On 10/27/2016 11:10 AM, Maxime Coquelin wrote:
> Hi Zhihong,
>
> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>> Hi Maxime,
>>
>> Seems indirect desc feature is causing serious performance
>> degradation on Haswell platform, about 20% drop for both
>> mrg=on and mrg=off (--txqflags=0xf00, non-vec
2016-10-27 12:38, Shreyansh Jain:
> rte_device/driver generalization patches [1] were merged without a change
> in the LIBABIVER macro. This patches bumps the macro of affected libs.
It is not a macro but a Makefile variable.
> (librte_eal was already bumped; libcryptodev and libetherdev have bee
> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com]
> Sent: Thursday, October 27, 2016 5:55 PM
> To: Wang, Zhihong ; Yuanhan Liu
> ; stephen at networkplumber.org; Pierre
> Pfister (ppfister)
> Cc: Xie, Huawei ; dev at dpdk.org;
> vkaplans at redhat.com; m
On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
> Hi Zhihong,
>
> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >Hi Maxime,
> >
> >Seems indirect desc feature is causing serious performance
> >degradation on Haswell platform, about 20% drop for both
> >mrg=on and mrg=off (--txqfl
On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
>> Hi Zhihong,
>>
>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>>> Hi Maxime,
>>>
>>> Seems indirect desc feature is causing serious performance
>>> degradation on Haswell platform, ab
Hi,
First of all, welcome to DPDK!
2016-10-27 09:34, Andrew Rybchenko:
> Hi,
>
> we would like to include Solarflare libefx-based PMD in the DPDK 17.02
> and start the upstreaming process.
> The driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40
> Gbps adapters.
> The driver has
On Thu, Oct 27, 2016 at 12:35:11PM +0200, Maxime Coquelin wrote:
>
>
> On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> >On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
> >>Hi Zhihong,
> >>
> >>On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >>>Hi Maxime,
> >>>
> >>>Seems indirect des
On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin wrote:
>> Hi Zhihong,
>>
>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>>> Hi Maxime,
>>>
>>> Seems indirect desc feature is causing serious performance
>>> degradation on Haswell platform, ab
Hello Thomas,
On Thursday 27 October 2016 03:45 PM, Thomas Monjalon wrote:
> 2016-10-27 12:38, Shreyansh Jain:
>> rte_device/driver generalization patches [1] were merged without a change
>> in the LIBABIVER macro. This patches bumps the macro of affected libs.
>
> It is not a macro but a Makefile
rte_device/driver generalization patches [1] were merged without a change
in the LIBABIVER variable. This patches bumps the macro of affected libs:
- libcryptodev and libetherdev have been bumped
- librte_eal version changed in
d7e61ad3ae36 ("log: remove deprecated history dump")
Details of ABI
On Thursday 27 October 2016 04:59 PM, Shreyansh Jain wrote:
> index aa0c09a..db20567 100644
> --- a/doc/guides/rel_notes/release_16_11.rst
> +++ b/doc/guides/rel_notes/release_16_11.rst
> @@ -201,6 +201,32 @@ API Changes
> * The ``file_name`` data type of ``struct rte_port_source_params`` and
>
2016-10-27 17:02, Shreyansh Jain:
> Even though I have sent the v4, there is another possibility of
> splitting this log across API and ABI changes.
> Problem is that most of the changes are quite related in terms of impact
> on ABI and API. (some like rte_device is clear enough, though).
> Any s
Hi,
I have a DPDK application that binds to an interface and processes packets.
For debugging purposes I want to run tcpdump on this interface.
IYO, what is my best option with hurting the performance of the application
too much?
TIA,
Dror
On 10/26/2016 02:56 PM, Tomasz Kulasek wrote:
> Added API for `rte_eth_tx_prep`
>
> [...]
>
> Signed-off-by: Tomasz Kulasek
Acked-by: Olivier Matz
Hello Benjamin,
On Tue, Oct 25, 2016 at 11:50 PM, Ben Walker
wrote:
> If the user asks to probe multiple times, the probe
> callback should only be called on devices that don't have
> a driver already loaded.
>
> This is useful if a driver is registered after the
> execution of a program has sta
On Thu, Oct 27, 2016 at 3:28 PM, David Marchand
wrote:
> On Tue, Oct 25, 2016 at 11:50 PM, Ben Walker
> wrote:
>> If the user asks to probe multiple times, the probe
>> callback should only be called on devices that don't have
>> a driver already loaded.
>>
>> This is useful if a driver is regis
Hi,
I am crafting a packet in which the source MAC address as set in the Ethernet
header is different than the transmit port?s default MAC address. A packet
capture of the packets coming out of this port however comes with source MAC
address of the port?s default MAC address.
Altering the dest
> On Oct 27, 2016, at 6:33 AM, Padam Jeet Singh
> wrote:
>
> Hi,
>
> I am crafting a packet in which the source MAC address as set in the Ethernet
> header is different than the transmit port?s default MAC address. A packet
> capture of the packets coming out of this port however comes with
> On 27-Oct-2016, at 7:37 pm, Wiles, Keith wrote:
>
>
>> On Oct 27, 2016, at 6:33 AM, Padam Jeet Singh
>> wrote:
>>
>> Hi,
>>
>> I am crafting a packet in which the source MAC address as set in the
>> Ethernet header is different than the transmit port?s default MAC address. A
>> packet c
Hi Tomasz,
This is a major new function in the API and I still have some comments.
2016-10-26 14:56, Tomasz Kulasek:
> --- a/config/common_base
> +++ b/config/common_base
> +CONFIG_RTE_ETHDEV_TX_PREP=y
We cannot enable it until it is implemented in every drivers.
> struct rte_eth_dev {
>
Fixes: 75ef62a94301 ("net/mlx5: fix link speed capability information")
Fixes: 188408719888 ("net/mlx5: fix support for newer link speeds")
Signed-off-by: Nelio Laranjeiro
---
doc/guides/nics/features/mlx5.ini | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/nics/features/mlx5.ini
Introduction:
=
This patch set is direct derivative of Jan's original series [1],[2].
- This version is based on master HEAD (ca41215)
- In this, I am merging the series [11] back. It was initially part
of this set but I had split considering that those changes in PCI
were go
From: Jan Viktorin
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
--
Changes since v0:
- fix compilation error due to missing include
---
lib/librte_eal/common/include/rte_dev.h | 12
lib/librte_eal/common/include/rte_pci.h | 9 -
2 files changed, 12 insertio
From: Jan Viktorin
Generalize the PCI-specific pci_unbind_kernel_driver. It is now divided
into two parts. First, determination of the path and string identification
of the device to be unbound. Second, the actual unbind operation which is
generic.
BSD implementation updated as ENOTSUP
Signed-o
From: Jan Viktorin
Generalize the PCI-specific pci_get_kernel_driver_by_path. The function
is general enough, we have just moved it to eal.c, changed the prefix to
rte_eal and provided it privately to other parts of EAL.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
---
lib/librte
From: Jan Viktorin
The functions pci_map_resource, pci_unmap_resource are generic so the
pci_* prefix can be omitted. The functions are moved to the
eal_common_dev.c so they can be reused by other infrastructure.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
---
lib/librte_eal/bsd
From: Jan Viktorin
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
---
lib/librte_eal/common/include/rte_common.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index db5
From: Jan Viktorin
Define initial structures and functions for the SoC infrastructure.
This patch supports only a very minimal functions for now.
More features will be added in the following commits.
Includes rte_device/rte_driver inheritance of
rte_soc_device/rte_soc_driver.
Signed-off-by: Jan
From: Jan Viktorin
Registeration of a SoC driver through a helper RTE_PMD_REGISTER_SOC
(on the lines of RTE_PMD_REGISTER_PCI). soc_driver_list stores all the
registered drivers.
Test case has been introduced to verify the registration and
deregistration.
Signed-off-by: Jan Viktorin
[Shreyansh:
From: Jan Viktorin
SoC devices would be linked in a separate list (from PCI). This is used for
probe function.
A helper for dumping the device list is added.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/bsdapp/eal/rte_eal_version.
From: Jan Viktorin
Support --enable-soc. SoC support is disabled by default.
Signed-off-by: Jan Viktorin
[Shreyansh: Change --no-soc to --enable-soc; disabled by default]
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
doc/guides/testpmd_app_ug/run_app.rst | 4
lib/
From: Jan Viktorin
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/bsdapp/eal/Makefile| 1 +
lib/librte_eal/bsdapp/eal/eal.c | 4 +++
lib/librte_eal/bsdapp/eal/eal_soc.c | 46
lib/librte_eal/
From: Jan Viktorin
It is assumed that SoC Devices provided on command line are prefixed with
"soc:". This patch adds parse and attach support for such devices.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/eal_common_dev.c
From: Jan Viktorin
The flags are copied from the PCI ones. They should be refactorized into a
general set of flags in the future.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/include/rte_soc.h | 10 ++
1 file change
From: Jan Viktorin
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_eal/common/include/rte_soc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index
From: Jan Viktorin
Default implementation which scans the sysfs platform devices hierarchy.
For each device, extract the ueven and convert into rte_soc_device.
The information populated can then be used in probe to match against
the drivers registered.
Signed-off-by: Jan Viktorin
[Shreyansh: r
From: Jan Viktorin
Additional features introduced:
- Find kernel driver through sysfs bindings
- Dummy implementation for mapping to kernel driver
- DMA coherency value from sysfs
- Numa node number from sysfs
- Support for updating device during probe if already registered
Signed-off-by: J
From: Jan Viktorin
It is not necessary to place the rte_pci_driver at the beginning
of the rte_eth_dev struct anymore as we use the container_of macro
to get the parent pointer.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_e
From: Jan Viktorin
Now that different types of ethdev exist, check for presence of PCI dev
while copying out the info.
Similar would be done for SoC.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 2 ++
1 file chang
From: Jan Viktorin
We abstract access to the intr_handle here as we want to get
it either from the pci_dev or soc_dev.
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 14 --
1 file changed, 12 insertions(
From: Jan Viktorin
Signed-off-by: Jan Viktorin
Signed-off-by: Shreyansh Jain
Signed-off-by: Hemant Agrawal
---
lib/librte_ether/rte_ethdev.c | 148 +-
lib/librte_ether/rte_ethdev.h | 31 +
2 files changed, 177 insertions(+), 2 deletions(-)
dif
- rte_cryptodev_driver/rte_cryptodev_dev embeds rte_soc_driver/device for
linking SoC PMDs to crypto devices.
- Add probe and remove functions linked
Signed-off-by: Hemant Agrawal
Signed-off-by: Shreyansh Jain
---
lib/librte_cryptodev/rte_cryptodev.c | 122 -
>
> Hi Tomasz,
>
> This is a major new function in the API and I still have some comments.
>
> 2016-10-26 14:56, Tomasz Kulasek:
> > --- a/config/common_base
> > +++ b/config/common_base
> > +CONFIG_RTE_ETHDEV_TX_PREP=y
>
> We cannot enable it until it is implemented in every drivers.
Not su
2016-10-27 15:52, Ananyev, Konstantin:
>
> >
> > Hi Tomasz,
> >
> > This is a major new function in the API and I still have some comments.
> >
> > 2016-10-26 14:56, Tomasz Kulasek:
> > > --- a/config/common_base
> > > +++ b/config/common_base
> > > +CONFIG_RTE_ETHDEV_TX_PREP=y
> >
> > We cann
Hi Benjamin,
2016-10-24 18:16, Walker, Benjamin:
> Hi all,
>
> My name is Ben Walker and I'm the technical lead for SPDK (it's like DPDK, but
> for storage devices). SPDK relies on DPDK only for the base functionality in
> the
> EAL - memory management, the rings, and the PCI scanning code. A ke
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, October 27, 2016 5:02 PM
> To: Ananyev, Konstantin
> Cc: Kulasek, TomaszX ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation
>
> 2016-10-27 15:52, Ana
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, October 27, 2016 17:01
> To: Kulasek, TomaszX
> Cc: dev at dpdk.org; olivier.matz at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation
>
> Hi Tomas
2016-10-27 16:24, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2016-10-27 15:52, Ananyev, Konstantin:
> > > > Hi Tomasz,
> > > >
> > > > This is a major new function in the API and I still have some comments.
> > > >
> > > > 2016-10-26 14:56, Tomasz Kulasek
Hi
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, October 27, 2016 18:24
> To: Thomas Monjalon
> Cc: Kulasek, TomaszX ; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation
>
>
>
> > -Original Message-
> > From: Thomas Monjalo
On Fri, 28 Oct 2016 09:04:30 +0800
Remy Horton wrote:
> +
> +struct rte_stats_bitrate_s {
> + uint64_t last_ibytes;
> + uint64_t last_obytes;
> + uint64_t peak_ibits;
> + uint64_t peak_obits;
> + uint64_t ewma_ibits;
> + uint64_t ewma_obits;
> +};
> +
Reader/write access
From: Rasesh Mody
Using GCC_VERSION to check gcc version and decide whether to include
that compiler option.
Fixes: ec94dbc57362 ("qede: add base driver")
Fixes: ecc7a5a27ffe ("net/qede/base: fix 32-bit build")
Signed-off-by: Rasesh Mody
---
drivers/net/qede/Makefile | 4 ++--
1 file changed,
From: Harish Patil
Fix to advertise device's link speed capability based on current
link speed rather than returning driver supported speeds.
Fixes: 95e67b479506 ("net/qede: add 100G link speed capability")
Signed-off-by: Harish Patil
---
drivers/net/qede/qede_ethdev.c | 6 --
1 file chan
60 matches
Mail list logo
