A new major release is available:
https://fast.dpdk.org/rel/dpdk-19.02.tar.xz
If this release happened earlier, it would be called 19.01 :-)
Thanks to a reduced scope and good respect of the targets,
it is ready on the first day of the month for the very first time!
Indeed it is a short re
01/02/2019 10:23, John McNamara:
> Fix grammar, spelling and formatting of DPDK 19.02 release notes.
>
> Signed-off-by: John McNamara
Applied, thanks
On Fri, 2019-02-01 at 21:05 +, Eads, Gage wrote:
>
> >
> > -Original Message-
> > From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> > Sent: Friday, February 1, 2019 1:44 PM
> > To: Eads, Gage ; dev@dpdk.org
> > Cc: jer...@marvell.com; chao...@linux.vnet.ibm.com; nd ;
> > Richardson
> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Friday, February 1, 2019 1:44 PM
> To: Eads, Gage ; dev@dpdk.org
> Cc: jer...@marvell.com; chao...@linux.vnet.ibm.com; nd ;
> Richardson, Bruce ; Ananyev, Konstantin
> ; hemant.agra...@nxp.com;
> olivier.m..
On Fri, 2019-02-01 at 19:28 +, Eads, Gage wrote:
>
> >
> > -Original Message-
> > From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> > Sent: Friday, February 1, 2019 1:02 PM
> > To: Eads, Gage ; dev@dpdk.org
> > Cc: jer...@marvell.com; chao...@linux.vnet.ibm.com; nd ;
> > Richardson
> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Friday, February 1, 2019 1:02 PM
> To: Eads, Gage ; dev@dpdk.org
> Cc: jer...@marvell.com; chao...@linux.vnet.ibm.com; nd ;
> Richardson, Bruce ; Ananyev, Konstantin
> ; hemant.agra...@nxp.com;
> olivier.m..
On Fri, 2019-02-01 at 17:06 +, Eads, Gage wrote:
>
> >
> > -Original Message-
> > From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> > Sent: Monday, January 28, 2019 5:02 PM
> > To: Eads, Gage ; dev@dpdk.org
> > Cc: arybche...@solarflare.com; jer...@marvell.com;
> > chao...@linux.vn
On Fri, 2019-02-01 at 15:40 +, Eads, Gage wrote:
>
> >
> > -Original Message-
> > From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> > Sent: Wednesday, January 30, 2019 5:36 AM
> > To: Honnappa Nagarahalli ; Richardson,
> > Bruce ; Eads, Gage ;
> > dev@dpdk.org
> > Cc: nd
> > Subje
https://bugs.dpdk.org/show_bug.cgi?id=204
Bug ID: 204
Summary: Crash on Vmware esxi host when dpdk guest reboots.
Product: DPDK
Version: 18.11
Hardware: x86
OS: Other
Status: CONFIRMED
Severity: major
On Thu, 2019-01-31 at 18:09 +, Honnappa Nagarahalli wrote:
> + Phil and Hemant
>
>
>
> > > > > > Yes, we need to be inline with any other package. My
> > > > > > understanding is that the image will be same for v8,v9,v10
> > > > > > (any
> > > > > > input from distro engineers will help here
> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Wednesday, January 30, 2019 11:48 PM
> To: Eads, Gage ; dev@dpdk.org
> Cc: olivier.m...@6wind.com; arybche...@solarflare.com; Richardson, Bruce
> ; Ananyev, Konstantin
> ; Gavin Hu (Arm Techno
> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Monday, January 28, 2019 5:02 PM
> To: Eads, Gage ; dev@dpdk.org
> Cc: arybche...@solarflare.com; jer...@marvell.com;
> chao...@linux.vnet.ibm.com; nd ; Richardson, Bruce
> ; Ananyev, Konstantin
> ; hemant.a
On 1/31/2019 5:17 PM, Thomas Monjalon wrote:
>> +
>> +Reminder that new API should follow deprecation process to be able to
>> replace old API.
> This last sentence is not clear to me.
> I think you mean the old API should follow deprecation process
> to be removed (replaced).
Yes, we are trying
On 1/31/2019 5:49 PM, Thomas Monjalon wrote:
> 31/01/2019 18:07, Karuna Grewal:
>> Hi everyone,
>>
>> I saw the previous thread about DPDK's GSoC ideas. As someone having
>> experience using the same while investigating various userspace network
>> stack implementations, I want to know if there are
> -Original Message-
> From: Aaron Conole [mailto:acon...@redhat.com]
> Sent: Friday, January 25, 2019 9:16 PM
> To: Jay Rolette
> Cc: Mcnamara, John ; dev@dpdk.org; Thomas
> Monjalon ; Jerin Jacob
> ; Akhil Goyal ;
> Dumitrescu, Cristian ; Xu, Qian Q
> ; Yongseok Koh ; Maxime Coquelin
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementa
From: Aaron Conole
The vhost_scsi example code is set to build, even if the requisite header
file virtio_scsi.h isn't available. This happens on some Ubuntu systems
when some versions of the libc-dev package aren't available.
Check whether the virtio_scsi.h file exists, and if not, set the buil
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and
RFC 4115 allows a meter with either cir and/or eir configured.
When only one is configured a divide by zero would occur.
Fixes: 655796d2b5fb ("meter: support RFC4115 trTCM")
Cc: echau...@redhat.com
Signed-off-by: Eelco Chaudron
---
v2 - Removed configuration change that got included by acciden
RFC 4115 allows a meter with either cir and/or eir configured.
When only one is configured a divide by zero would occur.
Fixes: 655796d2b5fb ("meter: support RFC4115 trTCM")
Cc: echau...@redhat.com
Signed-off-by: Eelco Chaudron
---
config/common_linuxapp |4 ++--
lib/librte_meter/rte_
> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Wednesday, January 30, 2019 5:36 AM
> To: Honnappa Nagarahalli ; Richardson,
> Bruce ; Eads, Gage ;
> dev@dpdk.org
> Cc: nd
> Subject: Re: [RFC] lfring: lock-free ring buffer
>
> On Wed, 2019-01-30 at 05:1
On 01.02.2019 18:13, Jens Freimann wrote:
> On Fri, Feb 01, 2019 at 05:27:37PM +0300, Ilya Maximets wrote:
>> On 01.02.2019 13:03, Jens Freimann wrote:
>>> + if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
>>> + uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
>>> + hw
On Fri, Feb 01, 2019 at 05:27:37PM +0300, Ilya Maximets wrote:
On 01.02.2019 13:03, Jens Freimann wrote:
+ if (host_features & (1ULL << VIRTIO_NET_F_MTU)) {
+ uint32_t ether_hdr_len = ETHER_HDR_LEN + VLAN_TAG_LEN +
+ hw->vtnet_hdr_size;
+ i
In order to support the non-blocking ring[1], an API change (additional
argument to rte_ring_get_memsize()) is required in librte_ring. This commit
updates the deprecation notice to pave the way for its inclusion in
19.08.
[1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
Signed-off
On 01.02.2019 13:03, Jens Freimann wrote:
> Port configuration fails because offload flags don't match the expected
> value when max-pkt-len is set to a value that should enable receive port
> offloading but doesn't.
>
> There are two cases to consider:
>
> 1. VIRTIO_NET_F_MTU is set. Then we nee
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, February 1, 2019 5:17 AM
> To: dev@dpdk.org; Eads, Gage
> Cc: olivier.m...@6wind.com; arybche...@solarflare.com; Richardson, Bruce
> ; Ananyev, Konstantin
> ; step...@networkplumber.org; Mcnamara,
12/12/2018 17:38, Reshma Pattan:
> Added deprecation notice to replace rte_meter_color
> with rte_color.
>
> Signed-off-by: Reshma Pattan
> Acked-by: Cristian Dumitrescu
Acked-by: Jasvinder Singh
Acked-by: Mohammad Abdul Awal
Applied, thanks
22/01/2019 06:44, Nikhil Rao:
> rte_service_attr_get() is passed a uint32_t * to retrieve
> an attribute value, this will be changed to uin64_t * as per
> patch posted at http://patchwork.dpdk.org/patch/49968/
>
> Signed-off-by: Nikhil Rao
Acked-by: Harry van Haaren
Acked-by: Kevin Traynor
Ack
On Tue, Jan 22, 2019 at 6:46 AM Nikhil Rao wrote:
> rte_service_attr_get() is passed a uint32_t * to retrieve
> an attribute value, this will be changed to uin64_t * as per
> patch posted at http://patchwork.dpdk.org/patch/49968/
>
> Signed-off-by: Nikhil Rao
> ---
> doc/guides/rel_notes/deprec
On 2/1/19 2:41 PM, Kevin Traynor wrote:
On 01/22/2019 05:44 AM, Nikhil Rao wrote:
rte_service_attr_get() is passed a uint32_t * to retrieve
an attribute value, this will be changed to uin64_t * as per
patch posted at http://patchwork.dpdk.org/patch/49968/
Signed-off-by: Nikhil Rao
---
doc/gu
Hi Thomas, Akhil, Anoob,
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, February 1, 2019 11:14 AM
> To: dev@dpdk.org
> Cc: Akhil Goyal ; Anoob Joseph ; De
> Lara Guarch, Pablo
> ; Trahe, Fiona ; Jerin
> Jacob Kollanukkaran
> ; Narayana Prasad Ra
On 01/22/2019 05:44 AM, Nikhil Rao wrote:
> rte_service_attr_get() is passed a uint32_t * to retrieve
> an attribute value, this will be changed to uin64_t * as per
> patch posted at http://patchwork.dpdk.org/patch/49968/
>
> Signed-off-by: Nikhil Rao
> ---
> doc/guides/rel_notes/deprecation.rst
18/01/2019 16:31, Gage Eads:
> In order to support the non-blocking ring[1], an API change (additional
> argument to rte_ring_get_memsize()) is required in librte_ring. This commit
> updates the deprecation notice to pave the way for its inclusion in
> 19.05.
>
> [1] http://mails.dpdk.org/archives
There is only one ack for this change.
A deprecation requires more agreement (3 valuable acks).
Other opinions?
31/01/2019 10:53, Akhil Goyal:
> On 1/17/2019 3:09 PM, Anoob Joseph wrote:
> > Add new field ff_enable in rte_cryptodev_config. This enables
> > applications to control the features ena
16/01/2019 12:37, Bruce Richardson:
> Add a notice in the deprecation section of the release notes to call out
> the fact that the minimum supported meson version for DPDK will change
> from 19.05 onwards.
>
> Signed-off-by: Bruce Richardson
Acked-by: Luca Boccassi
Acked-by: Timothy Redaelli
Ac
30/01/2019 17:43, Bruce Richardson:
> At this stage, meson builds are widely supported for DPDK, and so
> the build system should be no longer called out as experimental.
> NOTE: this does not imply it's the primary build system, just that
> it's safe to use for day-to-day work and for packaging if
01/02/2019 11:28, Burakov, Anatoly:
> On 31-Jan-19 6:14 PM, Kevin Traynor wrote:
> > On 01/31/2019 05:05 PM, Anatoly Burakov wrote:
> >> Since 18.05, libnuma is pretty much required on Linux when using
> >> non-legacy mode, because without it, we cannot know where our
> >> hugepages are located [1]
On 31-Jan-19 6:14 PM, Kevin Traynor wrote:
On 01/31/2019 05:05 PM, Anatoly Burakov wrote:
Since 18.05, libnuma is pretty much required on Linux when using
non-legacy mode, because without it, we cannot know where our
hugepages are located [1].
In legacy mode, libnuma is not required because we
Port configuration fails because offload flags don't match the expected
value when max-pkt-len is set to a value that should enable receive port
offloading but doesn't.
There are two cases to consider:
1. VIRTIO_NET_F_MTU is set. Then we need to check if the requested
max-pkt-len fits into the
Fix grammar, spelling and formatting of DPDK 19.02 release notes.
Signed-off-by: John McNamara
---
doc/guides/rel_notes/release_19_02.rst | 80 +++---
1 file changed, 35 insertions(+), 45 deletions(-)
v3: rebased to master.
diff --git a/doc/guides/rel_notes/release_
40 matches
Mail list logo
