Re: [dpdk-dev] [PATCH v2] eal/windows: fix invalid thread handle

[Thomas Monjalon]

25/05/2020 03:02, Dmitry Kozlyuk:
> On Sat, 23 May 2020 00:25:56 -0700
> Tasnim Bashar  wrote:
> 
> > Casting thread ID to handle is not accurate way to get thread handle.
> > Need to use OpenThread function to get thread handle from thread ID.
> > 
> > pthread_setaffinity_np and pthread_getaffinity_np functions
> > for Windows are affected because of it.
> > 
> > Signed-off-by: Tasnim Bashar 
> > ---
> 
> Please use --in-reply-to=Message-ID-of-previous-version to send v2, etc.

I should update the doc to ask replying to the first patch.


> If you're using Outlook, you can find message ID as follows:
> 
> https://support.office.com/en-us/article/view-internet-message-headers-in-outlook-cd039382-dc6e-4264-ac74-c048563d212c

You can also find the message ID in patchwork or inbox.dpdk.org.


> For example, this is how this patch should have been sent:
> 
> git send-email --in-reply-to=20200522001112.48932-1-tbas...@mellanox.com ...

Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.

[Robin Jarry]

Hi Louise,

2020-05-22, Louise Kilheeney:
> This patch set converts all python scripts in the project to use
> python3 only. This is due to python2 being EOL in January 2020.
> 
> One script not tested: ./config/arm/armv8_machine.py
> 
> Louise Kilheeney (9):
>   app/test-bbdev: support python3 only
>   usertools/dpdk-devbind: support python3 only
>   usertools/dpdk-telemetry-client: support python3 only
>   usertools/dpdk-pmdinfo: support python3 only
>   usertools/cpu_layout: support python3 only
>   app/test-cmdline: support python3 only
>   app/test: support python3 only
>   devtools: support python3 only
>   config/arm: support python3 only

How did you test your changes?

Also, I had understood that python 2 support would not be dropped before
20.11: http://mails.dpdk.org/archives/dev/2020-February/157793.html

Did I miss something?

-- 
Robin

Re: [dpdk-dev] [PATCH v2] doc: announce the removal of legacy virtio support

[Maxime Coquelin]

Hi Jerrin,

I think what was agreed wasn't to remove Legacy Virtio support,
but instead remove support for probing legacy Virtio devices when they
are not bound to any Kernel drivers.

It should still be possible to use these legacy Virtio devices when
bound to VFIO or UIO.

Regards,
Maximle

On 5/25/20 7:46 AM, jer...@marvell.com wrote:
> From: Jerin Jacob 
> 
> The legacy virtio feature is not architecture agnostics.
> It relies on x86 IO port scheme support for its working.
> 
> The legacy virtio is only the consumer of RTE_KDRV_NONE in DPDK PCI
> subsystem. Legacy virtio removal will also optimize DPDK PCI enumeration
> management as it does not need to probe RTE_KDRV_NONE based
> devices anymore.
> 
> Legacy virtio feature removal is planned in the v20.11 release.
> 
> More details at http://patches.dpdk.org/patch/69351/
> 
> Cc: maxime.coque...@redhat.com
> Cc: david.march...@redhat.com
> Signed-off-by: Jerin Jacob 
> ---
>  doc/guides/rel_notes/deprecation.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index cf8b1eb7b..79a03432c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -107,3 +107,11 @@ Deprecation Notices
>Python 2 support will be completely removed in 20.11.
>In 20.08, explicit deprecation warnings will be displayed when running
>scripts with Python 2.
> +
> +* virtio: The legacy virtio feature is not architecture agnostics.
> +  It relies on x86 IO port scheme support for its working.
> +  The legacy virtio is only the consumer of RTE_KDRV_NONE in DPDK PCI 
> subsystem.
> +  Legacy virtio removal will also optimize DPDK PCI enumeration management as
> +  it does not need to probe RTE_KDRV_NONE based devices anymore.
> +  Legacy virtio feature removal is planned in the v20.11 release.
> +  More details at http://patches.dpdk.org/patch/69351/
> 

Re: [dpdk-dev] [PATCH v2] doc: announce the removal of legacy virtio support

[Jerin Jacob]

On Mon, May 25, 2020 at 1:03 PM Maxime Coquelin
 wrote:
>
> Hi Jerrin,

Hi Maxime,

>
> I think what was agreed wasn't to remove Legacy Virtio support,
> but instead remove support for probing legacy Virtio devices when they
> are not bound to any Kernel drivers.
>
> It should still be possible to use these legacy Virtio devices when
> bound to VFIO or UIO.

I was not aware that legacy virtio can be used with VFIO or UIO.
I will send the v3.

>
> Regards,
> Maximle
>
> On 5/25/20 7:46 AM, jer...@marvell.com wrote:
> > From: Jerin Jacob 
> >
> > The legacy virtio feature is not architecture agnostics.
> > It relies on x86 IO port scheme support for its working.
> >
> > The legacy virtio is only the consumer of RTE_KDRV_NONE in DPDK PCI
> > subsystem. Legacy virtio removal will also optimize DPDK PCI enumeration
> > management as it does not need to probe RTE_KDRV_NONE based
> > devices anymore.
> >
> > Legacy virtio feature removal is planned in the v20.11 release.
> >
> > More details at http://patches.dpdk.org/patch/69351/
> >
> > Cc: maxime.coque...@redhat.com
> > Cc: david.march...@redhat.com
> > Signed-off-by: Jerin Jacob 
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst 
> > b/doc/guides/rel_notes/deprecation.rst
> > index cf8b1eb7b..79a03432c 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -107,3 +107,11 @@ Deprecation Notices
> >Python 2 support will be completely removed in 20.11.
> >In 20.08, explicit deprecation warnings will be displayed when running
> >scripts with Python 2.
> > +
> > +* virtio: The legacy virtio feature is not architecture agnostics.
> > +  It relies on x86 IO port scheme support for its working.
> > +  The legacy virtio is only the consumer of RTE_KDRV_NONE in DPDK PCI 
> > subsystem.
> > +  Legacy virtio removal will also optimize DPDK PCI enumeration management 
> > as
> > +  it does not need to probe RTE_KDRV_NONE based devices anymore.
> > +  Legacy virtio feature removal is planned in the v20.11 release.
> > +  More details at http://patches.dpdk.org/patch/69351/
> >
>

[dpdk-dev] [PATCH v3] doc: announce the removal of RTE_KDRV_NONE based probe

[jerinj]

From: Jerin Jacob 

In order to optimize the DPDK PCI enumeration management, RTE_KDRV_NONE
based device driver probing will be removed in v20.08.
The legacy virtio is the only consumer of RTE_KDRV_NONE based
device  driver probe scheme.
The legacy virtio support will be available through existing VFIO/UIO
based kernel driver scheme.
More details at http://patches.dpdk.org/patch/69351/

Cc: maxime.coque...@redhat.com
Cc: david.march...@redhat.com
Signed-off-by: Jerin Jacob 
---
 doc/guides/rel_notes/deprecation.rst | 8 
 1 file changed, 8 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index 2d11bae93..c7fb368ff 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -132,3 +132,11 @@ Deprecation Notices
   Python 2 support will be completely removed in 20.11.
   In 20.08, explicit deprecation warnings will be displayed when running
   scripts with Python 2.
+
+* pci: Remove ``RTE_KDRV_NONE`` based device driver probing.
+  In order to optimize the DPDK PCI enumeration management, ``RTE_KDRV_NONE``
+  based device driver probing will be removed in v20.08.
+  The legacy virtio is the only consumer of ``RTE_KDRV_NONE`` based device
+  driver probe scheme. The legacy virtio support will be available through
+  the existing VFIO/UIO based kernel driver scheme.
+  More details at http://patches.dpdk.org/patch/69351/
-- 
2.26.2

Re: [dpdk-dev] [PATCH v3] doc: announce the removal of RTE_KDRV_NONE based probe

[Maxime Coquelin]

On 5/25/20 10:15 AM, jer...@marvell.com wrote:
> From: Jerin Jacob 
> 
> In order to optimize the DPDK PCI enumeration management, RTE_KDRV_NONE
> based device driver probing will be removed in v20.08.
> The legacy virtio is the only consumer of RTE_KDRV_NONE based
> device  driver probe scheme.
> The legacy virtio support will be available through existing VFIO/UIO
> based kernel driver scheme.
> More details at http://patches.dpdk.org/patch/69351/
> 
> Cc: maxime.coque...@redhat.com
> Cc: david.march...@redhat.com
> Signed-off-by: Jerin Jacob 
> ---
>  doc/guides/rel_notes/deprecation.rst | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst 
> b/doc/guides/rel_notes/deprecation.rst
> index 2d11bae93..c7fb368ff 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -132,3 +132,11 @@ Deprecation Notices
>Python 2 support will be completely removed in 20.11.
>In 20.08, explicit deprecation warnings will be displayed when running
>scripts with Python 2.
> +
> +* pci: Remove ``RTE_KDRV_NONE`` based device driver probing.
> +  In order to optimize the DPDK PCI enumeration management, ``RTE_KDRV_NONE``
> +  based device driver probing will be removed in v20.08.
> +  The legacy virtio is the only consumer of ``RTE_KDRV_NONE`` based device
> +  driver probe scheme. The legacy virtio support will be available through
> +  the existing VFIO/UIO based kernel driver scheme.
> +  More details at http://patches.dpdk.org/patch/69351/
> 

Acked-by: Maxime Coquelin 

Thanks,
Maxime

[dpdk-dev] [PATCH] net/octeontx2: fix seg fault on running procinfo

[Harman Kalra]

Segmentation fault has been observed while running procinfo
with reset options i.e. --stats-reset and --xstats-reset.
Reason is procinfo runs as a secondary process and tries to
hold a lock which is part of struct mdev, which was not
allocated as part of shared mememory.

Fixes: 5ca59711f771 ("common/octeontx2: add mailbox base support infra")
Cc: sta...@dpdk.org

Signed-off-by: Harman Kalra 
---
 drivers/common/octeontx2/otx2_mbox.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/common/octeontx2/otx2_mbox.c 
b/drivers/common/octeontx2/otx2_mbox.c
index 2b7810929..6df1e8ea6 100644
--- a/drivers/common/octeontx2/otx2_mbox.c
+++ b/drivers/common/octeontx2/otx2_mbox.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include "otx2_mbox.h"
 #include "otx2_dev.h"
@@ -36,7 +37,7 @@ otx2_mbox_fini(struct otx2_mbox *mbox)
 {
mbox->reg_base = 0;
mbox->hwbase = 0;
-   free(mbox->dev);
+   rte_free(mbox->dev);
mbox->dev = NULL;
 }
 
@@ -128,7 +129,9 @@ otx2_mbox_init(struct otx2_mbox *mbox, uintptr_t hwbase, 
uintptr_t reg_base,
return -ENODEV;
}
 
-   mbox->dev = malloc(ndevs * sizeof(struct otx2_mbox_dev));
+   mbox->dev = rte_zmalloc("mbox dev",
+   ndevs * sizeof(struct otx2_mbox_dev),
+   OTX2_ALIGN);
if (!mbox->dev) {
otx2_mbox_fini(mbox);
return -ENOMEM;
-- 
2.18.0

Re: [dpdk-dev] [PATCH v3] doc: plan splitting the ethdev ops struct

[Andrew Rybchenko]

On 5/25/20 2:18 AM, Thomas Monjalon wrote:
> 04/03/2020 10:57, Ferruh Yigit:
>> For the ABI compatibility it is better to hide internal data structures
>> from the application as much as possible. But because of some inline
>> functions 'struct eth_dev_ops' can't be hidden completely.
>>
>> Plan is to split the 'struct eth_dev_ops' into two as ones used by
>> inline functions and ones not used, and hide the second part that not
>> used by inline functions completely to the application.
>>
>> Because of ABI break the work will be done in 20.11
>>
>> Signed-off-by: Ferruh Yigit 
>> ---
>> +* ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as 
>> possible
>> +  will be done in 20.11.
>> +  Currently the ``struct eth_dev_ops`` struct is accessible by the 
>> application
>> +  because some inline functions, like ``rte_eth_tx_descriptor_status()``,
>> +  access the struct directly.
>> +  The struct will be separate in two, the ops used by inline functions will 
>> be moved
>> +  next to Rx/Tx burst functions, rest of the ``struct eth_dev_ops`` struct 
>> will be
>> +  moved to header file for drivers to hide it from applications.
> Acked-by: Thomas Monjalon 

Acked-by: Andrew Rybchenko 

Re: [dpdk-dev] [PATCH v4] examples/l2fwd: add cmdline option for forwarding port info

[Bruce Richardson]

On Sun, May 24, 2020 at 06:13:22PM +0200, Thomas Monjalon wrote:
> Bruce, as maintainer of l2fwd example, any opinion about this change?
> 
Assuming all previous discussion on it is resolved, I'm fine with this
patch, though I suspect it will only make 20.08 now.

Acked-by: Bruce Richardson 

> 
> 11/05/2020 02:23, Pavan Nikhilesh Bhagavatula:
> > Hi Vipin,
> > 
> > >Hi Pavan,
> > >
> > >snipped
> > >> >
> > >> >Should we check & warn the user if
> > >> >1. port speed mismatch
> > >> >2. on different NUMA
> > >> >3. port pairs are physical and vdev like tap, and KNI (performance).
> > >> >
> > >>
> > >> Sure, it can be a separate patch as it will be applicable for multiple
> > >examples.
> > >I believe this patch is for example `l2fwd`. But you would like to have to
> > >updated for all `example`. I am ok for this.
> > >
> > >snipped
> > >> >
> > >> >Should not the check_port_pair be after this? If the port is not
> > >> >enabled in port_mask will you skip that pair? or skip RX-TX from that
> > >port?
> > >>
> > >> We check every port pair against l2fwd_enabled_port_mask in
> > >> check_port_pair_config()
> > >
> > >
> > >>
> > >snipped
> > >> >
> > >> >As mentioned above there can ports in mask which might be
> > >disabled for
> > >> >port pair. Should not that be skipped rather than setting last port rx-
> > >> >tx loopback?
> > >>
> > >> There could be scenarios where user might want to test 2x10G and
> > >1x40G Why
> > >> force the user to explicitly mention 1x40G as port pair of itself in the
> > >portpair
> > >> config?
> > >I am not sure if I follow your thought, as your current port map only
> > >allows `1:1` mapping by `struct port_pair_params`. This can be to self
> > >like `(port0:port0),(port1:port1)` or `(port-0:port-1)`.
> > >
> > >1. But current `l2fwd_parse_port_pair_config` does not consider the
> > >same port mapping as we have hard check for `if (nb_port_pair_params
> > >>= RTE_MAX_ETHPORTS/2)`.
> > >
> > >2. `l2fwd_enabled_port_mask` is global variable of user port mask. This
> > >can contain both valid and invalid mask. Hence we check
> > >`l2fwd_enabled_port_mask & ~((1 << nb_ports) - 1)`.
> > >
> > >3. can these scenarios are true if we invoke `check_port_pair_config`
> > >before actual port_mask check.
> > > a. there are only 4 ports, hence possible mask is `0xf`.
> > > b. user passes port argument as `0xe`
> > > c. `check_port_pair_config` gets masks for `(1,3)` as input and
> > >populates `port_pair_config_mask`.
> > > d.  As per the code, port 2 which is valid port and part of user port mask
> > >will have lastport (which is port 3)? May be I did understand the logic
> > >correct. Can you help me?
> > 
> > Here user needs to explicitly mention (2,2) for port 2 to be setup else it 
> > will be skipped. 
> > If you see `check_port_pair_config` below we disable the ports that are not 
> > Mentioned in portmap.
> > 
> > "
> > check_port_pair_config(void)
> > {
> > 
> > 
> > port_pair_config_mask |= port_pair_mask;
> > }
> > 
> > l2fwd_enabled_port_mask &= port_pair_config_mask;
> > 
> > return 0;
> > }
> > "
> > 
> > 
> > >
> > >So my concerns are 1) there is no same port mapping, 2) my
> > >understanding on lastport logic is not clear and 3) as per the code there
> > >is 1:N but 1:1.
> > >
> > >Hence there should be sufficient warning to user if port are of wrong
> > >speed and NUMA.
> > 
> > Unless the user disables stats using -T 0 option all the prints will be 
> > skipped.
> > 
> > >
> > >Note: current speed can be fetched only if the port are started too (in
> > >Fortville).
> > >
> > >snipped
> 
> 
> 
> 

[dpdk-dev] Consider improving the DPDK contribution processes

[Morten Brørup]

Dear DPDK Techboard,

I am writing this to raise awareness about the environment for contributing to 
DPDK, as I feel that it could be improved. This is not a personal thing - I 
have thick skin - but a general observation. I urge the DPDK Techboard to spend 
some time to focus on the process, and not only on the technology.

Contributing to DPDK is not easy for infrequent contributors:

1. Infrequent contributors are limited by not being deeply familiar with the 
coding style and the commit style, so their style is not always 100 % spot on.
2. Infrequent contributors are limited by not having built trust by the 
maintainers and frequent contributors, and thus their contributions undergo 
more detailed reviews and get more negative (or: perceived negative) feedback, 
where trusted contributors are given more slack. (In theory, every contribution 
should be treated equal, but in reality it makes sense allocating fewer 
resources to review contributions from developers with a proven track record.)
3. Infrequent contributors may not be deeply familiar with the 
development/contribution tools. E.g. how to use git the "DPDK way".

Additionally, when contributing to old DPDK code, checkpatch complains about 
coding style violations stemming from the existing old code. This also raises 
the barrier and decreases the motivation to contribute - a contributor getting 
negative feedback about something he didn't even do.


Here are a couple of anonymous examples from the mailing list:

An infrequent contributor got minor coding style suggestions to a patch, 
although the coding style was similar to that of a closely related function in 
the same library, but not perfectly matching the official coding style. I think 
we could be more lax about coding style, except if the coding style directly 
violates automatic coding style validation tools.

Another infrequent contributor got patch style feedback about a small patch, 
suggesting to split it up into three patches. The official contributing guide 
says that small changes should be kept together in the same patch. The patch in 
question could be considered three bug fixes, so splitting it up might be 
appropriate, or it could be considered fixing three variations of the same bug, 
so keeping it together as one would be appropriate. I think we could be more 
lax about patch style, except if the patches are completely incomprehensible.

It is not all bad, though! I have more than once seen excellent feedback to a 
suggested patch, where an expert reviewer took the time and effort to explain - 
in an educational and welcoming tone - what was wrong about the patch and the 
contributor's assumptions.


In summary, I think that DPDK has grown to a point where we hopefully will see 
more contributions from outsiders and newcomers, and we need to adapt to it, so 
that they get a positive experience from contributing, and keep coming back 
with more.

Improving the process should be an ongoing discussion. Here are two areas for 
discussion:

1. Keep expanding the contributor documentation. It is already far better than 
for most projects, but there is always room for improvement. Assume that the 
reader is intelligent, but has limited information in advance. E.g. Patchwork 
and Bugzilla are barely mentioned, and it is only described how to use them 
when submitting a patch.

2. When giving feedback on the mailing list, consider how it may be received, 
weighing the balance between accepting imperfection and educating the 
contributor.


DPDK is a great project, and the contribution process described above sounds a 
lot worse than it actually is. But I just can't get enough rainbows and 
unicorns! :-)


Med venlig hilsen / kind regards

Morten Brørup
CTO


SmartShare Systems A/S
Tonsbakken 16-18
DK-2740 Skovlunde
Denmark

Office  +45 70 20 00 93
Direct  +45 89 93 50 22
Mobile +45 25 40 82 12

m...@smartsharesystems.com
www.smartsharesystems.com

Re: [dpdk-dev] [EXT] Re: [PATCH] eal: fix epoll fd list rebuild

[Harman Kalra]

On Sun, May 24, 2020 at 05:30:26PM +0200, Thomas Monjalon wrote:
> External Email
> 
> --
> 11/05/2020 15:43, Harman Kalra:
> > An issue has been observed where epoll file descriptor
> > list rebuilds every time an interrupt/alarm event is
> > received.
> > 
> > eal_intr_process_interrupts() should notify pipe fd only
> > if any source is removed from the source list i.e (rv > 0)
> > 
> > Fixes: 0c7ce182a760 ("eal: add pending interrupt callback unregister"
> > Cc: sta...@dpdk.org
> > 
> > Signed-off-by: Harman Kalra 
> 
> This patch is missing 20.05 because no review was done.
> In general, we are missing a maintainer on "interrupts" area.

Hi Thomas,

If everybody is fine we can take up the responsibility of maintaining
interrupt subsystem. I can send a patch to update maintainer list for
the same.

Thanks
Harman

> 
> 

Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.

[Bruce Richardson]

On Mon, May 25, 2020 at 09:27:17AM +0200, Robin Jarry wrote:
> Hi Louise,
> 
> 2020-05-22, Louise Kilheeney:
> > This patch set converts all python scripts in the project to use
> > python3 only. This is due to python2 being EOL in January 2020.
> > 
> > One script not tested: ./config/arm/armv8_machine.py
> > 
> > Louise Kilheeney (9):
> >   app/test-bbdev: support python3 only
> >   usertools/dpdk-devbind: support python3 only
> >   usertools/dpdk-telemetry-client: support python3 only
> >   usertools/dpdk-pmdinfo: support python3 only
> >   usertools/cpu_layout: support python3 only
> >   app/test-cmdline: support python3 only
> >   app/test: support python3 only
> >   devtools: support python3 only
> >   config/arm: support python3 only
> 
> How did you test your changes?
> 
> Also, I had understood that python 2 support would not be dropped before
> 20.11: http://mails.dpdk.org/archives/dev/2020-February/157793.html
> 
> Did I miss something?
> 
The 20.11 was just a suggestion from me, but I'm not sure it was ever
definitively agreed upon. I'd be ok with removing python2 support in either
20.08 or deferring to 20.11. I don't think the patches would be different
no matter what release it being targetted. :-)
Is there a particular concern around removing python2 support? I thought
all linux distros now have python3, and many are stopping installing
python2 by default also.

Re: [dpdk-dev] [PATCH 20.08 9/9] config/arm: support python3 only

[Bruce Richardson]

On Sat, May 23, 2020 at 11:27:42PM +0200, Thomas Monjalon wrote:
> 22/05/2020 16:10, Kilheeney, Louise:
> > From: Thomas Monjalon  
> > > 22/05/2020 15:23, Louise Kilheeney:
> > > > Changed script to explicitly use python3 only.
> > > 
> > > What is the reason of this change?
> > 
> > since python 2 is EOL, Making these scripts to use python3-only,
> > it's part of a general update to have everything use python3.
> > This is already using python 3 and this makes it explicit.
> 
> This is to avoid maintaining python 2 compatibility I guess.
> Please insert this real reason in the git commit log.
> 
Also, python 2 may not be installed (unless explicitly requested) on 
modern distro releases. My Ubuntu 20.04 still only had a "python3" binary,
no "python" binary.

> 
> > > --- a/config/arm/armv8_machine.py
> > > +++ b/config/arm/armv8_machine.py
> > > @@ -1,4 +1,4 @@
> > > -#!/usr/bin/python
> > > +#!/usr/bin/python3
> 
> Are you sure all OS have /usr/bin/python3?
> Is it called "python" sometimes?
> Is it always located in /usr/bin/?
> Shouldn't we use "#! /usr/bin/env python3" ?
> 
Good catch.
+1 for this. On BSD python is in /usr/local/bin

Re: [dpdk-dev] [PATCH] doc: clarify spaces for alignment note

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Sunday, May 24, 2020 11:47 PM
> To: Kevin Traynor 
> Cc: Mcnamara, John ; Yigit, Ferruh
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: clarify spaces for alignment note
> 
> 11/03/2019 19:39, Kevin Traynor:
> > Make clear that spaces are only for alignments less than tab size.
> >
> > Signed-off-by: Kevin Traynor 
> > ---
> > --- a/doc/guides/contributing/coding_style.rst
> > +++ b/doc/guides/contributing/coding_style.rst
> > -   Global whitespace rule in DPDK, use tabs for indentation, spaces for
> alignment.
> > +   Global whitespace rule in DPDK, use tabs for indentation, spaces for
> smaller alignments.
> 
> tab Vs spaces 😃

The forever-war!

> 
> I am not sure what is the most followed convention in DPDK.
> I thought most of alignments were done with spaces only.

That was my understanding too: tabs for indentation, spaces for alignment. 

John

Re: [dpdk-dev] [PATCH] telemetry: fix error and warning printfs

[Bruce Richardson]

On Sun, May 24, 2020 at 06:05:53PM +0200, Thomas Monjalon wrote:
> 22/05/2020 18:48, Bruce Richardson:
> > On Fri, May 22, 2020 at 10:04:44PM +0530, Jerin Jacob wrote:
> > > On Fri, May 22, 2020 at 7:21 PM Ciara Power  wrote:
> > > >
> > > > Initially, printf was used to indicate and error/warning resulting from
> > > > telemetry initialisation. This is now fixed to use EAL logs for
> > > > warnings, and the unnecessary printf for an error is removed.
> > > >
> > > > Fixes: eeb486f3ba65 ("eal: add telemetry as dependency")
> > > > Fixes: dd6275a424ac ("telemetry: fix error log output")
> > > > Cc: david.march...@redhat.com
> > > >
> > > > Signed-off-by: Ciara Power 
> > > > ---
> > > > --- a/lib/librte_eal/linux/eal.c
> > > > +++ b/lib/librte_eal/linux/eal.c
> > > > +   if (error_str != NULL)
> > > > +   RTE_LOG(WARNING, EAL, "%s\n", error_str);
> > > 
> > > "EAL: No legacy callbacks, legacy socket not created" comes all the times 
> > > now.
> > > Should we treat this as a warning? as it comes for with for the
> > > built-in applications?
> > > If it is important why not have a default handler in the EAL library?
> > 
> > Perhaps the warning level could be changed to INFO.
> > BTW: if you compile with jansson library available, the legacy callbacks
> > will be available and this will be silenced.
> 
> Applied with log level set as NOTICE.
> 
Thanks.

Re: [dpdk-dev] [PATCH v1] doc: update release notes for 20.05

[Mcnamara, John]

> -Original Message-
> From: Thomas Monjalon 
> Sent: Sunday, May 24, 2020 11:56 PM
> To: Mcnamara, John 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] doc: update release notes for 20.05
> 
> 22/05/2020 16:06, John McNamara:
> > +* **Added additional algorithms to the Cryptodev API.**
> >
> > +  Added additional algorithms and updated support to the Cryptodev
> > + PMD and  APIs, including:
> >
> > +  * Added support for intel-ipsec-mb version 0.54 to the following
> PMDs: AESNI
> > +MB, AESNI GCM, ZUC, KASUMI, SNOW 3G.
> 
> These are specific to Intel virtual PMDs, not cryptodev API.

Ok. I'll make these changes and send a v2.

Re: [dpdk-dev] [PATCH v1] doc: update release notes for 20.05

[Mcnamara, John]

> -Original Message-
> From: Kevin Traynor 
> Sent: Friday, May 22, 2020 4:18 PM
> To: Mcnamara, John ; dev@dpdk.org
> Cc: tho...@monjalon.net
> Subject: Re: [dpdk-dev] [PATCH v1] doc: update release notes for 20.05
> 
> On 22/05/2020 15:06, John McNamara wrote:
> > Fix grammar, spelling and formatting of DPDK 20.05 release notes.
> >
> > Signed-off-by: John McNamara 
> > ---
> >  doc/guides/rel_notes/release_20_05.rst | 264
> > +++--
> >  1 file changed, 116 insertions(+), 148 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_20_05.rst
> > b/doc/guides/rel_notes/release_20_05.rst
> > index 8470690..d10a1f4 100644
> > --- a/doc/guides/rel_notes/release_20_05.rst
> > +++ b/doc/guides/rel_notes/release_20_05.rst
> > @@ -56,38 +56,38 @@ New Features
> >   Also, make sure to start the actual text at the margin.
> >   =
> >
> > -* **Added Trace Library and Tracepoints**
> > +* **Added Trace Library and Tracepoints.**
> >
> > -  A native implementation of ``common trace format(CTF)`` based trace
> > library
> > -  has been added to provide the ability to add tracepoints in
> > -  application/library to get runtime trace/debug information for
> > control and
> > +  A native implementation of "common trace format" (CTF) based trace
> > + library
> 
> Not sure if the "" are intentional?


They were intentional but maybe not correct. I should have probably capitalized 
the words.

I'll fix this and the other suggested changes.

John

Re: [dpdk-dev] [PATCH] dpdk-setup.sh: Prevent infinite loop, when end of input.

[Piotr]

Hi


The script dpdk-setup.sh was froze wit full cpu usage when EOF input.  
For example:



dpdk-setup.sh <<< '11'


or


dpdk-setup.sh <
30/03/2020 16:18, Piotr Sieduszewski:

From: Piotr Sieduszewski 

Signed-off-by: Piotr Sieduszewski 

Please add some explanations, it may help getting reviews.
Thanks

Re: [dpdk-dev] [PATCH] dpdk-setup.sh: Prevent infinite loop, when end of input.

[Sieduszewski, Piotr]

Hi



I send answer yesterday, but now I put more examples from my scripts at work:





as first, very simple deadlock:

Dpd-setup.sh < /dev/null





Deadlock without patch:



for NIC in ${RTE_NIC-:3d:00.1} ; do

$RTE_SDK/usertools/dpdk-setup.sh <<< "51

${NIC}



62

"

Done



Above works only witch additional empty line:



for NIC in ${RTE_NIC-:3d:00.1} ; do

$RTE_SDK/usertools/dpdk-setup.sh <<< "51

${NIC}



62



"

Done





.. or other deadlock:



usertools/dpdk-setup.sh <<< '41



62

'



usertools/dpdk-setup.sh <<< '41



62



'





Regards



Piotr





-Original Message-
From: Thomas Monjalon 
Sent: 2020 May 24 19:08
To: Sieduszewski, Piotr 
Cc: dev@dpdk.org; Piotr Sieduszewski ; 
sarosh.a...@emumba.com; m.bi...@emumba.com
Subject: Re: [dpdk-dev] [PATCH] dpdk-setup.sh: Prevent infinite loop, when end 
of input.



30/03/2020 16:18, Piotr Sieduszewski:

> From: Piotr Sieduszewski 
> mailto:piotr.sieduszew...@intel.com>>

>

> Signed-off-by: Piotr Sieduszewski 
> mailto:piotr.sieduszew...@intel.com>>



Please add some explanations, it may help getting reviews.

Thanks




-
Intel Technology Poland sp. z o.o.
ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia 
Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | 
Kapita zakadowy 200.000 PLN.
Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe 
zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, 
prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek 
przegldanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by others 
is strictly prohibited.
 

Re: [dpdk-dev] [PATCH v3] doc: plan splitting the ethdev ops struct

[David Marchand]

On Wed, Mar 4, 2020 at 10:57 AM Ferruh Yigit  wrote:
>
> For the ABI compatibility it is better to hide internal data structures
> from the application as much as possible. But because of some inline
> functions 'struct eth_dev_ops' can't be hidden completely.
>
> Plan is to split the 'struct eth_dev_ops' into two as ones used by
> inline functions and ones not used, and hide the second part that not
> used by inline functions completely to the application.
>
> Because of ABI break the work will be done in 20.11
>
> Signed-off-by: Ferruh Yigit 

Acked-by: David Marchand 


-- 
David Marchand

Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.

[Robin Jarry]

2020-05-25, Bruce Richardson:
> The 20.11 was just a suggestion from me, but I'm not sure it was ever
> definitively agreed upon. I'd be ok with removing python2 support in either
> 20.08 or deferring to 20.11. I don't think the patches would be different
> no matter what release it being targetted. :-)
> Is there a particular concern around removing python2 support? I thought
> all linux distros now have python3, and many are stopping installing
> python2 by default also.

Absolutely no concern around getting rid of Python 2 support :-)

Thanks for the clarification.

-- 
Robin

Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.

[Kilheeney, Louise]

I tested all scripts by running each of them manually, if you have any input 
into what tests you thinks would be good to run please do let me know.  

Louise Kilheeney

> -Original Message-
> From: Robin Jarry 
> Sent: Monday 25 May 2020 08:27
> To: Kilheeney, Louise 
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.
> 
> Hi Louise,
> 
> 2020-05-22, Louise Kilheeney:
> > This patch set converts all python scripts in the project to use
> > python3 only. This is due to python2 being EOL in January 2020.
> >
> > One script not tested: ./config/arm/armv8_machine.py
> >
> > Louise Kilheeney (9):
> >   app/test-bbdev: support python3 only
> >   usertools/dpdk-devbind: support python3 only
> >   usertools/dpdk-telemetry-client: support python3 only
> >   usertools/dpdk-pmdinfo: support python3 only
> >   usertools/cpu_layout: support python3 only
> >   app/test-cmdline: support python3 only
> >   app/test: support python3 only
> >   devtools: support python3 only
> >   config/arm: support python3 only
> 
> How did you test your changes?
> 
> Also, I had understood that python 2 support would not be dropped before
> 20.11: http://mails.dpdk.org/archives/dev/2020-February/157793.html
> 
> Did I miss something?
> 
> --
> Robin

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Jerin Jacob]

>
> Here are a couple of anonymous examples from the mailing list:
>
> An infrequent contributor got minor coding style suggestions to a patch, 
> although the coding style was similar to that of a closely related function 
> in the same library, but not perfectly matching the official coding style. I 
> think we could be more lax about coding style, except if the coding style 
> directly violates automatic coding style validation tools.
>
> Another infrequent contributor got patch style feedback about a small patch, 
> suggesting to split it up into three patches. The official contributing guide 
> says that small changes should be kept together in the same patch. The patch 
> in question could be considered three bug fixes, so splitting it up might be 
> appropriate, or it could be considered fixing three variations of the same 
> bug, so keeping it together as one would be appropriate. I think we could be 
> more lax about patch style, except if the patches are completely 
> incomprehensible.
>

A lot of patch style can be fixed automatically through clang-format.

Please find below the Linux kernel documentation for its clang-format and usage.

https://www.kernel.org/doc/html/latest/process/clang-format.html
https://github.com/torvalds/linux/blob/master/.clang-format

Maybe we could add .clang-format file for DPDK.
I have been using the following clang-format configuration for DPDK[1]
May be for once, we need to fix the coding standard issue with the
existing codebase using clang-format.

[1]
"{ BasedOnStyle: LLVM, IndentWidth: 8, TabWidth: 8, UseTab: Always,
AllowShortIfStatementsOnASingleLine: false, IndentCaseLabels: false,
ColumnLimit: 80, AllowShortFunctionsOnASingleLine: false,
AlwaysBreakAfterReturnType: AllDefinitions, ColumnLimit: 80,
ConstructorInitializerAllOnOneLineOrOnePerLine: true,
ConstructorInitializerIndentWidth: 8, ContinuationIndentWidth: 8,
BreakBeforeBraces: Linux, AllowShortBlocksOnASingleLine: false,
AlignConsecutiveAssignments: false, AlignEscapedNewlines: Right,
AlignConsecutiveMacros : true, MaxEmptyLinesToKeep : 1,
Cpp11BracedListStyle : true, AlignTrailingComments : true,
ForEachMacros: ['STAILQ_FOREACH', 'rte_graph_foreach_node',
'TAILQ_FOREACH', 'RTE_ETH_FOREACH_DEV']}",

Re: [dpdk-dev] [PATCH 20.08 0/9] adding support for python 3 only.

[Robin Jarry]

2020-05-25, Kilheeney, Louise:
> I tested all scripts by running each of them manually, if you have any
> input into what tests you thinks would be good to run please do let me
> know.

This should be enough to debunk the most obvious problems. Thanks.

-- 
Robin

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 10:34 AM, Morten Brørup wrote:

Dear DPDK Techboard,

I am writing this to raise awareness about the environment for contributing to 
DPDK, as I feel that it could be improved. This is not a personal thing - I 
have thick skin - but a general observation. I urge the DPDK Techboard to spend 
some time to focus on the process, and not only on the technology.

Contributing to DPDK is not easy for infrequent contributors:

1. Infrequent contributors are limited by not being deeply familiar with the 
coding style and the commit style, so their style is not always 100 % spot on.
2. Infrequent contributors are limited by not having built trust by the 
maintainers and frequent contributors, and thus their contributions undergo 
more detailed reviews and get more negative (or: perceived negative) feedback, 
where trusted contributors are given more slack. (In theory, every contribution 
should be treated equal, but in reality it makes sense allocating fewer 
resources to review contributions from developers with a proven track record.)
3. Infrequent contributors may not be deeply familiar with the development/contribution 
tools. E.g. how to use git the "DPDK way".

Additionally, when contributing to old DPDK code, checkpatch complains about 
coding style violations stemming from the existing old code. This also raises 
the barrier and decreases the motivation to contribute - a contributor getting 
negative feedback about something he didn't even do.


Here are a couple of anonymous examples from the mailing list:

An infrequent contributor got minor coding style suggestions to a patch, 
although the coding style was similar to that of a closely related function in 
the same library, but not perfectly matching the official coding style. I think 
we could be more lax about coding style, except if the coding style directly 
violates automatic coding style validation tools.



A lot of that could simply be fixed by codifying our Coding Style into a 
.clang-format file, and make this process (semi-)automatic. A lot of 
IDE's/editors now have either built-in support for clang-format, or have 
plugins enabling said support.


I've investigated this in the past and found that our coding style 
guidelines are very specific in some places, and neither clang-format 
nor other options have that kind of detailed control over source code 
formatting. The only other option would be to adjust our coding style to 
fit the options available in clang-format.


IMO this would cut down a lot on complaints about mixing indents, wrong 
alignment, (lack of) newlines before function name, etc.



Another infrequent contributor got patch style feedback about a small patch, 
suggesting to split it up into three patches. The official contributing guide 
says that small changes should be kept together in the same patch. The patch in 
question could be considered three bug fixes, so splitting it up might be 
appropriate, or it could be considered fixing three variations of the same bug, 
so keeping it together as one would be appropriate. I think we could be more 
lax about patch style, except if the patches are completely incomprehensible.


In my experience, this has been up to individual maintainers. I 
generally split up my patches not to follow a guideline, but to make 
reviewing code easier for others. Sometimes that means splitting up the 
patch, sometimes that means keeping everything together, and sometimes 
either one is OK so i don't insist on either.


But perhaps it would be a good idea to clarify some of these guidelines.

Then again, we should also remember that coding guidelines are there to 
help us all, and to avoid wasting maintainers' time: David/Thomas/Ferruh 
manually fixing every patch before applying just because we are "lax" in 
reviews doesn't really scale. So, it's really a double edged sword IMO.




It is not all bad, though! I have more than once seen excellent feedback to a 
suggested patch, where an expert reviewer took the time and effort to explain - 
in an educational and welcoming tone - what was wrong about the patch and the 
contributor's assumptions.


In summary, I think that DPDK has grown to a point where we hopefully will see 
more contributions from outsiders and newcomers, and we need to adapt to it, so 
that they get a positive experience from contributing, and keep coming back 
with more.

Improving the process should be an ongoing discussion. Here are two areas for 
discussion:

1. Keep expanding the contributor documentation. It is already far better than 
for most projects, but there is always room for improvement. Assume that the 
reader is intelligent, but has limited information in advance. E.g. Patchwork 
and Bugzilla are barely mentioned, and it is only described how to use them 
when submitting a patch.

2. When giving feedback on the mailing list, consider how it may be received, 
weighing the balance between accepting imperfection and educating the 
contributor.


I would 

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Jerin Jacob]

> I would add a third area: the process itself is arcane and inaccessible.
> The current consensus among the community seems to be that IRC + mailing
> list are "the most accessible" because "everyone has email" and "getting
> on IRC is easy".
>
> However, the truth is, they aren't "accessible", they are low tech, and
> thus *in*accessible to those who aren't veteran command-line Linux
> coders. No one uses IRC any more except OSS projects (so a new

I agree. Since IRC is not secure, a lot of companies are blocking the 6667 port.
Another alternative is to see _slack_ "free public" channels. Some of
the cool features of
new tools are really useful. like notification, search in chat
area(help to create the knowledge base),
mobile application support, tons of custom free apps for a specific
workflow, etc.

> contributor isn't likely to have an IRC set up unless they're already a
> habitual contributor to other projects), and sending patches over an
> email as opposed to a well-integrated web interface workflow is so alien
> to most people that it definitely does discourage new contributions.
>
> I understand the advantages of mailing lists (vendor independence,
> universal compatibility, etc.), but after doing reviews in Github/Gitlab
> for a while (we use those internally), going through DPDK mailing list
> and reviewing code over email fills me with existential dread, as the
> process feels so manual and 19th century to me.

Agree. I had a difference in opinion when I was not using those tools.
My perspective changed after using Github and Gerrit etc.

Github pull request and integrated public CI(Travis, Shippable ,
codecov) makes collaboration easy.
Currently, in patchwork, we can not assign a patch other than the set
of maintainers.
I think, it would help the review process if the more fine-grained
owner will be responsible for specific
patch set.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Bruce Richardson]

On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote:
> On 25-May-20 10:34 AM, Morten Brørup wrote:
> > Dear DPDK Techboard,
> > 
> > I am writing this to raise awareness about the environment for contributing 
> > to DPDK, as I feel that it could be improved. This is not a personal thing 
> > - I have thick skin - but a general observation. I urge the DPDK Techboard 
> > to spend some time to focus on the process, and not only on the technology.
> > 
> > Contributing to DPDK is not easy for infrequent contributors:
> > 
> > 1. Infrequent contributors are limited by not being deeply familiar with 
> > the coding style and the commit style, so their style is not always 100 % 
> > spot on.
> > 2. Infrequent contributors are limited by not having built trust by the 
> > maintainers and frequent contributors, and thus their contributions undergo 
> > more detailed reviews and get more negative (or: perceived negative) 
> > feedback, where trusted contributors are given more slack. (In theory, 
> > every contribution should be treated equal, but in reality it makes sense 
> > allocating fewer resources to review contributions from developers with a 
> > proven track record.)
> > 3. Infrequent contributors may not be deeply familiar with the 
> > development/contribution tools. E.g. how to use git the "DPDK way".
> > 
> > Additionally, when contributing to old DPDK code, checkpatch complains 
> > about coding style violations stemming from the existing old code. This 
> > also raises the barrier and decreases the motivation to contribute - a 
> > contributor getting negative feedback about something he didn't even do.
> > 
> > 
> > Here are a couple of anonymous examples from the mailing list:
> > 
> > An infrequent contributor got minor coding style suggestions to a patch, 
> > although the coding style was similar to that of a closely related function 
> > in the same library, but not perfectly matching the official coding style. 
> > I think we could be more lax about coding style, except if the coding style 
> > directly violates automatic coding style validation tools.
> > 
> 
> A lot of that could simply be fixed by codifying our Coding Style into a
> .clang-format file, and make this process (semi-)automatic. A lot of
> IDE's/editors now have either built-in support for clang-format, or have
> plugins enabling said support.
> 
> I've investigated this in the past and found that our coding style
> guidelines are very specific in some places, and neither clang-format nor
> other options have that kind of detailed control over source code
> formatting. The only other option would be to adjust our coding style to fit
> the options available in clang-format.
> 
> IMO this would cut down a lot on complaints about mixing indents, wrong
> alignment, (lack of) newlines before function name, etc.
> 

This is of definite interest to me, for one. How close to our current
standards can we get right now with clang-format? If the coding standards
right now can't match exactly, how big would be the changes to make them
doable in clang-format? Is it one or two things, or is it quite a number?

/Bruce

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Thomas Monjalon]

25/05/2020 13:58, Jerin Jacob:
> 25/05/2020 11:34, Morten Brørup:
> > sending patches over an
> > email as opposed to a well-integrated web interface workflow is so alien
> > to most people that it definitely does discourage new contributions.
> >
> > I understand the advantages of mailing lists (vendor independence,
> > universal compatibility, etc.), but after doing reviews in Github/Gitlab
> > for a while (we use those internally), going through DPDK mailing list
> > and reviewing code over email fills me with existential dread, as the
> > process feels so manual and 19th century to me.
> 
> Agree. I had a difference in opinion when I was not using those tools.
> My perspective changed after using Github and Gerrit etc.
> 
> Github pull request and integrated public CI(Travis, Shippable ,
> codecov) makes collaboration easy.
> Currently, in patchwork, we can not assign a patch other than the set
> of maintainers.
> I think, it would help the review process if the more fine-grained
> owner will be responsible for specific
> patch set.

The more fine-grain is achieved with Cc in mail.
But I understand not everybody knows/wants/can configure correctly
an email client. Emails are not easy for everybody, I agree.

I use GitHub as well, and I really prefer the clarity of the mail threads.
GitHub reviews tend to be line-focused, messy and not discussion-friendly.
I think contribution quality would be worst if using GitHub.

There is a mailing list discussing workflow tooling:
https://lore.kernel.org/workflows/

[dpdk-dev] DPDK 20.08 Mellanox Roadmap

[Gal Cohen (Product)]

Below is Mellanox's roadmap for DPDK20.08, which we are currently working on:

rte_flow API updates:
==

[1] Extending the DPDK flow action API to enable support of a shared 
rte_flow_action context:

A modification of a single rte_flow_action context replaces the current 
approach which requires multiple modifications of (identical) flow actions.

Motivation: When multiple flow rules such as RSS have the same action, this 
action is cloned and used on each of the flows. Prior to the proposed change, 
any update to the RSS action (e.g. adding/removing queue) required 
reconfiguration of all the flows. This re-configuration is non-efficient, and 
the newly proposed APIs provide means to influence all the relevant flows 
through a single change in the shared action context that is being used by all 
the relevant flows.

[2] Support flow-based traffic sampling or mirroring:

Packets of a given classification, can be cloned at a given sampling rate and 
forwarded to a vport or queue. When the sampling rate is set to 100% the 
traffic would be completely mirrored.
Once sampled or mirrored, a packet may be bound to an additional action such as 
mark, encap, decap.
Motivation: Enable monitoring and statistics on classified traffic for business 
or lawful interception.
Example: Monitoring of hairpined traffic;
[3] Add support for eCPRI header classification.

Motivation: Allow 5G RAN (Radio Access Network) applications to use DPDK for 
matching and steering traffic based on the eCPRI message header.



Introduce new rte_regex API:


[4] Introduce new API in DPDK to allow injection of regex parsing rules.

Motivation: Provide flexible parsing functionality with limited code changes.

(See DPDK RFC: regexdev: introduce regexdev subsytem)

mlx5 PMD updates:

[*] mlx5 PMD will support the rte_flow update changes listed above.



Performance improvement

[5] Add mlx5 PMD use of vectorized instructions when using Striding RQ (MPRQ)



Memory management:

[6] Add mlx5 PMD configuration option (dev-args), allowing control of the cache 
memory reclaim mode ("reclaim_mem_mode").

Motivation: Allow flexible application decision on how to treat aged cache 
memory entries. Options are - [1] cache regularly, [2] reclaim the PMD 
resource, or [3] reclaim both PMD and rdma_core resources.

[7] Add mlx5 PMD configuration option (dev-args), allowing to define the 
flow-related memory allocation source, either from system (new) or from the 
hugepage (legacy).



Efficient flow management in process restart:

[8] Add mlx5 PMD support for queue stop/start APIs.

Motivation: Enable support for various process availability scenarios in which 
a process that is using a queue need to be switched with another process (for 
example due to process failure/crash or to allow graceful shutdown).
Implemented functions are: 
rte_eth_dev_tx_queue_stop(),rte_eth_dev_tx_queue_start().



Added support for 5g use cases:

[*] matching on eCPRI header as mentioned in [3]

[9] Add mlx5 PMD support for accurate traffic scheduling.

   Motivation: Allow sending Tx traffic on a predefined timeslot to smooth 
traffic capacity on end-points that cannot sustain bursts.


Other functionalities:

[10] Add mlx5 PMD support for LACP steering to kernel.

Enable steering of Link Aggregation Control Protocol (LACP) traffic to kernel 
instead of to DPDK, even for cases in which the DPDK application selected to 
get all the traffic, such as in promiscuous mode.
Motivation: Allow working in promiscuous mode while using kernel bonding;



testpmd updates:
===

[*] testpmd will be updated to support the features that described above (eCPRI 
header classification; flow-based traffic sample or mirroring; adding, changing 
and using rte_flow_action context).



[11] Add support for IP and Port swapping.

Extending the existing 'macswap' to allow complete 5 tuple update in forwarding 
action.
Motivation: Improve flexibility in test and application scenarios in forwarding 
action with updates of 5 tuple.

Best regards,
Gal Cohen

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 1:53 PM, Thomas Monjalon wrote:

25/05/2020 13:58, Jerin Jacob:

25/05/2020 11:34, Morten Brørup:

sending patches over an
email as opposed to a well-integrated web interface workflow is so alien
to most people that it definitely does discourage new contributions.

I understand the advantages of mailing lists (vendor independence,
universal compatibility, etc.), but after doing reviews in Github/Gitlab
for a while (we use those internally), going through DPDK mailing list
and reviewing code over email fills me with existential dread, as the
process feels so manual and 19th century to me.


Agree. I had a difference in opinion when I was not using those tools.
My perspective changed after using Github and Gerrit etc.

Github pull request and integrated public CI(Travis, Shippable ,
codecov) makes collaboration easy.
Currently, in patchwork, we can not assign a patch other than the set
of maintainers.
I think, it would help the review process if the more fine-grained
owner will be responsible for specific
patch set.


The more fine-grain is achieved with Cc in mail.
But I understand not everybody knows/wants/can configure correctly
an email client. Emails are not easy for everybody, I agree.

I use GitHub as well, and I really prefer the clarity of the mail threads.
GitHub reviews tend to be line-focused, messy and not discussion-friendly.
I think contribution quality would be worst if using GitHub.


I have more experience with Gitlab than Github, but i really don't see 
it that way.


For one, reviewing in Gitlab makes it easier to see context in which 
changes appear. I mean, obviously, you can download the patch, apply it, 
and then do whatever you want with it in your editor/IDE, but it's just 
so much faster to do it right in the browser. Reviewing things with 
proper syntax highlighting and side-by-side diff with an option to see 
more context really makes a huge difference and is that much faster.


I would also vehemently disagree with the "clarity" argument. There is 
enforced minimum standard of clarity of discussion in a tool such as 
Gitlab. I'm sure you noticed that some people top-post, some 
bottom-post. Some will remove extraneous lines of patches while some 
will leave on comment in a 10K line patch and leave the rest as is, in 
quotes. Some people do weird quoting where they don't actually quote but 
just copy text verbatim, making it hard to determine where the quote 
starts. If the thread is long enough, you'd see the same text quoted 
over and over and over. All of that is not a problem within a single 
patch email, but it adds up to lots of wasted time on all sides.


And all of the above will not be a problem with a tool like 
Gitlab/Github. There are "general" comments that can be used for general 
discussion, and there are line-specific comments that can be used to 
discuss certain sections of the patch. I've done this many times in many 
reviews, and it works very well. Now, granted, I've never maintained an 
entire repository like DPDK, so you may have a different perspective, 
but i really don't see how long email chains have "clarity" that a 
discussion thread with proper quoting, links to code, markdown syntax, 
etc. doesn't.


(for the record, i don't consider Gerrit to be a good tool because it 
enforces a particular git workflow, one that is not at all compatible 
with how our community works. GitLab, on the other hand, "just works" - 
i'm assuming GitHub is very similar)




There is a mailing list discussing workflow tooling:
https://lore.kernel.org/workflows/





--
Thanks,
Anatoly

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Wiles, Keith]

> On May 25, 2020, at 7:53 AM, Thomas Monjalon  wrote:
> 
> 25/05/2020 13:58, Jerin Jacob:
>> 25/05/2020 11:34, Morten Brørup:
>>> sending patches over an
>>> email as opposed to a well-integrated web interface workflow is so alien
>>> to most people that it definitely does discourage new contributions.
>>> 
>>> I understand the advantages of mailing lists (vendor independence,
>>> universal compatibility, etc.), but after doing reviews in Github/Gitlab
>>> for a while (we use those internally), going through DPDK mailing list
>>> and reviewing code over email fills me with existential dread, as the
>>> process feels so manual and 19th century to me.
>> 
>> Agree. I had a difference in opinion when I was not using those tools.
>> My perspective changed after using Github and Gerrit etc.
>> 
>> Github pull request and integrated public CI(Travis, Shippable ,
>> codecov) makes collaboration easy.
>> Currently, in patchwork, we can not assign a patch other than the set
>> of maintainers.
>> I think, it would help the review process if the more fine-grained
>> owner will be responsible for specific
>> patch set.
> 
> The more fine-grain is achieved with Cc in mail.
> But I understand not everybody knows/wants/can configure correctly
> an email client. Emails are not easy for everybody, I agree.
> 
> I use GitHub as well, and I really prefer the clarity of the mail threads.
> GitHub reviews tend to be line-focused, messy and not discussion-friendly.
> I think contribution quality would be worst if using GitHub.
> 
> There is a mailing list discussing workflow tooling:
>   https://lore.kernel.org/workflows/

I disagree about GitHub/GitLab clarity the comments on the patch are inline 
with the code and these tools provide tracking of these comments. I believed 
GitHub/GitLab would help others contribute to DPDK easier and faster. With 
GitHub or GitLab it is a learning curve, but we do not need to have extra tools 
like patchwork it is already integrated into these tools. Submitting a patch 
should be simple and not require using N number of tools to submit a patch or 
manage a patch.

Being able to view the patches inline with code makes reviewing much easier and 
then being able to rebase the MR with a fixed approval method is great. These 
tools like any tools has it’s limits, but I think the advantage of these tools 
out weights some of the comments I have seen for using them.

Beginning able to track pretty much everything in one tool is great as it 
provides a much easier way to review patches and it focuses on the patch not 
looking up email messages to make a comment. We only need to comment via the 
tool at the exact location in the code. These tools also help track these 
comments and not have to figure out which of the N number of emails I need to 
respond too. Using the processes of the Linux kernel development is not the 
most user friendly method of development for developers IMHO.

Adding clang-format to commit-hook is a great way to keep the coding style 
going. It does not cover every case in DPDK, but they are minor IMHO. This 
means we can convert to one of these pre-canned formats and then adjust DPDK 
coding style.

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Wiles, Keith]

> On May 25, 2020, at 9:28 AM, Burakov, Anatoly  
> wrote:
> 
> On 25-May-20 1:53 PM, Thomas Monjalon wrote:
>> 25/05/2020 13:58, Jerin Jacob:
>>> 25/05/2020 11:34, Morten Brørup:
 sending patches over an
 email as opposed to a well-integrated web interface workflow is so alien
 to most people that it definitely does discourage new contributions.
 
 I understand the advantages of mailing lists (vendor independence,
 universal compatibility, etc.), but after doing reviews in Github/Gitlab
 for a while (we use those internally), going through DPDK mailing list
 and reviewing code over email fills me with existential dread, as the
 process feels so manual and 19th century to me.
>>> 
>>> Agree. I had a difference in opinion when I was not using those tools.
>>> My perspective changed after using Github and Gerrit etc.
>>> 
>>> Github pull request and integrated public CI(Travis, Shippable ,
>>> codecov) makes collaboration easy.
>>> Currently, in patchwork, we can not assign a patch other than the set
>>> of maintainers.
>>> I think, it would help the review process if the more fine-grained
>>> owner will be responsible for specific
>>> patch set.
>> The more fine-grain is achieved with Cc in mail.
>> But I understand not everybody knows/wants/can configure correctly
>> an email client. Emails are not easy for everybody, I agree.
>> I use GitHub as well, and I really prefer the clarity of the mail threads.
>> GitHub reviews tend to be line-focused, messy and not discussion-friendly.
>> I think contribution quality would be worst if using GitHub.
> 
> I have more experience with Gitlab than Github, but i really don't see it 
> that way.
> 
> For one, reviewing in Gitlab makes it easier to see context in which changes 
> appear. I mean, obviously, you can download the patch, apply it, and then do 
> whatever you want with it in your editor/IDE, but it's just so much faster to 
> do it right in the browser. Reviewing things with proper syntax highlighting 
> and side-by-side diff with an option to see more context really makes a huge 
> difference and is that much faster.
> 
> I would also vehemently disagree with the "clarity" argument. There is 
> enforced minimum standard of clarity of discussion in a tool such as Gitlab. 
> I'm sure you noticed that some people top-post, some bottom-post. Some will 
> remove extraneous lines of patches while some will leave on comment in a 10K 
> line patch and leave the rest as is, in quotes. Some people do weird quoting 
> where they don't actually quote but just copy text verbatim, making it hard 
> to determine where the quote starts. If the thread is long enough, you'd see 
> the same text quoted over and over and over. All of that is not a problem 
> within a single patch email, but it adds up to lots of wasted time on all 
> sides.
> 
> And all of the above will not be a problem with a tool like Gitlab/Github. 
> There are "general" comments that can be used for general discussion, and 
> there are line-specific comments that can be used to discuss certain sections 
> of the patch. I've done this many times in many reviews, and it works very 
> well. Now, granted, I've never maintained an entire repository like DPDK, so 
> you may have a different perspective, but i really don't see how long email 
> chains have "clarity" that a discussion thread with proper quoting, links to 
> code, markdown syntax, etc. doesn't.
> 
> (for the record, i don't consider Gerrit to be a good tool because it 
> enforces a particular git workflow, one that is not at all compatible with 
> how our community works. GitLab, on the other hand, "just works" - i'm 
> assuming GitHub is very similar)
> 
>> There is a mailing list discussing workflow tooling:
>>  https://lore.kernel.org/workflows/
> 

Bummer, I did not have to write my email, so +1000 to this one.
> 
> -- 
> Thanks,
> Anatoly

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 1:08 PM, Bruce Richardson wrote:

On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote:

On 25-May-20 10:34 AM, Morten Brørup wrote:

Dear DPDK Techboard,

I am writing this to raise awareness about the environment for contributing to 
DPDK, as I feel that it could be improved. This is not a personal thing - I 
have thick skin - but a general observation. I urge the DPDK Techboard to spend 
some time to focus on the process, and not only on the technology.

Contributing to DPDK is not easy for infrequent contributors:

1. Infrequent contributors are limited by not being deeply familiar with the 
coding style and the commit style, so their style is not always 100 % spot on.
2. Infrequent contributors are limited by not having built trust by the 
maintainers and frequent contributors, and thus their contributions undergo 
more detailed reviews and get more negative (or: perceived negative) feedback, 
where trusted contributors are given more slack. (In theory, every contribution 
should be treated equal, but in reality it makes sense allocating fewer 
resources to review contributions from developers with a proven track record.)
3. Infrequent contributors may not be deeply familiar with the development/contribution 
tools. E.g. how to use git the "DPDK way".

Additionally, when contributing to old DPDK code, checkpatch complains about 
coding style violations stemming from the existing old code. This also raises 
the barrier and decreases the motivation to contribute - a contributor getting 
negative feedback about something he didn't even do.


Here are a couple of anonymous examples from the mailing list:

An infrequent contributor got minor coding style suggestions to a patch, 
although the coding style was similar to that of a closely related function in 
the same library, but not perfectly matching the official coding style. I think 
we could be more lax about coding style, except if the coding style directly 
violates automatic coding style validation tools.



A lot of that could simply be fixed by codifying our Coding Style into a
.clang-format file, and make this process (semi-)automatic. A lot of
IDE's/editors now have either built-in support for clang-format, or have
plugins enabling said support.

I've investigated this in the past and found that our coding style
guidelines are very specific in some places, and neither clang-format nor
other options have that kind of detailed control over source code
formatting. The only other option would be to adjust our coding style to fit
the options available in clang-format.

IMO this would cut down a lot on complaints about mixing indents, wrong
alignment, (lack of) newlines before function name, etc.



This is of definite interest to me, for one. How close to our current
standards can we get right now with clang-format? If the coding standards
right now can't match exactly, how big would be the changes to make them
doable in clang-format? Is it one or two things, or is it quite a number?

/Bruce



The issues weren't that serious - mainly the peculiarities around our 
custom macros like __rte_experimental or our specific flavor of 
indentation. I can't remember off the top of my head exactly what was 
the problem as i've looked at this a couple of years ago, but i'm pretty 
sure the majority of the stuff we expect in DPDK is configurable through 
clang-format. Plus, i'm sure clang-format has gained features in the 
meantime, maybe the things that weren't possible then, are now :)


--
Thanks,
Anatoly

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Thomas Monjalon]

25/05/2020 16:28, Burakov, Anatoly:
> On 25-May-20 1:53 PM, Thomas Monjalon wrote:
> > 25/05/2020 13:58, Jerin Jacob:
> >> 25/05/2020 11:34, Morten Brørup:
> >>> sending patches over an
> >>> email as opposed to a well-integrated web interface workflow is so alien
> >>> to most people that it definitely does discourage new contributions.
> >>>
> >>> I understand the advantages of mailing lists (vendor independence,
> >>> universal compatibility, etc.), but after doing reviews in Github/Gitlab
> >>> for a while (we use those internally), going through DPDK mailing list
> >>> and reviewing code over email fills me with existential dread, as the
> >>> process feels so manual and 19th century to me.
> >>
> >> Agree. I had a difference in opinion when I was not using those tools.
> >> My perspective changed after using Github and Gerrit etc.
> >>
> >> Github pull request and integrated public CI(Travis, Shippable ,
> >> codecov) makes collaboration easy.
> >> Currently, in patchwork, we can not assign a patch other than the set
> >> of maintainers.
> >> I think, it would help the review process if the more fine-grained
> >> owner will be responsible for specific
> >> patch set.
> > 
> > The more fine-grain is achieved with Cc in mail.
> > But I understand not everybody knows/wants/can configure correctly
> > an email client. Emails are not easy for everybody, I agree.
> > 
> > I use GitHub as well, and I really prefer the clarity of the mail threads.
> > GitHub reviews tend to be line-focused, messy and not discussion-friendly.
> > I think contribution quality would be worst if using GitHub.
> 
> I have more experience with Gitlab than Github, but i really don't see 
> it that way.
> 
> For one, reviewing in Gitlab makes it easier to see context in which 
> changes appear. I mean, obviously, you can download the patch, apply it, 
> and then do whatever you want with it in your editor/IDE, but it's just 
> so much faster to do it right in the browser. Reviewing things with 
> proper syntax highlighting and side-by-side diff with an option to see 
> more context really makes a huge difference and is that much faster.

OK


> I would also vehemently disagree with the "clarity" argument. There is 
> enforced minimum standard of clarity of discussion in a tool such as 
> Gitlab. I'm sure you noticed that some people top-post, some 
> bottom-post. Some will remove extraneous lines of patches while some 
> will leave on comment in a 10K line patch and leave the rest as is, in 
> quotes. Some people do weird quoting where they don't actually quote but 
> just copy text verbatim, making it hard to determine where the quote 
> starts. If the thread is long enough, you'd see the same text quoted 
> over and over and over. All of that is not a problem within a single 
> patch email, but it adds up to lots of wasted time on all sides.

Yes

My concern about clarity is the history of the discussion.
When we post a new versions in GitHub, it's very hard to keep track
of the history.
As a maintainer, I need to see the history to understand what happened,
what we are waiting for, and what should be merged.


> And all of the above will not be a problem with a tool like 
> Gitlab/Github. There are "general" comments that can be used for general 
> discussion, and there are line-specific comments that can be used to 
> discuss certain sections of the patch. I've done this many times in many 
> reviews, and it works very well. Now, granted, I've never maintained an 
> entire repository like DPDK, so you may have a different perspective, 
> but i really don't see how long email chains have "clarity" that a 
> discussion thread with proper quoting, links to code, markdown syntax, 
> etc. doesn't.

You don't have discussion threading in GitHub. Is there?


> (for the record, i don't consider Gerrit to be a good tool because it 
> enforces a particular git workflow, one that is not at all compatible 
> with how our community works. GitLab, on the other hand, "just works" - 
> i'm assuming GitHub is very similar)
> 
> > 
> > There is a mailing list discussing workflow tooling:
> > https://lore.kernel.org/workflows/

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Jerin Jacob]

On Mon, May 25, 2020 at 8:34 PM Burakov, Anatoly
 wrote:
>
> On 25-May-20 1:08 PM, Bruce Richardson wrote:
> > On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote:
> >> On 25-May-20 10:34 AM, Morten Brørup wrote:
> >>> Dear DPDK Techboard,
> >>>
> >>> I am writing this to raise awareness about the environment for 
> >>> contributing to DPDK, as I feel that it could be improved. This is not a 
> >>> personal thing - I have thick skin - but a general observation. I urge 
> >>> the DPDK Techboard to spend some time to focus on the process, and not 
> >>> only on the technology.
> >>>
> >>> Contributing to DPDK is not easy for infrequent contributors:
> >>>
> >>> 1. Infrequent contributors are limited by not being deeply familiar with 
> >>> the coding style and the commit style, so their style is not always 100 % 
> >>> spot on.
> >>> 2. Infrequent contributors are limited by not having built trust by the 
> >>> maintainers and frequent contributors, and thus their contributions 
> >>> undergo more detailed reviews and get more negative (or: perceived 
> >>> negative) feedback, where trusted contributors are given more slack. (In 
> >>> theory, every contribution should be treated equal, but in reality it 
> >>> makes sense allocating fewer resources to review contributions from 
> >>> developers with a proven track record.)
> >>> 3. Infrequent contributors may not be deeply familiar with the 
> >>> development/contribution tools. E.g. how to use git the "DPDK way".
> >>>
> >>> Additionally, when contributing to old DPDK code, checkpatch complains 
> >>> about coding style violations stemming from the existing old code. This 
> >>> also raises the barrier and decreases the motivation to contribute - a 
> >>> contributor getting negative feedback about something he didn't even do.
> >>>
> >>>
> >>> Here are a couple of anonymous examples from the mailing list:
> >>>
> >>> An infrequent contributor got minor coding style suggestions to a patch, 
> >>> although the coding style was similar to that of a closely related 
> >>> function in the same library, but not perfectly matching the official 
> >>> coding style. I think we could be more lax about coding style, except if 
> >>> the coding style directly violates automatic coding style validation 
> >>> tools.
> >>>
> >>
> >> A lot of that could simply be fixed by codifying our Coding Style into a
> >> .clang-format file, and make this process (semi-)automatic. A lot of
> >> IDE's/editors now have either built-in support for clang-format, or have
> >> plugins enabling said support.
> >>
> >> I've investigated this in the past and found that our coding style
> >> guidelines are very specific in some places, and neither clang-format nor
> >> other options have that kind of detailed control over source code
> >> formatting. The only other option would be to adjust our coding style to 
> >> fit
> >> the options available in clang-format.
> >>
> >> IMO this would cut down a lot on complaints about mixing indents, wrong
> >> alignment, (lack of) newlines before function name, etc.
> >>
> >
> > This is of definite interest to me, for one. How close to our current
> > standards can we get right now with clang-format? If the coding standards
> > right now can't match exactly, how big would be the changes to make them
> > doable in clang-format? Is it one or two things, or is it quite a number?
> >
> > /Bruce
> >
>
> The issues weren't that serious - mainly the peculiarities around our
> custom macros like __rte_experimental or our specific flavor of
> indentation. I can't remember off the top of my head exactly what was
> the problem as i've looked at this a couple of years ago, but i'm pretty
> sure the majority of the stuff we expect in DPDK is configurable through
> clang-format. Plus, i'm sure clang-format has gained features in the
> meantime, maybe the things that weren't possible then, are now :)

I have been using the following clang-format configuration for DPDK[1].
I dont see any setbacks. ForEachMacros section below needs to extend for DPDK.

[1]
"{ BasedOnStyle: LLVM, IndentWidth: 8, TabWidth: 8, UseTab: Always,
AllowShortIfStatementsOnASingleLine: false, IndentCaseLabels: false,
ColumnLimit: 80, AllowShortFunctionsOnASingleLine: false,
AlwaysBreakAfterReturnType: AllDefinitions, ColumnLimit: 80,
ConstructorInitializerAllOnOneLineOrOnePerLine: true,
ConstructorInitializerIndentWidth: 8, ContinuationIndentWidth: 8,
BreakBeforeBraces: Linux, AllowShortBlocksOnASingleLine: false,
AlignConsecutiveAssignments: false, AlignEscapedNewlines: Right,
AlignConsecutiveMacros : true, MaxEmptyLinesToKeep : 1,
Cpp11BracedListStyle : true, AlignTrailingComments : true,
ForEachMacros: ['STAILQ_FOREACH', 'rte_graph_foreach_node',
'TAILQ_FOREACH', 'RTE_ETH_FOREACH_DEV']}",



>
> --
> Thanks,
> Anatoly

[dpdk-dev] [PATCH v2] doc: update for ice

[Xiaolong Ye]

Update the description and limitation about ice PMD according to the
product release strategy.

Signed-off-by: Xiaolong Ye 
Acked-by: Qiming Yang 
---
 doc/guides/nics/ice.rst | 29 +
 1 file changed, 5 insertions(+), 24 deletions(-)

diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index c5278fc757..9a9f4a6bb0 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -12,33 +12,14 @@ the Intel Ethernet Controller E810.
 Prerequisites
 -
 
-- Identifying your adapter using `Intel Support
-  `_ and get the latest NVM/FW images.
+- The E810 is currently in sampling state only. To obtain early samples and/or 
get further information
+  about kernel drivers, firmware and DDP support, please speak to your Intel 
representative.
 
 - Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
 
 - To get better performance on Intel platforms, please follow the "How to get 
best performance with NICs on Intel platforms"
   section of the :ref:`Getting Started Guide for Linux `.
 
-Recommended Matching List
--
-
-It is highly recommended to upgrade the ice kernel driver and firmware and
-DDP packages to avoid the compatibility issues with ice PMD. Here is the
-suggested matching list.
-
-   
+--+---+--++---+
-   | DPDK version | Kernel driver version | Firmware version | DDP OS 
Package | DDP COMMS Package |
-   
+==+===+==++===+
-   |20.02 |0.12.25| 1.1.16.39|  
1.3.4 |   1.3.10  |
-   
+--+---+--++---+
-   |19.11 |0.12.25| 1.1.16.39|  
1.3.4 |   1.3.10  |
-   
+--+---+--++---+
-   | 19.08 (experimental) |0.10.1 | 1.1.12.7 |  
1.2.0 |N/A|
-   
+--+---+--++---+
-   | 19.05 (experimental) |0.9.4  | 1.1.10.16|  
1.1.0 |N/A|
-   
+--+---+--++---+
-
 Pre-Installation Configuration
 --
 
@@ -330,7 +311,7 @@ is stored in ``ice_adapter->active_pkg_type``.
 A symbolic link to the DDP package file is also ok. The same package
 file is used by both the kernel driver and the DPDK PMD.
 
-19.02 limitation
-
+limitation
+~~
 
-Ice code released in 19.02 is for evaluation only.
+Ice code released is for evaluation only currently.
-- 
2.17.1

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Jerin Jacob]

On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon  wrote:
>
> 25/05/2020 16:28, Burakov, Anatoly:
> > On 25-May-20 1:53 PM, Thomas Monjalon wrote:
> > > 25/05/2020 13:58, Jerin Jacob:
> > >> 25/05/2020 11:34, Morten Brørup:
> > >>> sending patches over an
> > >>> email as opposed to a well-integrated web interface workflow is so alien
> > >>> to most people that it definitely does discourage new contributions.
> > >>>
> > >>> I understand the advantages of mailing lists (vendor independence,
> > >>> universal compatibility, etc.), but after doing reviews in Github/Gitlab
> > >>> for a while (we use those internally), going through DPDK mailing list
> > >>> and reviewing code over email fills me with existential dread, as the
> > >>> process feels so manual and 19th century to me.
> > >>
> > >> Agree. I had a difference in opinion when I was not using those tools.
> > >> My perspective changed after using Github and Gerrit etc.
> > >>
> > >> Github pull request and integrated public CI(Travis, Shippable ,
> > >> codecov) makes collaboration easy.
> > >> Currently, in patchwork, we can not assign a patch other than the set
> > >> of maintainers.
> > >> I think, it would help the review process if the more fine-grained
> > >> owner will be responsible for specific
> > >> patch set.
> > >
> > > The more fine-grain is achieved with Cc in mail.
> > > But I understand not everybody knows/wants/can configure correctly
> > > an email client. Emails are not easy for everybody, I agree.
> > >
> > > I use GitHub as well, and I really prefer the clarity of the mail threads.
> > > GitHub reviews tend to be line-focused, messy and not discussion-friendly.
> > > I think contribution quality would be worst if using GitHub.
> >
> > I have more experience with Gitlab than Github, but i really don't see
> > it that way.
> >
> > For one, reviewing in Gitlab makes it easier to see context in which
> > changes appear. I mean, obviously, you can download the patch, apply it,
> > and then do whatever you want with it in your editor/IDE, but it's just
> > so much faster to do it right in the browser. Reviewing things with
> > proper syntax highlighting and side-by-side diff with an option to see
> > more context really makes a huge difference and is that much faster.
>
> OK
>
>
> > I would also vehemently disagree with the "clarity" argument. There is
> > enforced minimum standard of clarity of discussion in a tool such as
> > Gitlab. I'm sure you noticed that some people top-post, some
> > bottom-post. Some will remove extraneous lines of patches while some
> > will leave on comment in a 10K line patch and leave the rest as is, in
> > quotes. Some people do weird quoting where they don't actually quote but
> > just copy text verbatim, making it hard to determine where the quote
> > starts. If the thread is long enough, you'd see the same text quoted
> > over and over and over. All of that is not a problem within a single
> > patch email, but it adds up to lots of wasted time on all sides.
>
> Yes
>
> My concern about clarity is the history of the discussion.
> When we post a new versions in GitHub, it's very hard to keep track
> of the history.
> As a maintainer, I need to see the history to understand what happened,
> what we are waiting for, and what should be merged.

IMO, The complete history is available per pull request URL.
I think, Github also email notification mechanism those to prefer to see
comments in the email too.

In addition to that, Bugzilla, patchwork, CI stuff all integrated into
one place.
I am quite impressed with vscode community collaboration.
https://github.com/Microsoft/vscode/pulls


>
>
> > And all of the above will not be a problem with a tool like
> > Gitlab/Github. There are "general" comments that can be used for general
> > discussion, and there are line-specific comments that can be used to
> > discuss certain sections of the patch. I've done this many times in many
> > reviews, and it works very well. Now, granted, I've never maintained an
> > entire repository like DPDK, so you may have a different perspective,
> > but i really don't see how long email chains have "clarity" that a
> > discussion thread with proper quoting, links to code, markdown syntax,
> > etc. doesn't.
>
> You don't have discussion threading in GitHub. Is there?
>
>
> > (for the record, i don't consider Gerrit to be a good tool because it
> > enforces a particular git workflow, one that is not at all compatible
> > with how our community works. GitLab, on the other hand, "just works" -
> > i'm assuming GitHub is very similar)
> >
> > >
> > > There is a mailing list discussing workflow tooling:
> > > https://lore.kernel.org/workflows/
>
>
>

Re: [dpdk-dev] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 4:22 PM, Thomas Monjalon wrote:

25/05/2020 16:28, Burakov, Anatoly:

On 25-May-20 1:53 PM, Thomas Monjalon wrote:

25/05/2020 13:58, Jerin Jacob:

25/05/2020 11:34, Morten Brørup:

sending patches over an
email as opposed to a well-integrated web interface workflow is so alien
to most people that it definitely does discourage new contributions.

I understand the advantages of mailing lists (vendor independence,
universal compatibility, etc.), but after doing reviews in Github/Gitlab
for a while (we use those internally), going through DPDK mailing list
and reviewing code over email fills me with existential dread, as the
process feels so manual and 19th century to me.


Agree. I had a difference in opinion when I was not using those tools.
My perspective changed after using Github and Gerrit etc.

Github pull request and integrated public CI(Travis, Shippable ,
codecov) makes collaboration easy.
Currently, in patchwork, we can not assign a patch other than the set
of maintainers.
I think, it would help the review process if the more fine-grained
owner will be responsible for specific
patch set.


The more fine-grain is achieved with Cc in mail.
But I understand not everybody knows/wants/can configure correctly
an email client. Emails are not easy for everybody, I agree.

I use GitHub as well, and I really prefer the clarity of the mail threads.
GitHub reviews tend to be line-focused, messy and not discussion-friendly.
I think contribution quality would be worst if using GitHub.


I have more experience with Gitlab than Github, but i really don't see
it that way.

For one, reviewing in Gitlab makes it easier to see context in which
changes appear. I mean, obviously, you can download the patch, apply it,
and then do whatever you want with it in your editor/IDE, but it's just
so much faster to do it right in the browser. Reviewing things with
proper syntax highlighting and side-by-side diff with an option to see
more context really makes a huge difference and is that much faster.


OK



I would also vehemently disagree with the "clarity" argument. There is
enforced minimum standard of clarity of discussion in a tool such as
Gitlab. I'm sure you noticed that some people top-post, some
bottom-post. Some will remove extraneous lines of patches while some
will leave on comment in a 10K line patch and leave the rest as is, in
quotes. Some people do weird quoting where they don't actually quote but
just copy text verbatim, making it hard to determine where the quote
starts. If the thread is long enough, you'd see the same text quoted
over and over and over. All of that is not a problem within a single
patch email, but it adds up to lots of wasted time on all sides.


Yes

My concern about clarity is the history of the discussion.
When we post a new versions in GitHub, it's very hard to keep track
of the history.
As a maintainer, I need to see the history to understand what happened,
what we are waiting for, and what should be merged.


And AFAIK you do have access to discussion for older versions of the PR, 
do you not? Again, i didn't do in-depth reviews with multiple revisions 
and threads on Github, but assuming Gitlab works similarly, we do have 
access to that.






And all of the above will not be a problem with a tool like
Gitlab/Github. There are "general" comments that can be used for general
discussion, and there are line-specific comments that can be used to
discuss certain sections of the patch. I've done this many times in many
reviews, and it works very well. Now, granted, I've never maintained an
entire repository like DPDK, so you may have a different perspective,
but i really don't see how long email chains have "clarity" that a
discussion thread with proper quoting, links to code, markdown syntax,
etc. doesn't.


You don't have discussion threading in GitHub. Is there?


Threading is implicit when you are commenting under a line of code. Of 
course this rests on an assumption that you wouldn't use a random 
comment thread to bring up things from another thread, but nothing is 
perfect :)






(for the record, i don't consider Gerrit to be a good tool because it
enforces a particular git workflow, one that is not at all compatible
with how our community works. GitLab, on the other hand, "just works" -
i'm assuming GitHub is very similar)



There is a mailing list discussing workflow tooling:
https://lore.kernel.org/workflows/







--
Thanks,
Anatoly

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Stephen Hemminger]

On Mon, 25 May 2020 13:08:19 +0100
Bruce Richardson  wrote:

> On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote:
> > On 25-May-20 10:34 AM, Morten Brørup wrote:  
> > > Dear DPDK Techboard,
> > > 
> > > I am writing this to raise awareness about the environment for 
> > > contributing to DPDK, as I feel that it could be improved. This is not a 
> > > personal thing - I have thick skin - but a general observation. I urge 
> > > the DPDK Techboard to spend some time to focus on the process, and not 
> > > only on the technology.
> > > 
> > > Contributing to DPDK is not easy for infrequent contributors:
> > > 
> > > 1. Infrequent contributors are limited by not being deeply familiar with 
> > > the coding style and the commit style, so their style is not always 100 % 
> > > spot on.
> > > 2. Infrequent contributors are limited by not having built trust by the 
> > > maintainers and frequent contributors, and thus their contributions 
> > > undergo more detailed reviews and get more negative (or: perceived 
> > > negative) feedback, where trusted contributors are given more slack. (In 
> > > theory, every contribution should be treated equal, but in reality it 
> > > makes sense allocating fewer resources to review contributions from 
> > > developers with a proven track record.)
> > > 3. Infrequent contributors may not be deeply familiar with the 
> > > development/contribution tools. E.g. how to use git the "DPDK way".
> > > 
> > > Additionally, when contributing to old DPDK code, checkpatch complains 
> > > about coding style violations stemming from the existing old code. This 
> > > also raises the barrier and decreases the motivation to contribute - a 
> > > contributor getting negative feedback about something he didn't even do.
> > > 
> > > 
> > > Here are a couple of anonymous examples from the mailing list:
> > > 
> > > An infrequent contributor got minor coding style suggestions to a patch, 
> > > although the coding style was similar to that of a closely related 
> > > function in the same library, but not perfectly matching the official 
> > > coding style. I think we could be more lax about coding style, except if 
> > > the coding style directly violates automatic coding style validation 
> > > tools.
> > >   
> > 
> > A lot of that could simply be fixed by codifying our Coding Style into a
> > .clang-format file, and make this process (semi-)automatic. A lot of
> > IDE's/editors now have either built-in support for clang-format, or have
> > plugins enabling said support.
> > 
> > I've investigated this in the past and found that our coding style
> > guidelines are very specific in some places, and neither clang-format nor
> > other options have that kind of detailed control over source code
> > formatting. The only other option would be to adjust our coding style to fit
> > the options available in clang-format.
> > 
> > IMO this would cut down a lot on complaints about mixing indents, wrong
> > alignment, (lack of) newlines before function name, etc.
> >   
> 
> This is of definite interest to me, for one. How close to our current
> standards can we get right now with clang-format? If the coding standards
> right now can't match exactly, how big would be the changes to make them
> doable in clang-format? Is it one or two things, or is it quite a number?
> 
> /Bruce

Or just adjust the coding style to match a clang format.
For a positive example of a project that does this see VPP. They have:
make checkstyle
and make fixstyle

And their CI bot checks it.

Re: [dpdk-dev] [PATCH v2] doc: update for ice

[Ferruh Yigit]

On 5/25/2020 4:22 PM, Xiaolong Ye wrote:
> Update the description and limitation about ice PMD according to the
> product release strategy.
> 
> Signed-off-by: Xiaolong Ye 
> Acked-by: Qiming Yang 

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Maxime Coquelin]

On 5/25/20 5:35 PM, Jerin Jacob wrote:
> On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon  wrote:
>>
>> 25/05/2020 16:28, Burakov, Anatoly:
>>> On 25-May-20 1:53 PM, Thomas Monjalon wrote:
 25/05/2020 13:58, Jerin Jacob:
> 25/05/2020 11:34, Morten Brørup:
>> sending patches over an
>> email as opposed to a well-integrated web interface workflow is so alien
>> to most people that it definitely does discourage new contributions.
>>
>> I understand the advantages of mailing lists (vendor independence,
>> universal compatibility, etc.), but after doing reviews in Github/Gitlab
>> for a while (we use those internally), going through DPDK mailing list
>> and reviewing code over email fills me with existential dread, as the
>> process feels so manual and 19th century to me.
>
> Agree. I had a difference in opinion when I was not using those tools.
> My perspective changed after using Github and Gerrit etc.
>
> Github pull request and integrated public CI(Travis, Shippable ,
> codecov) makes collaboration easy.
> Currently, in patchwork, we can not assign a patch other than the set
> of maintainers.
> I think, it would help the review process if the more fine-grained
> owner will be responsible for specific
> patch set.

 The more fine-grain is achieved with Cc in mail.
 But I understand not everybody knows/wants/can configure correctly
 an email client. Emails are not easy for everybody, I agree.

 I use GitHub as well, and I really prefer the clarity of the mail threads.
 GitHub reviews tend to be line-focused, messy and not discussion-friendly.
 I think contribution quality would be worst if using GitHub.
>>>
>>> I have more experience with Gitlab than Github, but i really don't see
>>> it that way.
>>>
>>> For one, reviewing in Gitlab makes it easier to see context in which
>>> changes appear. I mean, obviously, you can download the patch, apply it,
>>> and then do whatever you want with it in your editor/IDE, but it's just
>>> so much faster to do it right in the browser. Reviewing things with
>>> proper syntax highlighting and side-by-side diff with an option to see
>>> more context really makes a huge difference and is that much faster.
>>
>> OK
>>
>>
>>> I would also vehemently disagree with the "clarity" argument. There is
>>> enforced minimum standard of clarity of discussion in a tool such as
>>> Gitlab. I'm sure you noticed that some people top-post, some
>>> bottom-post. Some will remove extraneous lines of patches while some
>>> will leave on comment in a 10K line patch and leave the rest as is, in
>>> quotes. Some people do weird quoting where they don't actually quote but
>>> just copy text verbatim, making it hard to determine where the quote
>>> starts. If the thread is long enough, you'd see the same text quoted
>>> over and over and over. All of that is not a problem within a single
>>> patch email, but it adds up to lots of wasted time on all sides.
>>
>> Yes
>>
>> My concern about clarity is the history of the discussion.
>> When we post a new versions in GitHub, it's very hard to keep track
>> of the history.
>> As a maintainer, I need to see the history to understand what happened,
>> what we are waiting for, and what should be merged.
> 
> IMO, The complete history is available per pull request URL.
> I think, Github also email notification mechanism those to prefer to see
> comments in the email too.
> 
> In addition to that, Bugzilla, patchwork, CI stuff all integrated into
> one place.
> I am quite impressed with vscode community collaboration.
> https://github.com/Microsoft/vscode/pulls

Out of curiosity, just checked the git history and I'm not that
impressed. For example last commit on the master branch:

https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148

Commit title: " Fix #98530 "
Commit message empty, no explanation on what the patch is doing.

Then, let's check the the issue it is pointed to:
https://github.com/microsoft/vscode/issues/98530

Issue is created 15 minutes before the patch is being merged. All that
done by the same contributor, without any review.

Re: [dpdk-dev] [PATCH v1]doc:Update i40e PMD firmware/driver mapping table.

[Ferruh Yigit]

On 5/25/2020 3:03 AM, Xing, Beilei wrote:
> 
> 
>> -Original Message-
>> From: Yigit, Ferruh 
>> Sent: Friday, May 22, 2020 11:31 PM
>> To: Xing, Beilei ; Chen, Zhaoyan
>> ; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v1]doc:Update i40e PMD firmware/driver
>> mapping table.
>>
>> On 5/22/2020 3:20 AM, Xing, Beilei wrote:
>>>
>>>
 -Original Message-
 From: dev  On Behalf Of Chen, Zhaoyan
 Sent: Thursday, May 21, 2020 3:45 PM
 To: dev@dpdk.org
 Cc: Chen, Zhaoyan 
 Subject: [dpdk-dev] [PATCH v1]doc:Update i40e PMD firmware/driver
 mapping table.
>>>
>>> Minor comments:
>>> 1. Space is needed after colon
>>> 2. Update -> update
>>> 3. no need . in the tile
>>> So it should be like "doc: update firmware/driver mapping table for i40e"
>>
>> Hi Beilei,
>>
>> If the content is correct and only issue is above ones, I can fix them while
>> merging.
>>
> 
> Yes, thanks.
> 
> Except the minor comments,
> Acked-by: Beilei Xing 
> 

(Used suggested title.)

Applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 4:52 PM, Maxime Coquelin wrote:



On 5/25/20 5:35 PM, Jerin Jacob wrote:

On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon  wrote:


25/05/2020 16:28, Burakov, Anatoly:

On 25-May-20 1:53 PM, Thomas Monjalon wrote:

25/05/2020 13:58, Jerin Jacob:

25/05/2020 11:34, Morten Brørup:

sending patches over an
email as opposed to a well-integrated web interface workflow is so alien
to most people that it definitely does discourage new contributions.

I understand the advantages of mailing lists (vendor independence,
universal compatibility, etc.), but after doing reviews in Github/Gitlab
for a while (we use those internally), going through DPDK mailing list
and reviewing code over email fills me with existential dread, as the
process feels so manual and 19th century to me.


Agree. I had a difference in opinion when I was not using those tools.
My perspective changed after using Github and Gerrit etc.

Github pull request and integrated public CI(Travis, Shippable ,
codecov) makes collaboration easy.
Currently, in patchwork, we can not assign a patch other than the set
of maintainers.
I think, it would help the review process if the more fine-grained
owner will be responsible for specific
patch set.


The more fine-grain is achieved with Cc in mail.
But I understand not everybody knows/wants/can configure correctly
an email client. Emails are not easy for everybody, I agree.

I use GitHub as well, and I really prefer the clarity of the mail threads.
GitHub reviews tend to be line-focused, messy and not discussion-friendly.
I think contribution quality would be worst if using GitHub.


I have more experience with Gitlab than Github, but i really don't see
it that way.

For one, reviewing in Gitlab makes it easier to see context in which
changes appear. I mean, obviously, you can download the patch, apply it,
and then do whatever you want with it in your editor/IDE, but it's just
so much faster to do it right in the browser. Reviewing things with
proper syntax highlighting and side-by-side diff with an option to see
more context really makes a huge difference and is that much faster.


OK



I would also vehemently disagree with the "clarity" argument. There is
enforced minimum standard of clarity of discussion in a tool such as
Gitlab. I'm sure you noticed that some people top-post, some
bottom-post. Some will remove extraneous lines of patches while some
will leave on comment in a 10K line patch and leave the rest as is, in
quotes. Some people do weird quoting where they don't actually quote but
just copy text verbatim, making it hard to determine where the quote
starts. If the thread is long enough, you'd see the same text quoted
over and over and over. All of that is not a problem within a single
patch email, but it adds up to lots of wasted time on all sides.


Yes

My concern about clarity is the history of the discussion.
When we post a new versions in GitHub, it's very hard to keep track
of the history.
As a maintainer, I need to see the history to understand what happened,
what we are waiting for, and what should be merged.


IMO, The complete history is available per pull request URL.
I think, Github also email notification mechanism those to prefer to see
comments in the email too.

In addition to that, Bugzilla, patchwork, CI stuff all integrated into
one place.
I am quite impressed with vscode community collaboration.
https://github.com/Microsoft/vscode/pulls


Out of curiosity, just checked the git history and I'm not that
impressed. For example last commit on the master branch:

https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148

Commit title: " Fix #98530 "
Commit message empty, no explanation on what the patch is doing.

Then, let's check the the issue it is pointed to:
https://github.com/microsoft/vscode/issues/98530

Issue is created 15 minutes before the patch is being merged. All that
done by the same contributor, without any review.



Just because they do it wrong doesn't mean we can't do it right :) This 
says more about Microsoft's lack of process around VSCode than it does 
about Github the tool.


--
Thanks,
Anatoly

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Jerin Jacob]

On Mon, May 25, 2020 at 9:22 PM Maxime Coquelin
 wrote:
>
>
>
> On 5/25/20 5:35 PM, Jerin Jacob wrote:
> > On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon  wrote:
> >>
> >> 25/05/2020 16:28, Burakov, Anatoly:
> >>> On 25-May-20 1:53 PM, Thomas Monjalon wrote:
>  25/05/2020 13:58, Jerin Jacob:
> > 25/05/2020 11:34, Morten Brørup:
> >> sending patches over an
> >> email as opposed to a well-integrated web interface workflow is so 
> >> alien
> >> to most people that it definitely does discourage new contributions.
> >>
> >> I understand the advantages of mailing lists (vendor independence,
> >> universal compatibility, etc.), but after doing reviews in 
> >> Github/Gitlab
> >> for a while (we use those internally), going through DPDK mailing list
> >> and reviewing code over email fills me with existential dread, as the
> >> process feels so manual and 19th century to me.
> >
> > Agree. I had a difference in opinion when I was not using those tools.
> > My perspective changed after using Github and Gerrit etc.
> >
> > Github pull request and integrated public CI(Travis, Shippable ,
> > codecov) makes collaboration easy.
> > Currently, in patchwork, we can not assign a patch other than the set
> > of maintainers.
> > I think, it would help the review process if the more fine-grained
> > owner will be responsible for specific
> > patch set.
> 
>  The more fine-grain is achieved with Cc in mail.
>  But I understand not everybody knows/wants/can configure correctly
>  an email client. Emails are not easy for everybody, I agree.
> 
>  I use GitHub as well, and I really prefer the clarity of the mail 
>  threads.
>  GitHub reviews tend to be line-focused, messy and not 
>  discussion-friendly.
>  I think contribution quality would be worst if using GitHub.
> >>>
> >>> I have more experience with Gitlab than Github, but i really don't see
> >>> it that way.
> >>>
> >>> For one, reviewing in Gitlab makes it easier to see context in which
> >>> changes appear. I mean, obviously, you can download the patch, apply it,
> >>> and then do whatever you want with it in your editor/IDE, but it's just
> >>> so much faster to do it right in the browser. Reviewing things with
> >>> proper syntax highlighting and side-by-side diff with an option to see
> >>> more context really makes a huge difference and is that much faster.
> >>
> >> OK
> >>
> >>
> >>> I would also vehemently disagree with the "clarity" argument. There is
> >>> enforced minimum standard of clarity of discussion in a tool such as
> >>> Gitlab. I'm sure you noticed that some people top-post, some
> >>> bottom-post. Some will remove extraneous lines of patches while some
> >>> will leave on comment in a 10K line patch and leave the rest as is, in
> >>> quotes. Some people do weird quoting where they don't actually quote but
> >>> just copy text verbatim, making it hard to determine where the quote
> >>> starts. If the thread is long enough, you'd see the same text quoted
> >>> over and over and over. All of that is not a problem within a single
> >>> patch email, but it adds up to lots of wasted time on all sides.
> >>
> >> Yes
> >>
> >> My concern about clarity is the history of the discussion.
> >> When we post a new versions in GitHub, it's very hard to keep track
> >> of the history.
> >> As a maintainer, I need to see the history to understand what happened,
> >> what we are waiting for, and what should be merged.
> >
> > IMO, The complete history is available per pull request URL.
> > I think, Github also email notification mechanism those to prefer to see
> > comments in the email too.
> >
> > In addition to that, Bugzilla, patchwork, CI stuff all integrated into
> > one place.
> > I am quite impressed with vscode community collaboration.
> > https://github.com/Microsoft/vscode/pulls
>
> Out of curiosity, just checked the git history and I'm not that
> impressed. For example last commit on the master branch:
>
> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
>
> Commit title: " Fix #98530 "
> Commit message empty, no explanation on what the patch is doing.

Yes. The merging rules, how much review is required, sanity test to
per check-in will be specific to the project requirements.
I can see zephyr RTOS project(I am following this project) will be
more close to the coding standard and other requirements.

https://github.com/zephyrproject-rtos/zephyr/pulls


>
> Then, let's check the the issue it is pointed to:
> https://github.com/microsoft/vscode/issues/98530
>
> Issue is created 15 minutes before the patch is being merged. All that
> done by the same contributor, without any review.
>

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Maxime Coquelin]

On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
>>
>>
>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
>>> On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon 
>>> wrote:

 25/05/2020 16:28, Burakov, Anatoly:
> On 25-May-20 1:53 PM, Thomas Monjalon wrote:
>> 25/05/2020 13:58, Jerin Jacob:
>>> 25/05/2020 11:34, Morten Brørup:
 sending patches over an
 email as opposed to a well-integrated web interface workflow is
 so alien
 to most people that it definitely does discourage new
 contributions.

 I understand the advantages of mailing lists (vendor independence,
 universal compatibility, etc.), but after doing reviews in
 Github/Gitlab
 for a while (we use those internally), going through DPDK
 mailing list
 and reviewing code over email fills me with existential dread,
 as the
 process feels so manual and 19th century to me.
>>>
>>> Agree. I had a difference in opinion when I was not using those
>>> tools.
>>> My perspective changed after using Github and Gerrit etc.
>>>
>>> Github pull request and integrated public CI(Travis, Shippable ,
>>> codecov) makes collaboration easy.
>>> Currently, in patchwork, we can not assign a patch other than the
>>> set
>>> of maintainers.
>>> I think, it would help the review process if the more fine-grained
>>> owner will be responsible for specific
>>> patch set.
>>
>> The more fine-grain is achieved with Cc in mail.
>> But I understand not everybody knows/wants/can configure correctly
>> an email client. Emails are not easy for everybody, I agree.
>>
>> I use GitHub as well, and I really prefer the clarity of the mail
>> threads.
>> GitHub reviews tend to be line-focused, messy and not
>> discussion-friendly.
>> I think contribution quality would be worst if using GitHub.
>
> I have more experience with Gitlab than Github, but i really don't see
> it that way.
>
> For one, reviewing in Gitlab makes it easier to see context in which
> changes appear. I mean, obviously, you can download the patch,
> apply it,
> and then do whatever you want with it in your editor/IDE, but it's
> just
> so much faster to do it right in the browser. Reviewing things with
> proper syntax highlighting and side-by-side diff with an option to see
> more context really makes a huge difference and is that much faster.

 OK


> I would also vehemently disagree with the "clarity" argument. There is
> enforced minimum standard of clarity of discussion in a tool such as
> Gitlab. I'm sure you noticed that some people top-post, some
> bottom-post. Some will remove extraneous lines of patches while some
> will leave on comment in a 10K line patch and leave the rest as is, in
> quotes. Some people do weird quoting where they don't actually
> quote but
> just copy text verbatim, making it hard to determine where the quote
> starts. If the thread is long enough, you'd see the same text quoted
> over and over and over. All of that is not a problem within a single
> patch email, but it adds up to lots of wasted time on all sides.

 Yes

 My concern about clarity is the history of the discussion.
 When we post a new versions in GitHub, it's very hard to keep track
 of the history.
 As a maintainer, I need to see the history to understand what happened,
 what we are waiting for, and what should be merged.
>>>
>>> IMO, The complete history is available per pull request URL.
>>> I think, Github also email notification mechanism those to prefer to see
>>> comments in the email too.
>>>
>>> In addition to that, Bugzilla, patchwork, CI stuff all integrated into
>>> one place.
>>> I am quite impressed with vscode community collaboration.
>>> https://github.com/Microsoft/vscode/pulls
>>
>> Out of curiosity, just checked the git history and I'm not that
>> impressed. For example last commit on the master branch:
>>
>> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
>>
>>
>> Commit title: " Fix #98530 "
>> Commit message empty, no explanation on what the patch is doing.
>>
>> Then, let's check the the issue it is pointed to:
>> https://github.com/microsoft/vscode/issues/98530
>>
>> Issue is created 15 minutes before the patch is being merged. All that
>> done by the same contributor, without any review.
>>
> 
> Just because they do it wrong doesn't mean we can't do it right :) This
> says more about Microsoft's lack of process around VSCode than it does
> about Github the tool.
> 

True. I was just pointing out that is not the kind of process I would
personally want to adopt.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Burakov, Anatoly]

On 25-May-20 5:04 PM, Maxime Coquelin wrote:



On 5/25/20 5:59 PM, Burakov, Anatoly wrote:

On 25-May-20 4:52 PM, Maxime Coquelin wrote:



On 5/25/20 5:35 PM, Jerin Jacob wrote:

On Mon, May 25, 2020 at 8:52 PM Thomas Monjalon 
wrote:


25/05/2020 16:28, Burakov, Anatoly:

On 25-May-20 1:53 PM, Thomas Monjalon wrote:

25/05/2020 13:58, Jerin Jacob:

25/05/2020 11:34, Morten Brørup:

sending patches over an
email as opposed to a well-integrated web interface workflow is
so alien
to most people that it definitely does discourage new
contributions.

I understand the advantages of mailing lists (vendor independence,
universal compatibility, etc.), but after doing reviews in
Github/Gitlab
for a while (we use those internally), going through DPDK
mailing list
and reviewing code over email fills me with existential dread,
as the
process feels so manual and 19th century to me.


Agree. I had a difference in opinion when I was not using those
tools.
My perspective changed after using Github and Gerrit etc.

Github pull request and integrated public CI(Travis, Shippable ,
codecov) makes collaboration easy.
Currently, in patchwork, we can not assign a patch other than the
set
of maintainers.
I think, it would help the review process if the more fine-grained
owner will be responsible for specific
patch set.


The more fine-grain is achieved with Cc in mail.
But I understand not everybody knows/wants/can configure correctly
an email client. Emails are not easy for everybody, I agree.

I use GitHub as well, and I really prefer the clarity of the mail
threads.
GitHub reviews tend to be line-focused, messy and not
discussion-friendly.
I think contribution quality would be worst if using GitHub.


I have more experience with Gitlab than Github, but i really don't see
it that way.

For one, reviewing in Gitlab makes it easier to see context in which
changes appear. I mean, obviously, you can download the patch,
apply it,
and then do whatever you want with it in your editor/IDE, but it's
just
so much faster to do it right in the browser. Reviewing things with
proper syntax highlighting and side-by-side diff with an option to see
more context really makes a huge difference and is that much faster.


OK



I would also vehemently disagree with the "clarity" argument. There is
enforced minimum standard of clarity of discussion in a tool such as
Gitlab. I'm sure you noticed that some people top-post, some
bottom-post. Some will remove extraneous lines of patches while some
will leave on comment in a 10K line patch and leave the rest as is, in
quotes. Some people do weird quoting where they don't actually
quote but
just copy text verbatim, making it hard to determine where the quote
starts. If the thread is long enough, you'd see the same text quoted
over and over and over. All of that is not a problem within a single
patch email, but it adds up to lots of wasted time on all sides.


Yes

My concern about clarity is the history of the discussion.
When we post a new versions in GitHub, it's very hard to keep track
of the history.
As a maintainer, I need to see the history to understand what happened,
what we are waiting for, and what should be merged.


IMO, The complete history is available per pull request URL.
I think, Github also email notification mechanism those to prefer to see
comments in the email too.

In addition to that, Bugzilla, patchwork, CI stuff all integrated into
one place.
I am quite impressed with vscode community collaboration.
https://github.com/Microsoft/vscode/pulls


Out of curiosity, just checked the git history and I'm not that
impressed. For example last commit on the master branch:

https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148


Commit title: " Fix #98530 "
Commit message empty, no explanation on what the patch is doing.

Then, let's check the the issue it is pointed to:
https://github.com/microsoft/vscode/issues/98530

Issue is created 15 minutes before the patch is being merged. All that
done by the same contributor, without any review.



Just because they do it wrong doesn't mean we can't do it right :) This
says more about Microsoft's lack of process around VSCode than it does
about Github the tool.



True. I was just pointing out that is not the kind of process I would
personally want to adopt.



You won't find disagreement here, but this "process" is not due to the 
tool. You can just as well allow Thomas to merge stuff without any 
review because he has commit rights, no Github needed - and you would be 
faced with the same problem.


So, i don't think Jerin was suggesting that we degrade our merge/commit 
rules. Rather, the point was that (whatever you think of VSCode's 
review/merge process) there are a lot of pull requests and there is 
healthy community collaboration. I'm not saying we don't have that, 
obviously, but i have a suspicion that we'll get more of it if we lower 
the barrier for entry (not the barrier for merge!). I think there is a 

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Bruce Richardson]

On Mon, May 25, 2020 at 08:47:23AM -0700, Stephen Hemminger wrote:
> On Mon, 25 May 2020 13:08:19 +0100
> Bruce Richardson  wrote:
> 
> > On Mon, May 25, 2020 at 12:12:49PM +0100, Burakov, Anatoly wrote:
> > > On 25-May-20 10:34 AM, Morten Brørup wrote:  
> > > > Dear DPDK Techboard,
> > > > 
> > > > I am writing this to raise awareness about the environment for 
> > > > contributing to DPDK, as I feel that it could be improved. This is not 
> > > > a personal thing - I have thick skin - but a general observation. I 
> > > > urge the DPDK Techboard to spend some time to focus on the process, and 
> > > > not only on the technology.
> > > > 
> > > > Contributing to DPDK is not easy for infrequent contributors:
> > > > 
> > > > 1. Infrequent contributors are limited by not being deeply familiar 
> > > > with the coding style and the commit style, so their style is not 
> > > > always 100 % spot on.
> > > > 2. Infrequent contributors are limited by not having built trust by the 
> > > > maintainers and frequent contributors, and thus their contributions 
> > > > undergo more detailed reviews and get more negative (or: perceived 
> > > > negative) feedback, where trusted contributors are given more slack. 
> > > > (In theory, every contribution should be treated equal, but in reality 
> > > > it makes sense allocating fewer resources to review contributions from 
> > > > developers with a proven track record.)
> > > > 3. Infrequent contributors may not be deeply familiar with the 
> > > > development/contribution tools. E.g. how to use git the "DPDK way".
> > > > 
> > > > Additionally, when contributing to old DPDK code, checkpatch complains 
> > > > about coding style violations stemming from the existing old code. This 
> > > > also raises the barrier and decreases the motivation to contribute - a 
> > > > contributor getting negative feedback about something he didn't even do.
> > > > 
> > > > 
> > > > Here are a couple of anonymous examples from the mailing list:
> > > > 
> > > > An infrequent contributor got minor coding style suggestions to a 
> > > > patch, although the coding style was similar to that of a closely 
> > > > related function in the same library, but not perfectly matching the 
> > > > official coding style. I think we could be more lax about coding style, 
> > > > except if the coding style directly violates automatic coding style 
> > > > validation tools.
> > > >   
> > > 
> > > A lot of that could simply be fixed by codifying our Coding Style into a
> > > .clang-format file, and make this process (semi-)automatic. A lot of
> > > IDE's/editors now have either built-in support for clang-format, or have
> > > plugins enabling said support.
> > > 
> > > I've investigated this in the past and found that our coding style
> > > guidelines are very specific in some places, and neither clang-format nor
> > > other options have that kind of detailed control over source code
> > > formatting. The only other option would be to adjust our coding style to 
> > > fit
> > > the options available in clang-format.
> > > 
> > > IMO this would cut down a lot on complaints about mixing indents, wrong
> > > alignment, (lack of) newlines before function name, etc.
> > >   
> > 
> > This is of definite interest to me, for one. How close to our current
> > standards can we get right now with clang-format? If the coding standards
> > right now can't match exactly, how big would be the changes to make them
> > doable in clang-format? Is it one or two things, or is it quite a number?
> > 
> > /Bruce
> 
> Or just adjust the coding style to match a clang format.
> For a positive example of a project that does this see VPP. They have:
>   make checkstyle
> and   make fixstyle
> 
> And their CI bot checks it.

Yes, that was what I was implying by asking how big the delta was. :-) If
there are just a couple of things that don't quite align, the benefit of
getting clang-format outweighs the downsides of tweaking our coding
standards, IMHO.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Thomas Monjalon]

25/05/2020 18:09, Burakov, Anatoly:
> On 25-May-20 5:04 PM, Maxime Coquelin wrote:
> > On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
> >> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
> >>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
>  On May 25, 2020 Thomas Monjalon wrote:
> > My concern about clarity is the history of the discussion.
> > When we post a new versions in GitHub, it's very hard to keep track
> > of the history.
> > As a maintainer, I need to see the history to understand what happened,
> > what we are waiting for, and what should be merged.
> 
>  IMO, The complete history is available per pull request URL.
>  I think, Github also email notification mechanism those to prefer to see
>  comments in the email too.
> 
>  In addition to that, Bugzilla, patchwork, CI stuff all integrated into
>  one place.
>  I am quite impressed with vscode community collaboration.
>  https://github.com/Microsoft/vscode/pulls
> >>>
> >>> Out of curiosity, just checked the git history and I'm not that
> >>> impressed. For example last commit on the master branch:
> >>>
> >>> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
> >>>
> >>>
> >>> Commit title: " Fix #98530 "
> >>> Commit message empty, no explanation on what the patch is doing.
> >>>
> >>> Then, let's check the the issue it is pointed to:
> >>> https://github.com/microsoft/vscode/issues/98530
> >>>
> >>> Issue is created 15 minutes before the patch is being merged. All that
> >>> done by the same contributor, without any review.
> >>>
> >>
> >> Just because they do it wrong doesn't mean we can't do it right :) This
> >> says more about Microsoft's lack of process around VSCode than it does
> >> about Github the tool.
> >>
> > 
> > True. I was just pointing out that is not the kind of process I would
> > personally want to adopt.
> > 
> 
> You won't find disagreement here, but this "process" is not due to the 
> tool. You can just as well allow Thomas to merge stuff without any 
> review because he has commit rights, no Github needed - and you would be 
> faced with the same problem.
> 
> So, i don't think Jerin was suggesting that we degrade our merge/commit 
> rules. Rather, the point was that (whatever you think of VSCode's 
> review/merge process) there are a lot of pull requests and there is 
> healthy community collaboration. I'm not saying we don't have that,

Yes, recent survey said the process was fine:
http://mails.dpdk.org/archives/announce/2019-June/000268.html


> obviously, but i have a suspicion that we'll get more of it if we lower 
> the barrier for entry (not the barrier for merge!). I think there is a 
> way to lower the secondary skill level needed to contribute to DPDK 
> without lowering coding/merge standards with it.

About the barrier for entry, maybe it is not obvious because I don't
communicate a lot about it, but please be aware that I (and other
maintainers I think) are doing a lot of changes in newcomer patches
to avoid asking them knowing the whole process from the beginning.
Then frequent contributors get educated on the way.

I think the only real barrier we have is to sign the patch
with a real name and send an email to right list.
The ask for SoB real name is probably what started this thread
in Morten's mind. And the SoB requirement will *never* change.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Wiles, Keith]

> On May 25, 2020, at 11:28 AM, Thomas Monjalon  wrote:
> 
> 25/05/2020 18:09, Burakov, Anatoly:
>> On 25-May-20 5:04 PM, Maxime Coquelin wrote:
>>> On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
 On 25-May-20 4:52 PM, Maxime Coquelin wrote:
> On 5/25/20 5:35 PM, Jerin Jacob wrote:
>> On May 25, 2020 Thomas Monjalon wrote:
>>> My concern about clarity is the history of the discussion.
>>> When we post a new versions in GitHub, it's very hard to keep track
>>> of the history.
>>> As a maintainer, I need to see the history to understand what happened,
>>> what we are waiting for, and what should be merged.
>> 
>> IMO, The complete history is available per pull request URL.
>> I think, Github also email notification mechanism those to prefer to see
>> comments in the email too.
>> 
>> In addition to that, Bugzilla, patchwork, CI stuff all integrated into
>> one place.
>> I am quite impressed with vscode community collaboration.
>> https://github.com/Microsoft/vscode/pulls
> 
> Out of curiosity, just checked the git history and I'm not that
> impressed. For example last commit on the master branch:
> 
> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
> 
> 
> Commit title: " Fix #98530 "
> Commit message empty, no explanation on what the patch is doing.
> 
> Then, let's check the the issue it is pointed to:
> https://github.com/microsoft/vscode/issues/98530
> 
> Issue is created 15 minutes before the patch is being merged. All that
> done by the same contributor, without any review.
> 
 
 Just because they do it wrong doesn't mean we can't do it right :) This
 says more about Microsoft's lack of process around VSCode than it does
 about Github the tool.
 
>>> 
>>> True. I was just pointing out that is not the kind of process I would
>>> personally want to adopt.
>>> 
>> 
>> You won't find disagreement here, but this "process" is not due to the 
>> tool. You can just as well allow Thomas to merge stuff without any 
>> review because he has commit rights, no Github needed - and you would be 
>> faced with the same problem.
>> 
>> So, i don't think Jerin was suggesting that we degrade our merge/commit 
>> rules. Rather, the point was that (whatever you think of VSCode's 
>> review/merge process) there are a lot of pull requests and there is 
>> healthy community collaboration. I'm not saying we don't have that,
> 
> Yes, recent survey said the process was fine:
>   http://mails.dpdk.org/archives/announce/2019-June/000268.html

IMO the survey is not a great tool for these types of things. The tech board 
and others that fully understand the process should decide. From my experience 
using Github or Gitlab is much easy and a single tool to submit patches to a 
project. Anatoly and others stated it very well and we should convert IMO, as I 
have always stated in the past.
> 
> 
>> obviously, but i have a suspicion that we'll get more of it if we lower 
>> the barrier for entry (not the barrier for merge!). I think there is a 
>> way to lower the secondary skill level needed to contribute to DPDK 
>> without lowering coding/merge standards with it.
> 
> About the barrier for entry, maybe it is not obvious because I don't
> communicate a lot about it, but please be aware that I (and other
> maintainers I think) are doing a lot of changes in newcomer patches
> to avoid asking them knowing the whole process from the beginning.
> Then frequent contributors get educated on the way.
> 
> I think the only real barrier we have is to sign the patch
> with a real name and send an email to right list.
> The ask for SoB real name is probably what started this thread
> in Morten's mind. And the SoB requirement will *never* change.
> 
> 

Would it not free up your time and energies by have the tools do most of the 
work. then you can focus on what matters the patch and developing more 
features? 

There is a reasons millions of developer use one of these two tools, instead of 
emailing patch around. We are a fairly small project compared to Linux Kernel 
and we are not developing code for the Linux kernel. Some of the process like 
coding standard is great, but the rest is just legacy IMO and not required to 
get the job done. Having tools to keep track of the minutia should free up more 
of your time for the real development.

Yes, it will be a learning curve for some and nailing down the process or rules 
for merge requests needs to be done.

All in all it will be a huge improvement for contributors.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Thomas Monjalon]

25/05/2020 18:57, Wiles, Keith:
> On May 25, 2020, at 11:28 AM, Thomas Monjalon  wrote:
> > 25/05/2020 18:09, Burakov, Anatoly:
> >> On 25-May-20 5:04 PM, Maxime Coquelin wrote:
> >>> On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
>  On 25-May-20 4:52 PM, Maxime Coquelin wrote:
> > On 5/25/20 5:35 PM, Jerin Jacob wrote:
> >> On May 25, 2020 Thomas Monjalon wrote:
> >>> My concern about clarity is the history of the discussion.
> >>> When we post a new versions in GitHub, it's very hard to keep track
> >>> of the history.
> >>> As a maintainer, I need to see the history to understand what 
> >>> happened,
> >>> what we are waiting for, and what should be merged.
> >> 
> >> IMO, The complete history is available per pull request URL.
> >> I think, Github also email notification mechanism those to prefer to 
> >> see
> >> comments in the email too.
> >> 
> >> In addition to that, Bugzilla, patchwork, CI stuff all integrated into
> >> one place.
> >> I am quite impressed with vscode community collaboration.
> >> https://github.com/Microsoft/vscode/pulls
> > 
> > Out of curiosity, just checked the git history and I'm not that
> > impressed. For example last commit on the master branch:
> > 
> > https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
> > 
> > 
> > Commit title: " Fix #98530 "
> > Commit message empty, no explanation on what the patch is doing.
> > 
> > Then, let's check the the issue it is pointed to:
> > https://github.com/microsoft/vscode/issues/98530
> > 
> > Issue is created 15 minutes before the patch is being merged. All that
> > done by the same contributor, without any review.
> > 
>  
>  Just because they do it wrong doesn't mean we can't do it right :) This
>  says more about Microsoft's lack of process around VSCode than it does
>  about Github the tool.
>  
> >>> 
> >>> True. I was just pointing out that is not the kind of process I would
> >>> personally want to adopt.
> >>> 
> >> 
> >> You won't find disagreement here, but this "process" is not due to the 
> >> tool. You can just as well allow Thomas to merge stuff without any 
> >> review because he has commit rights, no Github needed - and you would be 
> >> faced with the same problem.
> >> 
> >> So, i don't think Jerin was suggesting that we degrade our merge/commit 
> >> rules. Rather, the point was that (whatever you think of VSCode's 
> >> review/merge process) there are a lot of pull requests and there is 
> >> healthy community collaboration. I'm not saying we don't have that,
> > 
> > Yes, recent survey said the process was fine:
> > http://mails.dpdk.org/archives/announce/2019-June/000268.html
> 
> IMO the survey is not a great tool for these types of things. The tech board 
> and others that fully understand the process should decide. From my 
> experience using Github or Gitlab is much easy and a single tool to submit 
> patches to a project. Anatoly and others stated it very well and we should 
> convert IMO, as I have always stated in the past.
> > 
> > 
> >> obviously, but i have a suspicion that we'll get more of it if we lower 
> >> the barrier for entry (not the barrier for merge!). I think there is a 
> >> way to lower the secondary skill level needed to contribute to DPDK 
> >> without lowering coding/merge standards with it.
> > 
> > About the barrier for entry, maybe it is not obvious because I don't
> > communicate a lot about it, but please be aware that I (and other
> > maintainers I think) are doing a lot of changes in newcomer patches
> > to avoid asking them knowing the whole process from the beginning.
> > Then frequent contributors get educated on the way.
> > 
> > I think the only real barrier we have is to sign the patch
> > with a real name and send an email to right list.
> > The ask for SoB real name is probably what started this thread
> > in Morten's mind. And the SoB requirement will *never* change.
> 
> Would it not free up your time and energies by have the tools
> do most of the work. then you can focus on what matters the patch
> and developing more features?

No, GitHub is not helping to track root cause and define what should be 
backported.
It does not help to track Coverity issues.
It does not add Acks automatically (but patchwork does).
It does not send a notification when enough review is done (judgement needed 
here).
It does not split patches when different bugs are fixed.
etc...

But yes GitHub provides a beautiful interface,
and can help with reviews (even if not my taste).

One more thing I experience sometimes, GitHub requires only one account
for all hosted projects, so it helps leaving quick comments in projects
we are not familiar with.


> There is a reasons millions of developer use one of these two tools, instead 
> of emailing patch around. We are a fairly small project compared to Lin

[dpdk-dev] [PATCH v4] net/axgbe: enabling VLAN support in axgbe

[ssardar]

From: Sardar Shamsher Singh 

adding below APIs for axgbe
- axgbe_enable_rx_vlan_stripping: to enable vlan header stipping
- axgbe_disable_rx_vlan_stripping: to disable vlan header stipping
- axgbe_enable_rx_vlan_filtering: to enable vlan filter mode
- axgbe_disable_rx_vlan_filtering: to disable vlan filter mode
- axgbe_update_vlan_hash_table: crc calculation and hash table update
based on vlan values post filter enable
- axgbe_vlan_filter_set: setting of active vlan out of max 4K values before
doing hash update of same
- axgbe_vlan_tpid_set: setting of default tpid values
- axgbe_vlan_offload_set: a top layer function to call stip/filter etc
based on mask values

Signed-off-by: Sardar Shamsher Singh 
---
 doc/guides/nics/features/axgbe.ini |   1 +
 drivers/net/axgbe/axgbe_common.h   |  30 +
 drivers/net/axgbe/axgbe_dev.c  | 171 ++--
 drivers/net/axgbe/axgbe_ethdev.c   | 173 -
 drivers/net/axgbe/axgbe_ethdev.h   |  16 +++
 drivers/net/axgbe/axgbe_rxtx.c |  69 +++-
 6 files changed, 444 insertions(+), 16 deletions(-)

diff --git a/doc/guides/nics/features/axgbe.ini 
b/doc/guides/nics/features/axgbe.ini
index 0becaa097..b7b4dd992 100644
--- a/doc/guides/nics/features/axgbe.ini
+++ b/doc/guides/nics/features/axgbe.ini
@@ -11,6 +11,7 @@ Scattered Rx = Y
 Promiscuous mode = Y
 Allmulticast mode= Y
 RSS hash = Y
+VLAN = Y
 CRC offload  = Y
 L3 checksum offload  = Y
 L4 checksum offload  = Y
diff --git a/drivers/net/axgbe/axgbe_common.h b/drivers/net/axgbe/axgbe_common.h
index f48117180..639e3c965 100644
--- a/drivers/net/axgbe/axgbe_common.h
+++ b/drivers/net/axgbe/axgbe_common.h
@@ -257,6 +257,7 @@
 #define MAC_HWF0R  0x011c
 #define MAC_HWF1R  0x0120
 #define MAC_HWF2R  0x0124
+#define MAC_HWF3R  0x0128
 #define MAC_MDIOSCAR   0x0200
 #define MAC_MDIOSCCDR  0x0204
 #define MAC_MDIOISR0x0214
@@ -282,6 +283,19 @@
 #define MAC_TXSNR  0x0d30
 #define MAC_TXSSR  0x0d34
 
+/*VLAN control bit mask*/
+#define AXGBE_VLNCTRL_MASK 0x
+#define VLAN_PRIO_MASK 0xe000 /* Priority Code Point */
+#define VLAN_PRIO_SHIFT13
+#define VLAN_CFI_MASK  0x1000 /* Canonical Format Indicator */
+#define VLAN_TAG_PRESENT   VLAN_CFI_MASK
+#define VLAN_VID_MASK  0x0fff /* VLAN Identifier */
+#define VLAN_N_VID 4096
+#define VLAN_TABLE_SIZE64
+#define VLAN_TABLE_BIT(vlan_id)(1UL << ((vlan_id) & 0x3F))
+#define VLAN_TABLE_IDX(vlan_id)((vlan_id) >> 6)
+#define RX_CVLAN_TAG_PRESENT   9
+
 #define MAC_QTFCR_INC  4
 #define MAC_MACA_INC   4
 #define MAC_HTR_INC4
@@ -359,6 +373,10 @@
 #define MAC_HWF2R_TXCHCNT_WIDTH4
 #define MAC_HWF2R_TXQCNT_INDEX 6
 #define MAC_HWF2R_TXQCNT_WIDTH 4
+#define MAC_HWF3R_CBTISEL_INDEX4
+#define MAC_HWF3R_CBTISEL_WIDTH1
+#define MAC_HWF3R_NRVF_INDEX   0
+#define MAC_HWF3R_NRVF_WIDTH   3
 #define MAC_IER_TSIE_INDEX 12
 #define MAC_IER_TSIE_WIDTH 1
 #define MAC_ISR_MMCRXIS_INDEX  9
@@ -513,6 +531,8 @@
 #define MAC_VLANIR_VLTI_WIDTH  1
 #define MAC_VLANIR_CSVL_INDEX  19
 #define MAC_VLANIR_CSVL_WIDTH  1
+#define MAC_VLANIR_VLC_INDEX   16
+#define MAC_VLANIR_VLC_WIDTH   2
 #define MAC_VLANTR_DOVLTC_INDEX20
 #define MAC_VLANTR_DOVLTC_WIDTH1
 #define MAC_VLANTR_ERSVLM_INDEX19
@@ -523,12 +543,18 @@
 #define MAC_VLANTR_ETV_WIDTH   1
 #define MAC_VLANTR_EVLS_INDEX  21
 #define MAC_VLANTR_EVLS_WIDTH  2
+#define MAC_VLANTR_EIVLS_INDEX 21
+#define MAC_VLANTR_EIVLS_WIDTH 2
 #define MAC_VLANTR_EVLRXS_INDEX24
 #define MAC_VLANTR_EVLRXS_WIDTH1
+#define MAC_VLANTR_EIVLRXS_INDEX   31
+#define MAC_VLANTR_EIVLRXS_WIDTH   1
 #define MAC_VLANTR_VL_INDEX0
 #define MAC_VLANTR_VL_WIDTH16
 #define MAC_VLANTR_VTHM_INDEX  25
 #define MAC_VLANTR_VTHM_WIDTH  1
+#define MAC_VLANTR_EDVLP_INDEX 26
+#define MAC_VLANTR_EDVLP_WIDTH 1
 #define MAC_VLANTR_VTIM_INDEX  17
 #define MAC_VLANTR_VTIM_WIDTH  1
 #define MAC_VR_DEVID_INDEX 8
@@ -537,6 +563,10 @@
 #define MAC_VR_SNPSVER_WIDTH   8
 #define MAC_VR_USERVER_INDEX   16
 #define MAC_VR_USERVER_WIDTH   8
+#define MAC_VLANIR_VLT_INDEX   0
+#define MAC_VLANIR_VLT_WIDTH   16
+#define MAC_VLANTR_ERIVLT_INDEX27
+#define MAC_VLANTR_ERIVLT_WIDTH1
 
 /* MMC register

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDK contribution processes

[Wiles, Keith]

> On May 25, 2020, at 12:32 PM, Thomas Monjalon  wrote:
> 
> 25/05/2020 18:57, Wiles, Keith:
>> On May 25, 2020, at 11:28 AM, Thomas Monjalon  wrote:
>>> 25/05/2020 18:09, Burakov, Anatoly:
 On 25-May-20 5:04 PM, Maxime Coquelin wrote:
> On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
>> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
>>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
 On May 25, 2020 Thomas Monjalon wrote:
> My concern about clarity is the history of the discussion.
> When we post a new versions in GitHub, it's very hard to keep track
> of the history.
> As a maintainer, I need to see the history to understand what 
> happened,
> what we are waiting for, and what should be merged.
 
 IMO, The complete history is available per pull request URL.
 I think, Github also email notification mechanism those to prefer to 
 see
 comments in the email too.
 
 In addition to that, Bugzilla, patchwork, CI stuff all integrated into
 one place.
 I am quite impressed with vscode community collaboration.
 https://github.com/Microsoft/vscode/pulls
>>> 
>>> Out of curiosity, just checked the git history and I'm not that
>>> impressed. For example last commit on the master branch:
>>> 
>>> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb7446b3915d6148
>>> 
>>> 
>>> Commit title: " Fix #98530 "
>>> Commit message empty, no explanation on what the patch is doing.
>>> 
>>> Then, let's check the the issue it is pointed to:
>>> https://github.com/microsoft/vscode/issues/98530
>>> 
>>> Issue is created 15 minutes before the patch is being merged. All that
>>> done by the same contributor, without any review.
>>> 
>> 
>> Just because they do it wrong doesn't mean we can't do it right :) This
>> says more about Microsoft's lack of process around VSCode than it does
>> about Github the tool.
>> 
> 
> True. I was just pointing out that is not the kind of process I would
> personally want to adopt.
> 
 
 You won't find disagreement here, but this "process" is not due to the 
 tool. You can just as well allow Thomas to merge stuff without any 
 review because he has commit rights, no Github needed - and you would be 
 faced with the same problem.
 
 So, i don't think Jerin was suggesting that we degrade our merge/commit 
 rules. Rather, the point was that (whatever you think of VSCode's 
 review/merge process) there are a lot of pull requests and there is 
 healthy community collaboration. I'm not saying we don't have that,
>>> 
>>> Yes, recent survey said the process was fine:
>>> http://mails.dpdk.org/archives/announce/2019-June/000268.html
>> 
>> IMO the survey is not a great tool for these types of things. The tech board 
>> and others that fully understand the process should decide. From my 
>> experience using Github or Gitlab is much easy and a single tool to submit 
>> patches to a project. Anatoly and others stated it very well and we should 
>> convert IMO, as I have always stated in the past.
>>> 
>>> 
 obviously, but i have a suspicion that we'll get more of it if we lower 
 the barrier for entry (not the barrier for merge!). I think there is a 
 way to lower the secondary skill level needed to contribute to DPDK 
 without lowering coding/merge standards with it.
>>> 
>>> About the barrier for entry, maybe it is not obvious because I don't
>>> communicate a lot about it, but please be aware that I (and other
>>> maintainers I think) are doing a lot of changes in newcomer patches
>>> to avoid asking them knowing the whole process from the beginning.
>>> Then frequent contributors get educated on the way.
>>> 
>>> I think the only real barrier we have is to sign the patch
>>> with a real name and send an email to right list.
>>> The ask for SoB real name is probably what started this thread
>>> in Morten's mind. And the SoB requirement will *never* change.
>> 
>> Would it not free up your time and energies by have the tools
>> do most of the work. then you can focus on what matters the patch
>> and developing more features?
> 
> No, GitHub is not helping to track root cause and define what should be 
> backported.
> It does not help to track Coverity issues.
> It does not add Acks automatically (but patchwork does).
> It does not send a notification when enough review is done (judgement needed 
> here).
> It does not split patches when different bugs are fixed.
> etc...

Thanks for reading my emails and I am trying to help DPDK as a whole.

All of these seem to be supported by GitHub or GitLab in one way or another, 
but other more versed in these tools can correct me.

- We use Coverity and other tools attached to GitLab and they seem to be doing 
the job. I agree we will always find issues and

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes

[Morten Brørup]

> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, May 25, 2020 6:29 PM
> 
> 25/05/2020 18:09, Burakov, Anatoly:
> > On 25-May-20 5:04 PM, Maxime Coquelin wrote:
> > > On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
> > >> On 25-May-20 4:52 PM, Maxime Coquelin wrote:
> > >>> On 5/25/20 5:35 PM, Jerin Jacob wrote:
> >  On May 25, 2020 Thomas Monjalon wrote:
> > > My concern about clarity is the history of the discussion.
> > > When we post a new versions in GitHub, it's very hard to keep
> track
> > > of the history.
> > > As a maintainer, I need to see the history to understand what
> happened,
> > > what we are waiting for, and what should be merged.
> > 
> >  IMO, The complete history is available per pull request URL.
> >  I think, Github also email notification mechanism those to
> prefer to see
> >  comments in the email too.
> > 
> >  In addition to that, Bugzilla, patchwork, CI stuff all
> integrated into
> >  one place.
> >  I am quite impressed with vscode community collaboration.
> >  https://github.com/Microsoft/vscode/pulls
> > >>>
> > >>> Out of curiosity, just checked the git history and I'm not that
> > >>> impressed. For example last commit on the master branch:
> > >>>
> > >>>
> https://github.com/microsoft/vscode/commit/2a4cecf3f2f72346d06990feeb74
> 46b3915d6148
> > >>>
> > >>>
> > >>> Commit title: " Fix #98530 "
> > >>> Commit message empty, no explanation on what the patch is doing.
> > >>>
> > >>> Then, let's check the the issue it is pointed to:
> > >>> https://github.com/microsoft/vscode/issues/98530
> > >>>
> > >>> Issue is created 15 minutes before the patch is being merged. All
> that
> > >>> done by the same contributor, without any review.
> > >>>
> > >>
> > >> Just because they do it wrong doesn't mean we can't do it right :)
> This
> > >> says more about Microsoft's lack of process around VSCode than it
> does
> > >> about Github the tool.
> > >>
> > >
> > > True. I was just pointing out that is not the kind of process I
> would
> > > personally want to adopt.
> > >
> >
> > You won't find disagreement here, but this "process" is not due to
> the
> > tool. You can just as well allow Thomas to merge stuff without any
> > review because he has commit rights, no Github needed - and you would
> be
> > faced with the same problem.
> >
> > So, i don't think Jerin was suggesting that we degrade our
> merge/commit
> > rules. Rather, the point was that (whatever you think of VSCode's
> > review/merge process) there are a lot of pull requests and there is
> > healthy community collaboration. I'm not saying we don't have that,
> 
> Yes, recent survey said the process was fine:
>   http://mails.dpdk.org/archives/announce/2019-June/000268.html
> 
> 
> > obviously, but i have a suspicion that we'll get more of it if we
> lower
> > the barrier for entry (not the barrier for merge!). I think there is
> a
> > way to lower the secondary skill level needed to contribute to DPDK
> > without lowering coding/merge standards with it.

That is exactly what I am asking for: Lowering the barrier and increasing the 
feeling of success for newcomers. (The barrier for merge is probably fine; I'll 
leave that discussion to the maintainers.)

> 
> About the barrier for entry, maybe it is not obvious because I don't
> communicate a lot about it, but please be aware that I (and other
> maintainers I think) are doing a lot of changes in newcomer patches
> to avoid asking them knowing the whole process from the beginning.
> Then frequent contributors get educated on the way.

Great! I wish that every developer would think and behave this way.

> 
> I think the only real barrier we have is to sign the patch
> with a real name and send an email to right list.
> The ask for SoB real name is probably what started this thread
> in Morten's mind. And the SoB requirement will *never* change.

The incorrect Signed-off-by might be the only hard barrier (which we cannot 
avoid). But that did not trigger me.

I was raising the discussion to bring attention to soft barriers for 
contributors. What triggered me was the request to split the patch into 
multiple patches; a kind of feedback I have seen before. For an experienced git 
user, this is probably very easy, but for a git newbie (like myself), it 
basically means starting all over and trying to figure out the right set of git 
commands to do this, which can be perceived as a difficult task requiring a lot 
of effort.

Perhaps we could supplement the Contributor Guidelines with a set of cookbooks 
for different steps in the contribution process, so reviewers can be refer 
newcomers to the relevant of these as part of the feedback. Just like any 
professional customer support team has a set of canned answers ready for common 
customer issues. (Please note: I am not suggesting adding an AI/ML chat bot 
reviewer to the mailing list!)

The amount of Contributor Guideline docume

[dpdk-dev] [PATCH] doc: add tested platforms with Broadcom NICs

[Ajit Khaparde]

Signed-off-by: Ajit Khaparde 
---
 doc/guides/rel_notes/release_20_05.rst | 49 ++
 1 file changed, 49 insertions(+)

diff --git a/doc/guides/rel_notes/release_20_05.rst 
b/doc/guides/rel_notes/release_20_05.rst
index a61631e87..46fb30127 100644
--- a/doc/guides/rel_notes/release_20_05.rst
+++ b/doc/guides/rel_notes/release_20_05.rst
@@ -653,3 +653,52 @@ Tested Platforms
 * Ubuntu 16.10
 * Ubuntu 18.04.1
 * Ubuntu 19.04
+
+* Intel\ |reg| platforms with Broadcom\ |reg| NICs combinations
+
+  * CPU:
+
+* Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2650 v2 @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| CPU E5-2667 v3 @ 3.20GHz
+* Intel\ |reg| Xeon\ |reg| Gold 6142 CPU @ 2.60GHz
+* Intel\ |reg| Xeon\ |reg| Silver 4110 CPU @ 2.10GHz
+
+  * OS:
+* Red Hat Enterprise Linux Server release 8.1
+* Red Hat Enterprise Linux Server release 7.6
+* Red Hat Enterprise Linux Server release 7.5
+* Ubuntu 16.04
+* Centos 8.1
+* Centos 7.7
+
+  * upstream kernel:
+
+* Linux 5.3
+
+  * NICs:
+
+* Broadcom\ |reg| NetXtreme-E\ |reg| Series P225p (2x25G)
+
+  * Host interface: PCI Express 3.0 x8
+  * Firmware version: 214.4.81.0 and above
+
+* Broadcom\ |reg| NetXtreme-E\ |reg| Series P425p (4x25G)
+
+  * Host interface: PCI Express 3.0 x16
+  * Firmware version: 216.4.259.0 and above
+
+* Broadcom\ |reg| NetXtreme-E\ |reg| Series P2100G (2x100G)
+
+  * Host interface: PCI Express 3.0 x16
+  * Firmware version: 216.1.259.0 and above
+
+* Broadcom\ |reg| NetXtreme-E\ |reg| Series P425p (4x25G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Firmware version: 216.1.259.0 and above
+
+* Broadcom\ |reg| NetXtreme-E\ |reg| Series P2100G (2x100G)
+
+  * Host interface: PCI Express 4.0 x16
+  * Firmware version: 216.1.259.0 and above
-- 
2.21.1 (Apple Git-122.3)

[dpdk-dev] [PATCH v2] doc: update release notes for 20.05

[John McNamara]

Fix grammar, spelling and formatting of DPDK 20.05 release notes.

Signed-off-by: John McNamara 
---

v2: * Addressed comments from mailing list.
* Tried to add a more coherent grouping to the crypto changes.


 doc/guides/rel_notes/release_20_05.rst | 274 -
 1 file changed, 129 insertions(+), 145 deletions(-)

diff --git a/doc/guides/rel_notes/release_20_05.rst 
b/doc/guides/rel_notes/release_20_05.rst
index a61631e..3c6106b 100644
--- a/doc/guides/rel_notes/release_20_05.rst
+++ b/doc/guides/rel_notes/release_20_05.rst
@@ -56,38 +56,38 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
-* **Added Trace Library and Tracepoints**
+* **Added Trace Library and Tracepoints.**
 
-  A native implementation of ``common trace format(CTF)`` based trace library
-  has been added to provide the ability to add tracepoints in
-  application/library to get runtime trace/debug information for control and
-  fast APIs with minimum impact on fast path performance.
-  Typical trace overhead is ~20 cycles and instrumentation overhead is 1 cycle.
-  Added tracepoints in ``EAL``, ``ethdev``, ``cryptodev``, ``eventdev`` and
-  ``mempool`` libraries for important functions.
+  Added a native implementation of the "common trace format" (CTF) based trace
+  library. This allows the user add tracepoints in an application/library to
+  get runtime trace/debug information for control, and fast APIs with minimum
+  impact on fast path performance. Typical trace overhead is ~20 cycles and
+  instrumentation overhead is 1 cycle.  Added tracepoints in ``EAL``,
+  ``ethdev``, ``cryptodev``, ``eventdev`` and ``mempool`` libraries for
+  important functions.
 
-* **Added APIs for RCU defer queue.**
+* **Added APIs for RCU defer queues.**
 
-  Added APIs to create and delete defer queue. Additional APIs are provided
+  Added APIs to create and delete defer queues. Additional APIs are provided
   to enqueue a deleted resource and reclaim the resource in the future.
-  These APIs help the application use lock-free data structures with
+  These APIs help an application use lock-free data structures with
   less effort.
 
 * **Added new API for rte_ring.**
 
-  * New synchronization modes for rte_ring.
+  * Introduced new synchronization modes for ``rte_ring``.
 
-  Introduced new optional MT synchronization modes for rte_ring:
-  Relaxed Tail Sync (RTS) mode and Head/Tail Sync (HTS) mode.
-  With these mode selected, rte_ring shows significant improvements for
-  average enqueue/dequeue times on overcommitted systems.
+Introduced new optional MT synchronization modes for ``rte_ring``:
+Relaxed Tail Sync (RTS) mode and Head/Tail Sync (HTS) mode.
+With these modes selected, ``rte_ring`` shows significant improvements for
+average enqueue/dequeue times on overcommitted systems.
 
-  * Added peek style API for rte_ring.
+  * Added peek style API for ``rte_ring``.
 
-  For rings with producer/consumer in RTE_RING_SYNC_ST, RTE_RING_SYNC_MT_HTS
-  mode, provide an ability to split enqueue/dequeue operation into two phases
-  (enqueue/dequeue start; enqueue/dequeue finish). That allows user to inspect
-  objects in the ring without removing them from it (aka MT safe peek).
+For rings with producer/consumer in ``RTE_RING_SYNC_ST``, 
``RTE_RING_SYNC_MT_HTS``
+mode, provide the ability to split enqueue/dequeue operation into two 
phases
+(enqueue/dequeue start and enqueue/dequeue finish). This allows the user 
to inspect
+objects in the ring without removing them (aka MT safe peek).
 
 * **Added flow aging support.**
 
@@ -100,14 +100,16 @@ New Features
   * Added new query: ``rte_flow_get_aged_flows`` to get the aged-out flows
 contexts from the port.
 
-* **ethdev: Added a new value to link speed for 200Gbps**
+* **ethdev: Added a new value to link speed for 200Gbps.**
 
-* **Updated Amazon ena driver.**
+  Added a new ethdev value to for link speeds of 200Gbps.
 
-  Updated ena PMD with new features and improvements, including:
+* **Updated the Amazon ena driver.**
+
+  Updated the ena PMD with new features and improvements, including:
 
   * Added support for large LLQ (Low-latency queue) headers.
-  * Added Tx drops as new extended driver statistic.
+  * Added Tx drops as a new extended driver statistic.
   * Added support for accelerated LLQ mode.
   * Handling of the 0 length descriptors on the Rx path.
 
@@ -115,14 +117,14 @@ New Features
 
   Updated Hisilicon hns3 driver with new features and improvements, including:
 
-  * Added support for TSO
-  * Added support for configuring promiscuous and allmulticast mode for VF
+  * Added support for TSO.
+  * Added support for configuring promiscuous and allmulticast mode for VF.
 
 * **Updated Intel i40e driver.**
 
   Updated i40e PMD with new features and improvements, including:
 
-  * Enable MAC address as FDIR input set for ipv4-othe

Re: [dpdk-dev] [PATCH v2] doc: update release notes for 20.05

[Mcnamara, John]

> -Original Message-
> From: Mcnamara, John 
> Sent: Monday, May 25, 2020 8:12 PM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; ktray...@redhat.com; Power, Ciara
> ; Trahe, Fiona ; Mcnamara,
> John 
> Subject: [PATCH v2] doc: update release notes for 20.05
> 
> Fix grammar, spelling and formatting of DPDK 20.05 release notes.
> 
> Signed-off-by: John McNamara 
> ---
> 
> v2: * Addressed comments from mailing list.
> * Tried to add a more coherent grouping to the crypto changes.

Sorry. Forgot to thread this.

Re: [dpdk-dev] [dpdk-techboard] Consider improving the DPDKcontribution processes

[Thomas Monjalon]

25/05/2020 20:44, Morten Brørup:
> From: Thomas Monjalon
> > 25/05/2020 18:09, Burakov, Anatoly:
> > > obviously, but i have a suspicion that we'll get more of it if we
> > lower
> > > the barrier for entry (not the barrier for merge!). I think there is
> > a
> > > way to lower the secondary skill level needed to contribute to DPDK
> > > without lowering coding/merge standards with it.
> 
> That is exactly what I am asking for: Lowering the barrier and increasing the 
> feeling of success for newcomers. (The barrier for merge is probably fine; 
> I'll leave that discussion to the maintainers.)

I understand.


> > About the barrier for entry, maybe it is not obvious because I don't
> > communicate a lot about it, but please be aware that I (and other
> > maintainers I think) are doing a lot of changes in newcomer patches
> > to avoid asking them knowing the whole process from the beginning.
> > Then frequent contributors get educated on the way.
> 
> Great! I wish that every developer would think and behave this way.
> 
> > 
> > I think the only real barrier we have is to sign the patch
> > with a real name and send an email to right list.
> > The ask for SoB real name is probably what started this thread
> > in Morten's mind. And the SoB requirement will *never* change.
> 
> The incorrect Signed-off-by might be the only hard barrier (which we cannot 
> avoid). But that did not trigger me.
> 
> I was raising the discussion to bring attention to soft barriers for 
> contributors. What triggered me was the request to split the patch into 
> multiple patches; a kind of feedback I have seen before. For an experienced 
> git user, this is probably very easy, but for a git newbie (like myself), it 
> basically means starting all over and trying to figure out the right set of 
> git commands to do this, which can be perceived as a difficult task requiring 
> a lot of effort.

Yes I am aware about this difficulty.
It is basically knowing git-reset and git-add -p.
I agree a cookbook for this kind of thing is required.

I would like to do the split for newcomers,
but we need also to validate the explanations of each commit.
A solution in such case is to send the split so the newbie can just
fill what is missing.
This kind of workflow is really what we should look at improving.


> Perhaps we could supplement the Contributor Guidelines with a set of 
> cookbooks for different steps in the contribution process, so reviewers can 
> be refer newcomers to the relevant of these as part of the feedback. Just 
> like any professional customer support team has a set of canned answers ready 
> for common customer issues. (Please note: I am not suggesting adding an AI/ML 
> chat bot reviewer to the mailing list!)

OK


> The amount of Contributor Guideline documentation is also a balance... it 
> must be long enough to contain the relevant information to get going, but 
> short enough for newcomers to bother reading it.

Yes, we need short intros and long explanations when really needed.
It is touching another issue: we lack some documentation love.

[dpdk-dev] [PATCH] mbuf: document rule for new fields and flags

[Thomas Monjalon]

Since dynamic fields and flags were added in 19.11,
the idea was to use them for new features, not only PMD-specific.

The rule is made more explicit in doxygen, in the mbuf guide,
and in the contribution design guidelines.

For more information about the original design, see the presentation
https://www.dpdk.org/wp-content/uploads/sites/35/2019/10/DynamicMbuf.pdf

Signed-off-by: Thomas Monjalon 
---
 doc/guides/contributing/design.rst | 13 +
 doc/guides/prog_guide/mbuf_lib.rst | 23 +++
 lib/librte_mbuf/rte_mbuf_core.h|  2 ++
 3 files changed, 38 insertions(+)

diff --git a/doc/guides/contributing/design.rst 
b/doc/guides/contributing/design.rst
index d3dd694b65..508115d5bd 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -57,6 +57,19 @@ The following config options can be used:
 * ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the executive 
environment.
 * ``CONFIG_RTE_EXEC_ENV_FREEBSD`` or ``CONFIG_RTE_EXEC_ENV_LINUX`` are defined 
only if we are building for this execution environment.
 
+Mbuf features
+-
+
+The ``rte_mbuf`` structure must be kept small (128 bytes).
+
+In order to add new features without wasting buffer space for unused features,
+some fields and flags can be registered dynamically in a shared area.
+The "dynamic" mbuf area is the default choice for the new features.
+
+The "dynamic" area is eating the remaining space in mbuf,
+and some existing "static" fields may need to become "dynamic".
+
+
 Library Statistics
 --
 
diff --git a/doc/guides/prog_guide/mbuf_lib.rst 
b/doc/guides/prog_guide/mbuf_lib.rst
index 0d3223b081..c3dbfb9221 100644
--- a/doc/guides/prog_guide/mbuf_lib.rst
+++ b/doc/guides/prog_guide/mbuf_lib.rst
@@ -207,6 +207,29 @@ The list of flags and their precise meaning is described 
in the mbuf API
 documentation (rte_mbuf.h). Also refer to the testpmd source code
 (specifically the csumonly.c file) for details.
 
+Dynamic fields and flags
+
+
+The size of the mbuf is constrained and limited;
+while the amount of metadata to save for each packet is quite unlimited.
+The most basic networking information already find their place
+in the existing mbuf fields and flags.
+
+If new features need to be added, the new fields and flags should fit
+in the "dynamic space", by registering some room in the mbuf structure:
+
+dynamic field
+   named area in the mbuf structure,
+   with a given size (at least 1 byte) and alignment constraint.
+
+dynamic flag
+   named bit in the mbuf structure,
+   stored in the field ``ol_flags``.
+
+The dynamic fields and flags are managed with the functions ``rte_mbuf_dyn*``.
+
+It is not possible to unregister fields or flags.
+
 .. _direct_indirect_buffer:
 
 Direct and Indirect Buffers
diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h
index b9a59c879c..22be41e520 100644
--- a/lib/librte_mbuf/rte_mbuf_core.h
+++ b/lib/librte_mbuf/rte_mbuf_core.h
@@ -12,6 +12,8 @@
  * packet offload flags and some related macros.
  * For majority of DPDK entities, it is not recommended to include
  * this file directly, use include  instead.
+ *
+ * New fields and flags should fit in the "dynamic space".
  */
 
 #include 
-- 
2.26.2

Re: [dpdk-dev] [PATCH] doc: add tested platforms with Broadcom NICs

[Thomas Monjalon]

25/05/2020 16:50, Ajit Khaparde:
> Signed-off-by: Ajit Khaparde 

Applied, thanks

Re: [dpdk-dev] [PATCH v2] doc: update release notes for 20.05

[Thomas Monjalon]

25/05/2020 21:11, John McNamara:
> Fix grammar, spelling and formatting of DPDK 20.05 release notes.
> 
> Signed-off-by: John McNamara 
> ---
> 
> v2: * Addressed comments from mailing list.
> * Tried to add a more coherent grouping to the crypto changes.

Moved bnxt and igc in "more or less" alphabetical order, as it was
already moved by this patch at the end of networking PMDs list.

And applied, thanks.

[dpdk-dev] i40e VXLAN TSO issue

[yang_y_yi]

Hi, folk

I'm trying to enable VXLAN TSO support in OVS DPDK, [1]
is RFC patch, I tested it, it can work in term of functionality, but the
performance is very bad, I don't know why, anybody can help on this? I tested 
it on X710, and tried dpdk 
19.11 and dpdk 19.11.2, the same performance issue is
there.

I have the below questions:

#1. For large TSO packet, it is about 64K, but ret_mbuf
size is MTU of DPDK port, multi-segmented mbuf is necessary, but I checked
GSO code, it seems the attached mbuf includes packet header, anybody can help
confirm external mbuf is ok for Tx on physical dpdk port? It doesn't work per 
my check.

 #2. Can anybody help review code [1] and find out the root cause?

Thank you in advance.

 [1] 
https://patchwork.ozlabs.org/project/openvswitch/patch/20200525090337.110640-1-yang_y...@163.com/
 

Re: [dpdk-dev] [dpdk-stable] [PATCH v2] test-pmd: fix memory leaks when mtr policer actions update fails

[wangyunjian]

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 25, 2020 2:51 PM
> To: wangyunjian 
> Cc: dev@dpdk.org; sta...@dpdk.org; Lilijun (Jerry) ;
> xudingke ; wangyunjian ;
> sta...@dpdk.org; cristian.dumitre...@intel.com
> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] test-pmd: fix memory leaks
> when mtr policer actions update fails
> 
> 25/05/2020 03:46, wangyunjian:
> > From: Yunjian Wang 
> >
> > This patch fixes the Huawei internal coverity reported resource leak
> > issue.
> 
> The problem is not seen in the community Coverity?

I don't know much about that.

> 
> 
> > Fixes: e63b50162aa3 ("app/testpmd: clean metering and policing
> > commands")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Yunjian Wang 
> > ---
> > v2:
> >  * Update commit log
> 
> Please, next time, use --in-reply-to to keep v1 and v2 in the same thread.

OK, thanks.

> 

Re: [dpdk-dev] 【BUG REPORT】l3fwd-power can not exit by ctrl+c

[oulijun]

Hi，
   I have update the code into 20.05-rc2. However， the l3fwd-power 
startup fail.


[root@centos-C3 build]# l3fwd-power -w :7d:00.1  -c 0xc00 -n 4 
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype

EAL: Detected 128 lcore(s)
EAL: Detected 4 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-2048kB
EAL: No available hugepages reported in hugepages-32768kB
EAL: No available hugepages reported in hugepages-64kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL:   using IOMMU type 1 (Type 1)
EAL: Ignore mapping IO port bar(1)
EAL: Ignore mapping IO port bar(3)
EAL: Probe PCI driver: net_hns3 (19e5:a221) device: :7d:00.1 (socket 0)
No telemetry legacy support - No legacy callbacks, legacy socket not created
Promiscuous mode selected
soft parse-ptype is enabled
POWER: Env isn't set yet!
POWER: Attempting to initialise ACPI cpufreq power management...
POWER: Power management governor of lcore 26 has been set to user space 
successfully

POWER: File not opened
POWER: Cannot get available frequencies of lcore 26
POWER: Attempting to initialise PSTAT power management...
POWER: Power management governor of lcore 26 has been set to performance 
successfully

POWER: Error opening '/dev/cpu/26/msr': No such file or directory
POWER: Cannot init for setting frequency for lcore 26
POWER: Attempting to initialise VM power management...
GUEST_CHANNEL: Opening channel 
'/dev/virtio-ports/virtio.serial.port.poweragent.26' for lcore 26
GUEST_CHANNEL: Unable to to connect to 
'/dev/virtio-ports/virtio.serial.port.poweragent.26' with error No such 
file or directory

POWER: Unable to set Power Management Environment for lcore 26
POWER: Library initialization failed on core 26
EAL: Error - exiting with code: 1
  Cause: init_power_library failed

Thanks
Lijun Ou

在 2020/5/22 17:02, Hunt, David 写道:


On 22/5/2020 9:17 AM, oulijun wrote:



在 2020/5/20 15:22, David Marchand 写道:

Hello,

On Wed, May 20, 2020 at 5:18 AM oulijun  wrote:
 I am using 20.05-rc2 version to test based on HNS3 NIC 
hardware, and

found that after starting l3fwd-power,

using ctrl+c cannot force quit. But I revert the patch(33666b4 service:
fix crash on exit) and it is ok.


We had a fix in rc1 that is supposed to fix this.
https://git.dpdk.org/dpdk/commit?id=613ce6691c0d5ac0f99d7995f1e8e4ac86643882 



Copying Anatoly and David H. too.


Hi, David Marchand
   I am only merged the patch(examples/l3fwd-power: implement proper 
shutdown) based on 20.05-rc0 and test. the bug is not resolved.
Can you provide me with complete solution?  I want to understand the 
cause of the whole problem




Hi Lijun,

 The complete solution is to use a version with all of the fixes, as 
Anatoly suggested previously. I have just checked out the latest tip of 
the master branch, and l3fwd-power exits gracefully with a single CTRL-C:



...
Checking link statusdone
Port 0 Link Up - speed 10 Mbps - full-duplex
L3FWD_POWER: entering main loop on lcore 27
L3FWD_POWER:  -- lcoreid=27 portid=0 rxqueueid=0
L3FWD_POWER: lcore 26 has nothing to do
L3FWD_POWER: lcore 27 sleeps until interrupt triggers
*^C*POWER: Power management governor of lcore 26 has been set back to  
successfully
POWER: Power management of lcore 26 has exited from 'performance' mode 
and been set back to the original
POWER: Power management governor of lcore 27 has been set back to 
successfully
POWER: Power management of lcore 27 has exited from 'performance' mode 
and been set back to the original

#


Rgds,
Dave.

[dpdk-dev] xdp_umem_configure(): Failed to create umem

[Deepak Gowda]

Hi All,

I'm fairly new to xdp, i'm trying to run the testpmd with af_xdp. I have
checked all the prerequisites for af_xdp.
I see testpmd exiting with the following error,
./testpmd -c 0x3 -n 4 --vdev net_af_xdp0,iface=tap0 -- -i
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: PCI device :00:03.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 1af4:1000 net_virtio
EAL: PCI device :00:0a.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 1af4:1000 net_virtio
Interactive-mode selected
testpmd: create a new mbuf pool : n=155456, size=2176,
socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port
will pair with itself.

Configuring Port 0 (socket 0)
*xdp_umem_configure(): Failed to create umemeth_rx_queue_setup(): Failed to
configure xdp socket*
Fail to configure port 0 rx queues
EAL: Error - exiting with code: 1
  Cause: Start ports failed

Seems like xsk_umem__create() is failing, could this be a kernel issue?
Before going further i wanted to confirm that my setup is fine and that
there are no obvious mistakes, here is my setup details:
debian buster kvm machine
4.19.0-9-amd64 kernel
iface argument is a tap interface
dpdk-stable-19.11.2

Any insight is appreciated.
Thanks!