[dpdk-dev] FW: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

Hi Olivier,

I submitted the below patch about a month ago, and nothing happened. The patch 
is simple and obvious. Is something wrong with it, or did I not follow the 
submission process correctly?


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
-Original Message-
From: Morten Brørup [mailto:m...@smartsharesystems.com] 
Sent: Friday, April 5, 2019 11:55 AM
To: olivier.m...@6wind.com; tho...@monjalon.net; ferruh.yi...@intel.com; 
arybche...@solarflare.com
Cc: dev@dpdk.org; Morten Brørup
Subject: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in 
rte_eth_ctrl.h

Signed-off-by: Morten Brørup 
---
 app/test-pmd/cmdline.c   |4 ++--
 drivers/net/e1000/igb_ethdev.c   |8 
 lib/librte_ethdev/rte_eth_ctrl.h |8 +---
 lib/librte_net/rte_tcp.h |   13 +
 4 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e45..59a45c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9983,7 +9983,7 @@ cmd_2tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
@@ -10141,7 +10141,7 @@ cmd_5tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b897e8a..c2fe19a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3702,7 +3702,7 @@ ntuple_filter_to_2tuple(struct rte_eth_ntuple_filter 
*filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_port_mask) {
@@ -3782,7 +3782,7 @@ igb_inject_2uple_filter(struct rte_eth_dev *dev,
ttqf &= ~E1000_TTQF_MASK_ENABLE;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
@@ -4188,7 +4188,7 @@ ntuple_filter_to_5tuple_82576(struct 
rte_eth_ntuple_filter *filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_ip_mask) {
@@ -4318,7 +4318,7 @@ igb_inject_5tuple_filter_82576(struct rte_eth_dev *dev,
imir |= filter->filter_info.priority << E1000_IMIR_PRIORITY_SHIFT;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..f21e84b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -184,13 +184,7 @@ struct rte_eth_syn_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)
 
-#define TCP_URG_FLAG 0x20
-#define TCP_ACK_FLAG 0x10
-#define TCP_PSH_FLAG 0x08
-#define TCP_RST_FLAG 0x04
-#define TCP_SYN_FLAG 0x02
-#define TCP_FIN_FLAG 0x01
-#define TCP_FLAG_ALL 0x3F
+#define RTE_NTUPLE_TCP_FLAGS_MASK 0x3F /**< TCP flags filter can match. */
 
 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_net/rte_tcp.h b/lib/librte_net/rte_tcp.h
index 91f5898..2e89b5e 100644
--- a/lib/librte_net/rte_tcp.h
+++ b/lib/librte_net/rte_tcp.h
@@ -2,6 +2,7 @@
  * Copyright(c) 1982, 1986, 1990, 1993
  *  The Regents of the University of California.
  * Copyright(c) 2010-2014 Intel Corporation.
+ * Copyrigh

[dpdk-dev] [PATCH v2] devtools: select patches to check with git range

[David Marchand]

Rather than default to origin/master.., it can be handy to choose the
range you want to check.

Example on a branch rebased on next-net:

Before:
[dmarchan@dmarchan dpdk]$ ./devtools/checkpatches.sh
...
...
67/69 valid patches

After:
[dmarchan@dmarchan dpdk]$ ./devtools/checkpatches.sh -r next-net/master..

3/3 valid patches

Signed-off-by: David Marchand 
Acked-by: Thomas Monjalon 
---
 devtools/checkpatches.sh | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

---
Changelog since v1:
- fixed usage string to reflect the new option is exclusive to other
  options that select patches (tu clair, Thomas)

diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 3272774..6a01b39 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -44,13 +44,14 @@ trap "clean_tmp_files" INT
 
 print_usage () {
cat <<- END_OF_HELP
-   usage: $(basename $0) [-q] [-v] [-nX|patch1 [patch2] ...]]
+   usage: $(basename $0) [-q] [-v] [-nX|-r range|patch1 [patch2] ...]]
 
Run Linux kernel checkpatch.pl with DPDK options.
The environment variable DPDK_CHECKPATCH_PATH must be set.
 
The patches to check can be from stdin, files specified on the command 
line,
-   or latest git commits limited with -n option (default limit: 
origin/master).
+   latest git commits limited with -n option, or commits in the git range
+   specified with -r option (default: "origin/master..").
END_OF_HELP
 }
 
@@ -79,12 +80,14 @@ check_forbidden_additions() { # 
 }
 
 number=0
+range='origin/master..'
 quiet=false
 verbose=false
-while getopts hn:qv ARG ; do
+while getopts hn:qr:v ARG ; do
case $ARG in
n ) number=$OPTARG ;;
q ) quiet=true ;;
+   r ) range=$OPTARG ;;
v ) verbose=true ;;
h ) print_usage ; exit 0 ;;
? ) print_usage ; exit 1 ;;
@@ -172,7 +175,7 @@ elif [ ! -t 0 ] ; then # stdin
check '' '' "$subject"
 else
if [ $number -eq 0 ] ; then
-   commits=$(git rev-list --reverse origin/master..)
+   commits=$(git rev-list --reverse $range)
else
commits=$(git rev-list --reverse --max-count=$number HEAD)
fi
-- 
1.8.3.1

[dpdk-dev] [PATCH v3] eventdev: fix Rx adapter event flush logic

[Nikhil Rao]

The Rx adapter flushes events only if it has BATCH_SIZE
events buffered where BATCH_SIZE is set to 32, e.g., if a
single packet is sent, it is never passed to
eventdev. Fix this issue by adding an event buffer flush
either when a Rx queue is found to be empty or the adapter service
function has processed the max number of packets for an invocation.

Bugzilla ID: 277

Fixes: 6b83f5935543 ("eventdev: add event buffer flush in Rx adapter")

Reported-by: Matias Elo 

CC: sta...@dpdk.org

Signed-off-by: Nikhil Rao 
---
 lib/librte_eventdev/rte_event_eth_rx_adapter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

v2:
* add Bugzilla ID

v3:
* add stable CC
* replace boolean check with check for > 0

diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index 8b6e69d..b60674b 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -872,7 +872,7 @@ static uint16_t rxa_gcd_u16(uint16_t a, uint16_t b)
break;
}
 
-   if (buf->count >= BATCH_SIZE)
+   if (buf->count > 0)
rxa_flush_event_buffer(rx_adapter);
 
return nb_rx;
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH v2] eventdev: fix Rx adapter event flush logic

[Rao, Nikhil]

> -Original Message-
> From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> Sent: Friday, May 10, 2019 12:52 AM
> To: Rao, Nikhil ; jer...@marvell.com
> Cc: dev@dpdk.org; matias@nokia.com
> Subject: Re: [dpdk-dev] [PATCH v2] eventdev: fix Rx adapter event flush logic
> 
> On 2019-05-09 06:50, Nikhil Rao wrote:
> > The Rx adapter flushes events only if it has BATCH_SIZE events
> > buffered where BATCH_SIZE is set to 32, e.g., if a single packet is
> > sent, it is never passed to eventdev. Fix this issue by adding an
> > event buffer flush either when a Rx queue is found to be empty or the
> > adapter service function has processed the max number of packets for
> > an invocation.
> >
> > Bugzilla ID: 277
> >
> > Fixes: 6b83f5935543 ("eventdev: add event buffer flush in Rx adapter")
> >
> > Reported-by: Matias Elo 
> >
> > Signed-off-by: Nikhil Rao 
> > ---
> >   lib/librte_eventdev/rte_event_eth_rx_adapter.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > v2:
> > * added Bugzilla ID
> >
> > diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > index 8d178be..fd3761b 100644
> > --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > @@ -872,7 +872,7 @@ static uint16_t rxa_gcd_u16(uint16_t a, uint16_t b)
> > break;
> > }
> >
> > -   if (buf->count >= BATCH_SIZE)
> > +   if (buf->count)
> > rxa_flush_event_buffer(rx_adapter);
> >
> > return nb_rx;
> >
> 
> After this change, is there any point in having the event_enqueue_buffer
> being a part of the rx_adapter struct? It could be stack allocated. In the
> process, you could eliminate the rte_event copying that goes on and the
> logic around that. Just make mbufs ETH_EVENT_BUFFER_SIZE in size, and
> retry until the NIC queue is empty or you accumulated
> ETH_EVENT_BUFFER_SIZE events. Then you ship it off to the event device.

You are right, I will post a separate (from the bug fix) patch for this.

Thanks,
Nikhil

Re: [dpdk-dev] [PATCH v2] eventdev: fix Rx adapter event flush logic

[Rao, Nikhil]

> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, May 10, 2019 12:48 AM
> To: Rao, Nikhil 
> Cc: dev@dpdk.org; jer...@marvell.com; matias@nokia.com
> Subject: Re: [dpdk-dev] [PATCH v2] eventdev: fix Rx adapter event flush logic
> 
> 09/05/2019 06:50, Nikhil Rao:
> > The Rx adapter flushes events only if it has BATCH_SIZE events
> > buffered where BATCH_SIZE is set to 32, e.g., if a single packet is
> > sent, it is never passed to eventdev. Fix this issue by adding an
> > event buffer flush either when a Rx queue is found to be empty or the
> > adapter service function has processed the max number of packets for
> > an invocation.
> >
> > Bugzilla ID: 277
> >
> > Fixes: 6b83f5935543 ("eventdev: add event buffer flush in Rx adapter")
> >
> > Reported-by: Matias Elo 
> >
> > Signed-off-by: Nikhil Rao 
> > ---
> > --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > @@ -872,7 +872,7 @@ static uint16_t rxa_gcd_u16(uint16_t a, uint16_t b)
> > -   if (buf->count >= BATCH_SIZE)
> > +   if (buf->count)
> 
> I don't this code, but it looks you are removing a test which was probably
> done on purpose.
The previous test (against BATCH_SIZE)  resulted in events permanently sitting
in the buffer if the number of events in the buffer was less than BATCH_SIZE. 

> By the way, you should make your test explicit with "!= 0".
> 
Done.

Thanks,
Nikhil 

[dpdk-dev] [PATCH v2] app/testpmd: remove port stop check for macsec

[Wei Zhao]

There is no need to do such a check when set macsec for ixgbe,
reconfig_device_queueand is also useless. If we do not delete this
unnessary code, users have to sotp port before enable or disable
macsec, then restart this port after make configuration. All these
process is useless. As this cmdline is a private API which is only
used by ixgbe NIC, so remove it.

Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API")
Cc: sta...@dpdk.org

Signed-off-by: Wei Zhao 

---

v2:
-update log info and delete code in disable function
---
 app/test-pmd/cmdline.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index c1042dd..dd0f698 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -14044,10 +14044,6 @@ cmd_set_macsec_offload_on_parsed(
 
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
-   if (!port_is_stopped(port_id)) {
-   printf("Please stop port %d first\n", port_id);
-   return;
-   }
 
rte_eth_dev_info_get(port_id, &dev_info);
if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MACSEC_INSERT) {
@@ -14062,7 +14058,6 @@ cmd_set_macsec_offload_on_parsed(
case 0:
ports[port_id].dev_conf.txmode.offloads |=
DEV_TX_OFFLOAD_MACSEC_INSERT;
-   cmd_reconfig_device_queue(port_id, 1, 1);
break;
case -ENODEV:
printf("invalid port_id %d\n", port_id);
@@ -14138,10 +14133,6 @@ cmd_set_macsec_offload_off_parsed(
 
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
-   if (!port_is_stopped(port_id)) {
-   printf("Please stop port %d first\n", port_id);
-   return;
-   }
 
rte_eth_dev_info_get(port_id, &dev_info);
if (dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MACSEC_INSERT) {
@@ -14153,7 +14144,6 @@ cmd_set_macsec_offload_off_parsed(
case 0:
ports[port_id].dev_conf.txmode.offloads &=
~DEV_TX_OFFLOAD_MACSEC_INSERT;
-   cmd_reconfig_device_queue(port_id, 1, 1);
break;
case -ENODEV:
printf("invalid port_id %d\n", port_id);
-- 
2.7.5

Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API

[Burakov, Anatoly]

On 13-Mar-19 7:21 PM, Hajkowski wrote:

From: Marcin Hajkowski 

Function rte_power_set_env will no longer return
success on attempt to set env in initialized state.

Signed-off-by: Marcin Hajkowski 
---


Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API

[Bruce Richardson]

On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote:
> > > From: Marcin Hajkowski 
> > >
> > > Function rte_power_set_env will no longer return
> > > success on attempt to set env in initialized state.
> > >
> > > Signed-off-by: Marcin Hajkowski 
> > 
> > Acked-by: David Hunt 
> 
> Any other comment about this deprecation notice?
> 
Seems ok to me, though the actual text is maybe a little unclear. It
implies that the function will always return -1 unless the variable is
unset when the function terminates (which seems to imply a failure case).
What I presume is meant is that we have three possibilities:

* The variable is set by the function -> return 0
* The varaible is already set, so no action needed -> return -1 (and set
  rte_errno to EEXIST or EALREADY??)
* Setting the variable failed -> return -1 (and set rte_errno to ??)

Is my understanding correct? Can the deprecation notice be improved to make
it clear that only the middle case is the one being changed, e.g. by adding
"in this case" to the second sentence. It might also be worthwhile calling
out what the errno value will be to identify this failure vs regular
failures.

/Bruce

PS: For this case, is there a reason to make it an error? Would a +1 value
not also do, so anything non-zero implies no work done, and anything >=0
means that the value is set? Call set on something already set doesn't
really seem like an error case to me.

Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config

[Burakov, Anatoly]

On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:

It is planned to make the rte_mem_config struct of the EAL private to
remove it from the visible ABI.  Add a notice to announce the intention.

Signed-off-by: Erik Gabriel Carrillo 
---
changes in v2:
  - Original deprecation notice announced a change to the rte_mem_config
struct that would break ABI.  Update the notice to instead announce
the struct will be made private.  (Stephen, Anatoly, David)

  doc/guides/rel_notes/deprecation.rst | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..a7dff6b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,9 @@ Deprecation Notices
  
  + ``rte_eal_devargs_type_count``
  
+* eal: the ``rte_mem_config`` struct will be made private to remove it from the

+  externally visible ABI and allow it to be updated in the future.
+
  * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions.  The due date for the removal targets DPDK 20.02.



Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API

[Bruce Richardson]

On Fri, May 10, 2019 at 10:28:14AM +0100, Bruce Richardson wrote:
> On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote:
> > > > From: Marcin Hajkowski 
> > > >
> > > > Function rte_power_set_env will no longer return
> > > > success on attempt to set env in initialized state.
> > > >
> > > > Signed-off-by: Marcin Hajkowski 
> > > 
> > > Acked-by: David Hunt 
> > 
> > Any other comment about this deprecation notice?
> > 
> Seems ok to me, though the actual text is maybe a little unclear. It
> implies that the function will always return -1 unless the variable is
> unset when the function terminates (which seems to imply a failure case).
> What I presume is meant is that we have three possibilities:
> 
> * The variable is set by the function -> return 0
> * The varaible is already set, so no action needed -> return -1 (and set
>   rte_errno to EEXIST or EALREADY??)
> * Setting the variable failed -> return -1 (and set rte_errno to ??)
> 
> Is my understanding correct? Can the deprecation notice be improved to make
> it clear that only the middle case is the one being changed, e.g. by adding
> "in this case" to the second sentence. It might also be worthwhile calling
> out what the errno value will be to identify this failure vs regular
> failures.
> 
> /Bruce
> 
> PS: For this case, is there a reason to make it an error? Would a +1 value
> not also do, so anything non-zero implies no work done, and anything >=0
> means that the value is set? Call set on something already set doesn't
> really seem like an error case to me.

Sorry, forgot to put:

For changing the ABI itself, no issues, so with the small rewording asked
for, please add my ack.

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config

[Bruce Richardson]

On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:
> > It is planned to make the rte_mem_config struct of the EAL private to
> > remove it from the visible ABI.  Add a notice to announce the intention.
> > 
> > Signed-off-by: Erik Gabriel Carrillo 
> > ---
> > changes in v2:
> >   - Original deprecation notice announced a change to the rte_mem_config
> > struct that would break ABI.  Update the notice to instead announce
> > the struct will be made private.  (Stephen, Anatoly, David)
> > 
> >   doc/guides/rel_notes/deprecation.rst | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/doc/guides/rel_notes/deprecation.rst 
> > b/doc/guides/rel_notes/deprecation.rst
> > index b47c8c2..a7dff6b 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,9 @@ Deprecation Notices
> >   + ``rte_eal_devargs_type_count``
> > +* eal: the ``rte_mem_config`` struct will be made private to remove it 
> > from the
> > +  externally visible ABI and allow it to be updated in the future.
> > +
> >   * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs 
> > which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions.  The due date for the removal targets DPDK 20.02.
> > 
> 
> Acked-by: Anatoly Burakov 
> 
Acked-by: Bruce Richardson 

Re: [dpdk-dev] FW: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Ferruh Yigit]

On 5/10/2019 8:01 AM, Morten Brørup wrote:
> Hi Olivier,
> 
> I submitted the below patch about a month ago, and nothing happened. The 
> patch is simple and obvious. Is something wrong with it, or did I not follow 
> the submission process correctly?

Hi Morten,

I don't see this mail in mail list (and list archive), or in my inbox (it looks
like I am in cc in original mail).

Something may be went wrong in your side while sending, can you please send the
patch again?

> 
> 
> 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
> -Original Message-
> From: Morten Brørup [mailto:m...@smartsharesystems.com] 
> Sent: Friday, April 5, 2019 11:55 AM
> To: olivier.m...@6wind.com; tho...@monjalon.net; ferruh.yi...@intel.com; 
> arybche...@solarflare.com
> Cc: dev@dpdk.org; Morten Brørup
> Subject: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in 
> rte_eth_ctrl.h
> 
> Signed-off-by: Morten Brørup 

<...>

Re: [dpdk-dev] [PATCH] event/dsw: ignore scheduling type for single-link queues

[Mattias Rönnblom]

On 2019-05-10 11:47, Mattias Rönnblom wrote:

The scheduling type parameter is not applicable for single link
queues. DSW would, at the time of rte_event_queue_setup(), erroneously
verify that scheduling type was one of the supported types, and
returned -ENOTSUP in case of RTE_SCHED_TYPE_ORDERED.

Signed-off-by: Mattias Rönnblom 


Adding sta...@dpdk.org.

[dpdk-dev] [PATCH] event/dsw: ignore scheduling type for single-link queues

[Mattias Rönnblom]

The scheduling type parameter is not applicable for single link
queues. DSW would, at the time of rte_event_queue_setup(), erroneously
verify that scheduling type was one of the supported types, and
returned -ENOTSUP in case of RTE_SCHED_TYPE_ORDERED.

Signed-off-by: Mattias Rönnblom 
---
 drivers/event/dsw/dsw_evdev.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index 4157d130c..9387d4149 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -102,9 +102,6 @@ dsw_queue_setup(struct rte_eventdev *dev, uint8_t queue_id,
if (RTE_EVENT_QUEUE_CFG_ALL_TYPES & conf->event_queue_cfg)
return -ENOTSUP;
 
-   if (conf->schedule_type == RTE_SCHED_TYPE_ORDERED)
-   return -ENOTSUP;
-
/* SINGLE_LINK is better off treated as TYPE_ATOMIC, since it
 * avoid the "fake" TYPE_PARALLEL flow_id assignment. Since
 * the queue will only have a single serving port, no
@@ -113,8 +110,12 @@ dsw_queue_setup(struct rte_eventdev *dev, uint8_t queue_id,
 */
if (RTE_EVENT_QUEUE_CFG_SINGLE_LINK & conf->event_queue_cfg)
queue->schedule_type = RTE_SCHED_TYPE_ATOMIC;
-   else /* atomic or parallel */
+   else {
+   if (conf->schedule_type == RTE_SCHED_TYPE_ORDERED)
+   return -ENOTSUP;
+   /* atomic or parallel */
queue->schedule_type = conf->schedule_type;
+   }
 
queue->num_serving_ports = 0;
 
-- 
2.17.1

Re: [dpdk-dev] [PATCH] event/dsw: ignore scheduling type for single-link queues

[Kevin Traynor]

On 10/05/2019 10:53, Mattias Rönnblom wrote:
> On 2019-05-10 11:47, Mattias Rönnblom wrote:
>> The scheduling type parameter is not applicable for single link
>> queues. DSW would, at the time of rte_event_queue_setup(), erroneously
>> verify that scheduling type was one of the supported types, and
>> returned -ENOTSUP in case of RTE_SCHED_TYPE_ORDERED.
>>
>> Signed-off-by: Mattias Rönnblom 
> 
> Adding sta...@dpdk.org.
> 

Please add it and a Fixes tag in the commit msg, so it won't be missed
later, thanks.
http://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-be-backported

Re: [dpdk-dev] [PATCH 18.11] eal: fix cleanup in no-shconf mode

[Burakov, Anatoly]

On 09-May-19 7:16 PM, Kevin Traynor wrote:

On 09/05/2019 18:50, Ferruh Yigit wrote:

On 5/9/2019 6:50 PM, Ferruh Yigit wrote:

On 4/24/2019 4:26 PM, Anatoly Burakov wrote:

In no-shconf mode, there is no need to clean runtime directory
because it's not created in the first place.

Fixes: 0a529578f162 ("eal: clean up unused files on initialization")

Signed-off-by: Anatoly Burakov 


Is this for 18.11.x LTS?
cc'ed the stable mail list assuming that is the case.


+Kevin



Is this valid for 19.05 too?



It's already applied on 18.11 branch. The same change is also in master
courtesy of the referenced upstream commit below, so this one not needed
for master. Thanks for checking.

commit 4c1ef6dff7230f08f90427355741f56d2faf5884
Author: Anatoly Burakov 
Date:   Wed Apr 24 16:26:10 2019 +0100

 eal: fix cleanup in no-shconf mode

 [ upstream commit 307315d4577462943d0fcb2e6b8c8f35f90698d7 ]



Yes, this was already applied at master. It was rolled into another fix, 
which i admittedly shouldn't have done, i don't know what i was 
thinking. This is only for 18.11 stable.


--
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when port is being removed

[wangyunjian]

> -Original Message-
> From: Zhao1, Wei [mailto:wei.zh...@intel.com]
> Sent: Friday, May 10, 2019 11:14 AM
> To: wangyunjian ; dev@dpdk.org
> Cc: i.maxim...@samsung.com; xudingke ;
> sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when port
> is being removed
> 
> Hi,  wangyunjian
> 
>   May I ask some more info about it?
> Sure, we may this handler in ixgbe_dev_link_update_share (),  but we have
> "rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, dev)"
> in function ixgbe_dev_stop() and ixgbevf_dev_stop() to  cancel this handler.
> If you want to remove dev, you will call ixgbe_dev_stop() first, RIGHT?
> Maybe there is an accidental situation that some interrupt like LSC trigger
> ixgbe_dev_link_update() to set setup_link_alarm_handler just after dev stop?
> Then we need to cancel it in eth_ixgbe_dev_uninit().
> Is you issue the same as above or other?

Yes,  it is as above. It is easy to reproduce through fault injection. As 
follow:

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 975fa47..a1e93c0 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4055,7 +4055,7 @@ static int ixgbevf_dev_xstats_get_names(__rte_unused 
struct rte_eth_dev *dev,
if (link_up == 0) {
if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
-   rte_eal_alarm_set(10,
+   rte_eal_alarm_set(500 * 1000,
ixgbe_dev_setup_link_alarm_handler, dev);
}
return rte_eth_linkstatus_set(dev, &link);

> 
> 
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of wangyunjian
> > Sent: Wednesday, May 8, 2019 8:52 PM
> > To: dev@dpdk.org
> > Cc: i.maxim...@samsung.com; xudin...@huawei.com; Yunjian Wang
> > ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] net/ixgbe: fix cancel link handler when
> > port is being removed
> >
> > From: Yunjian Wang 
> >
> > The nic's interrupt source has some active handler, which maybe call
> > ixgbe_dev_link_update() to set link handler. We should cancel the link
> > handler before remove dev to prevent executing the link handler.
> > It triggers segfault.
> >
> > Fixes: 0408f47ba4d6 ("net/ixgbe: fix busy polling while fiber link
> > update")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Yunjian Wang 
> > ---
> >  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 975fa47..2470c89 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -1344,6 +1344,9 @@ struct rte_ixgbe_xstats_name_off {
> > /* cancel the delay handler before remove dev */
> > rte_eal_alarm_cancel(ixgbe_dev_interrupt_delayed_handler,
> eth_dev);
> >
> > +   /* cancel the link handler before remove dev */
> > +   rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler,
> eth_dev);
> > +
> > /* uninitialize PF if max_vfs not zero */
> > ixgbe_pf_host_uninit(eth_dev);
> >
> > --
> > 1.8.3.1
> >

[dpdk-dev] [PATCH v2] event/dsw: ignore scheduling type for single-link queues

[Mattias Rönnblom]

The scheduling type parameter is not applicable for single link
queues. DSW would, at the time of rte_event_queue_setup(), erroneously
verify that scheduling type was one of the supported types, and
returned -ENOTSUP in case of RTE_SCHED_TYPE_ORDERED.

Fixes: 4540ee9c68 ("event/dsw: add device and queue configuration")
Cc: sta...@dpdk.org

Signed-off-by: Mattias Rönnblom 
---
 drivers/event/dsw/dsw_evdev.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/event/dsw/dsw_evdev.c b/drivers/event/dsw/dsw_evdev.c
index 4157d130c..9387d4149 100644
--- a/drivers/event/dsw/dsw_evdev.c
+++ b/drivers/event/dsw/dsw_evdev.c
@@ -102,9 +102,6 @@ dsw_queue_setup(struct rte_eventdev *dev, uint8_t queue_id,
if (RTE_EVENT_QUEUE_CFG_ALL_TYPES & conf->event_queue_cfg)
return -ENOTSUP;
 
-   if (conf->schedule_type == RTE_SCHED_TYPE_ORDERED)
-   return -ENOTSUP;
-
/* SINGLE_LINK is better off treated as TYPE_ATOMIC, since it
 * avoid the "fake" TYPE_PARALLEL flow_id assignment. Since
 * the queue will only have a single serving port, no
@@ -113,8 +110,12 @@ dsw_queue_setup(struct rte_eventdev *dev, uint8_t queue_id,
 */
if (RTE_EVENT_QUEUE_CFG_SINGLE_LINK & conf->event_queue_cfg)
queue->schedule_type = RTE_SCHED_TYPE_ATOMIC;
-   else /* atomic or parallel */
+   else {
+   if (conf->schedule_type == RTE_SCHED_TYPE_ORDERED)
+   return -ENOTSUP;
+   /* atomic or parallel */
queue->schedule_type = conf->schedule_type;
+   }
 
queue->num_serving_ports = 0;
 
-- 
2.17.1

[dpdk-dev] Discussion on the OS Packaging of DPDK

[Ray Kinsella]

( from the undersigned )

Hi folks,

In light of the renewed community discussion on API Stability
(https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
right time to open a discussion on how DPDK is distributed and updated.

To this point in time, DPDK's primary distribution method has been as
source code distributed as a tarball from dpdk.org. This distribution
method, in addition to abi instability and the dpdk's build system
default behaviour of static linking have all encouraged the "tight
coupling" or "vendorization" of DPDK.

These behaviours makes it a challenge for end users, those deploying
applications based on DPDK, to manage and update DPDK in a method
consistent with other system libraries. For instance, an end user may
not have any idea which version of DPDK a consuming application may be
using and if this DPDK version is reasonably up to date with the latest
upstream version. This would not be the case for other system libraries
such as glibc.

For these reasons, now is the right time for DPDK to embrace standard
Operating System practices for distributing and updating system
libraries. The current industry push towards cloud and
cloud-friendliness make addressing this issue all the more timely.

To this end, the following proposals are made for discussion at the next
techboard meeting:-

* The primary method of distributing DPDK should be as an operating
system package, dpdk.org should be updated to reflect this reality and
provide OS installation details in place of tarball downloads.

* DPDK should build as a dynamic shared libraries by default, to
encourage loose coupling with consuming applications.

* Future guarantees around ABI/API stability should be provided, so that
OS packagers can offer safe upgrade paths for consuming applications.

Look forward to the discussion, thank you,

Luca Boccassi, Debian maintainer and DPDK LTS maintainer
Nirmoy Das, SUSE dpdk maintainer
Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
Ian Stokes, Open vSwitch maintainer
Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
Billy McFall, DPDK consumer and FD.io/VPP Contributor
Ray Kinsella, DPDK and FD.io Contributor

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] eventdev: fix Rx adapter event flush logic

[Thomas Monjalon]

Any review please?

10/05/2019 10:08, Nikhil Rao:
> The Rx adapter flushes events only if it has BATCH_SIZE
> events buffered where BATCH_SIZE is set to 32, e.g., if a
> single packet is sent, it is never passed to
> eventdev. Fix this issue by adding an event buffer flush
> either when a Rx queue is found to be empty or the adapter service
> function has processed the max number of packets for an invocation.
> 
> Bugzilla ID: 277
> 
> Fixes: 6b83f5935543 ("eventdev: add event buffer flush in Rx adapter")
> 
> Reported-by: Matias Elo 
> 
> CC: sta...@dpdk.org
> 
> Signed-off-by: Nikhil Rao 
> ---
>  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> v2:
> * add Bugzilla ID
> 
> v3:
> * add stable CC
> * replace boolean check with check for > 0
> 
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c 
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index 8b6e69d..b60674b 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -872,7 +872,7 @@ static uint16_t rxa_gcd_u16(uint16_t a, uint16_t b)
>   break;
>   }
>  
> - if (buf->count >= BATCH_SIZE)
> + if (buf->count > 0)
>   rxa_flush_event_buffer(rx_adapter);
>  
>   return nb_rx;
> 

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Bruce Richardson]

On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> ( from the undersigned )
> 
> Hi folks,
> 
> In light of the renewed community discussion on API Stability
> (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> right time to open a discussion on how DPDK is distributed and updated.
> 
> To this point in time, DPDK's primary distribution method has been as
> source code distributed as a tarball from dpdk.org. This distribution
> method, in addition to abi instability and the dpdk's build system
> default behaviour of static linking have all encouraged the "tight
> coupling" or "vendorization" of DPDK.
> 
> These behaviours makes it a challenge for end users, those deploying
> applications based on DPDK, to manage and update DPDK in a method
> consistent with other system libraries. For instance, an end user may
> not have any idea which version of DPDK a consuming application may be
> using and if this DPDK version is reasonably up to date with the latest
> upstream version. This would not be the case for other system libraries
> such as glibc.
> 
> For these reasons, now is the right time for DPDK to embrace standard
> Operating System practices for distributing and updating system
> libraries. The current industry push towards cloud and
> cloud-friendliness make addressing this issue all the more timely.
> 
> To this end, the following proposals are made for discussion at the next
> techboard meeting:-
> 
> * The primary method of distributing DPDK should be as an operating
> system package, dpdk.org should be updated to reflect this reality and
> provide OS installation details in place of tarball downloads.

I really like that idea. Since DPDK is available in distro packages that
should be the first port of call for users getting DPDK. Since it's just a
doc update - as I understand it anyway - it should be easy to implement if
agreed, which is a nice bonus.

> 
> * DPDK should build as a dynamic shared libraries by default, to
> encourage loose coupling with consuming applications.
> 

To a certain extent, this only applies with the "make" build system, which
is due to be deprecated in the next release and removed sometime next year.
With builds done with meson and ninja, both shared and static libraries are
always built. The default setting though remains as "static" which applies
only to the linking of applications as part of the DPDK build. This default
was set mainly for legacy purposes, but also has benefits for us developers
working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
and EAL_PMD_PATH values for running applications we've built. Therefore,
I'm not sure of the value of changing the default here - it's certainly
less important than the default in the "make" build system where only one
library type at a time was built.

> * Future guarantees around ABI/API stability should be provided, so that
> OS packagers can offer safe upgrade paths for consuming applications.
> 
> Look forward to the discussion, thank you,
> 
> Luca Boccassi, Debian maintainer and DPDK LTS maintainer
> Nirmoy Das, SUSE dpdk maintainer
> Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
> Ian Stokes, Open vSwitch maintainer
> Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
> Billy McFall, DPDK consumer and FD.io/VPP Contributor
> Ray Kinsella, DPDK and FD.io Contributor

Thanks all for kicking off this discussion.

/Bruce

Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config

[David Marchand]

On Thu, May 9, 2019 at 8:53 PM Erik Gabriel Carrillo <
erik.g.carri...@intel.com> wrote:

> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI.  Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo 
> ---
> changes in v2:
>  - Original deprecation notice announced a change to the rte_mem_config
>struct that would break ABI.  Update the notice to instead announce
>the struct will be made private.  (Stephen, Anatoly, David)
>
>  doc/guides/rel_notes/deprecation.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
>  + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it
> from the
> +  externally visible ABI and allow it to be updated in the future.
> +
>  * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
>have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
>functions.  The due date for the removal targets DPDK 20.02.
> --
> 2.6.4
>
>
I had a look at the current callers, trying to see what "hiding" means.

$ git grep -Elw '(rte_mem_config|mem_config)' origin/master --
origin/master:app/test/test_memzone.c
origin/master:doc/guides/rel_notes/release_18_11.rst
origin/master:drivers/bus/fslmc/fslmc_vfio.c
origin/master:drivers/net/ena/ena_ethdev.c
origin/master:drivers/net/mlx4/mlx4_mr.c
origin/master:drivers/net/mlx5/mlx5_mr.c
origin/master:drivers/net/virtio/virtio_user/virtio_user_dev.c
origin/master:lib/librte_eal/common/eal_common_memory.c
origin/master:lib/librte_eal/common/eal_common_memzone.c
origin/master:lib/librte_eal/common/eal_common_tailqs.c
origin/master:lib/librte_eal/common/include/rte_eal.h
origin/master:lib/librte_eal/common/include/rte_eal_memconfig.h
origin/master:lib/librte_eal/common/malloc_heap.c
origin/master:lib/librte_eal/common/rte_malloc.c
origin/master:lib/librte_eal/freebsd/eal/eal.c
origin/master:lib/librte_eal/freebsd/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal.c
origin/master:lib/librte_eal/linux/eal/eal_memalloc.c
origin/master:lib/librte_eal/linux/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal_vfio.c

- I understand that the following drivers will need a new lock/unlock api
to protect calls to the memory api.
drivers/bus/fslmc/fslmc_vfio.c
drivers/net/mlx4/mlx4_mr.c
drivers/net/mlx5/mlx5_mr.c
drivers/net/virtio/virtio_user/virtio_user_dev.c

- I have a little trouble with this one, so there might be a new api for
this driver usecase.
A discussion will have to happen with its maintainers (added in CC:).
drivers/net/ena/ena_ethdev.c


Apart from this, I am ok with the objective, which is to hide one more eal
internal structure.

Acked-by: David Marchand 


-- 
David Marchand

Re: [dpdk-dev] [PATCH v2] devtools: select patches to check with git range

[Thomas Monjalon]

10/05/2019 09:49, David Marchand:
> Rather than default to origin/master.., it can be handy to choose the
> range you want to check.
> 
> Example on a branch rebased on next-net:
> 
> Before:
> [dmarchan@dmarchan dpdk]$ ./devtools/checkpatches.sh
> ...
> ...
> 67/69 valid patches
> 
> After:
> [dmarchan@dmarchan dpdk]$ ./devtools/checkpatches.sh -r next-net/master..
> 
> 3/3 valid patches
> 
> Signed-off-by: David Marchand 
> Acked-by: Thomas Monjalon 

Applied, thanks

Re: [dpdk-dev] FW: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

Hi Ferruh,

Thanks for the detailed feedback. There seems to be a problem with my mail 
configuration on our development server. I will fix and send again.

Sorry about the inconvenience.


Med venlig hilsen / kind regards
- Morten Brørup

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, May 10, 2019 11:41 AM
> To: Morten Brørup; Olivier Matz
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] FW: [PATCH] librte_net: define TCP flags in
> rte_tcp.h instead of in rte_eth_ctrl.h
> 
> On 5/10/2019 8:01 AM, Morten Brørup wrote:
> > Hi Olivier,
> >
> > I submitted the below patch about a month ago, and nothing happened.
> The patch is simple and obvious. Is something wrong with it, or did I
> not follow the submission process correctly?
> 
> Hi Morten,
> 
> I don't see this mail in mail list (and list archive), or in my inbox
> (it looks
> like I am in cc in original mail).
> 
> Something may be went wrong in your side while sending, can you please
> send the
> patch again?
> 
> >
> >
> > 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
> > -Original Message-
> > From: Morten Brørup [mailto:m...@smartsharesystems.com]
> > Sent: Friday, April 5, 2019 11:55 AM
> > To: olivier.m...@6wind.com; tho...@monjalon.net;
> ferruh.yi...@intel.com; arybche...@solarflare.com
> > Cc: dev@dpdk.org; Morten Brørup
> > Subject: [PATCH] librte_net: define TCP flags in rte_tcp.h instead of
> in rte_eth_ctrl.h
> >
> > Signed-off-by: Morten Brørup 
> 
> <...>
> 

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

[John McNamara]

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

Signed-off-by: John McNamara 
---
 doc/guides/rel_notes/release_19_05.rst | 147 -
 1 file changed, 70 insertions(+), 77 deletions(-)

diff --git a/doc/guides/rel_notes/release_19_05.rst 
b/doc/guides/rel_notes/release_19_05.rst
index 4e0eed5..fa213b5 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,24 +54,27 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
-* **Added new armv8 machine targets:**
+* **Added new armv8 machine targets.**
+
+  Added new armv8 machine targets:
 
   * BlueField (Mellanox)
   * OcteonTX2 (Marvell)
   * ThunderX2 (Marvell)
 
-* **Introduced Windows Support.**
+* **Added Windows Support.**
 
   Added Windows support to build Hello World sample application.
 
-* **Added Stack API.**
+* **Added Stack Library.**
 
-  Added a new stack API for configuration and use of a bounded stack of
-  pointers. The API provides MT-safe push and pop operations that can operate
-  on one or more pointers per operation.
+  Added a new stack library and APIs for configuration and use of a bounded
+  stack of pointers. The API provides multi-thread safe push and pop
+  operations that can operate on one or more pointers per operation.
 
-  The library supports two stack implementations: standard (lock-based) and 
lock-free.
-  The lock-free implementation is currently limited to x86-64 platforms.
+  The library supports two stack implementations: standard (lock-based) and
+  lock-free.  The lock-free implementation is currently limited to x86-64
+  platforms.
 
 * **Added Lock-Free Stack Mempool Handler.**
 
@@ -80,24 +83,24 @@ New Features
 
 * **Added RCU library.**
 
-  Added RCU library supporting quiescent state based memory reclamation method.
+  Added RCU library supporting a quiescent state based memory reclamation 
method.
   This library helps identify the quiescent state of the reader threads so
   that the writers can free the memory associated with the lock free data
   structures.
 
 * **Updated KNI module and PMD.**
 
-  Updated the KNI kernel module to set the max_mtu according to the given
+  Updated the KNI kernel module to set the ``max_mtu`` according to the given
   initial MTU size. Without it, the maximum MTU was 1500.
 
-  Updated the KNI PMD driver to set the mbuf_size and MTU based on
+  Updated the KNI PMD driver to set the ``mbuf_size`` and MTU based on
   the given mb-pool. This provide the ability to pass jumbo frames
-  if the mb-pool contains suitable buffers' size.
+  if the mb-pool contains a suitable buffer size.
 
 * **Added the AF_XDP PMD.**
 
-  Added a Linux-specific PMD driver for AF_XDP, it can create the AF_XDP socket
-  and bind it to a specific netdev queue, it allows a DPDK application to send
+  Added a Linux-specific PMD driver for AF_XDP. This PMD can create an AF_XDP 
socket
+  and bind it to a specific netdev queue. It allows a DPDK application to send
   and receive raw packets through the socket which would bypass the kernel
   network stack to achieve high performance packet processing.
 
@@ -108,21 +111,21 @@ New Features
 
 * **Added IPN3KE net PMD.**
 
-  Added the new ``ipn3ke`` net driver for Intel® FPGA PAC(Programmable
+  Added the new ``ipn3ke`` net driver for the Intel® FPGA PAC (Programmable
   Acceleration Card) N3000. See the :doc:`../nics/ipn3ke` NIC guide for more
   details on this new driver.
 
-  Aside from this, ifpga_rawdev is also updated to support Intel® FPGA PAC
-  N3000 with SPI interface access, I2C Read/Write and Ethernet PHY 
configuration.
+  In addition ``ifpga_rawdev`` was also updated to support Intel® FPGA PAC
+  N3000 with SPI interface access, I2C Read/Write, and Ethernet PHY 
configuration.
 
 * **Updated Solarflare network PMD.**
 
-  Updated the sfc_efx driver including the following changes:
+  Updated the Solarflare ``sfc_efx`` driver with changes including:
 
   * Added support for Rx descriptor status and related API in a secondary
 process.
   * Added support for Tx descriptor status API in a secondary process.
-  * Added support for RSS RETA and hash configuration get API in a secondary
+  * Added support for RSS RETA and hash configuration API in a secondary
 process.
   * Added support for Rx packet types list in a secondary process.
   * Added Tx prepare to do Tx offloads checks.
@@ -130,27 +133,27 @@ New Features
 
 * **Updated Mellanox mlx4 driver.**
 
-   New features and improvements were done:
+   Updated Mellanox mlx4 driver with new features and improvements, including:
 
* Added firmware version reading.
-   * Added support for secondary process.
-   * Added support of per-process device registers, reserving identical VA 
space
- is not needed anymore.
-   * Added support for multicast address list interface
+   * Added support for secon

[dpdk-dev] [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

Signed-off-by: Morten Brørup 
---
 app/test-pmd/cmdline.c   |4 ++--
 drivers/net/e1000/igb_ethdev.c   |8 
 lib/librte_ethdev/rte_eth_ctrl.h |8 +---
 lib/librte_net/rte_tcp.h |   13 +
 4 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e45..59a45c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9983,7 +9983,7 @@ cmd_2tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
@@ -10141,7 +10141,7 @@ cmd_5tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b897e8a..c2fe19a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3702,7 +3702,7 @@ ntuple_filter_to_2tuple(struct rte_eth_ntuple_filter 
*filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_port_mask) {
@@ -3782,7 +3782,7 @@ igb_inject_2uple_filter(struct rte_eth_dev *dev,
ttqf &= ~E1000_TTQF_MASK_ENABLE;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
@@ -4188,7 +4188,7 @@ ntuple_filter_to_5tuple_82576(struct 
rte_eth_ntuple_filter *filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_ip_mask) {
@@ -4318,7 +4318,7 @@ igb_inject_5tuple_filter_82576(struct rte_eth_dev *dev,
imir |= filter->filter_info.priority << E1000_IMIR_PRIORITY_SHIFT;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..f21e84b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -184,13 +184,7 @@ struct rte_eth_syn_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)
 
-#define TCP_URG_FLAG 0x20
-#define TCP_ACK_FLAG 0x10
-#define TCP_PSH_FLAG 0x08
-#define TCP_RST_FLAG 0x04
-#define TCP_SYN_FLAG 0x02
-#define TCP_FIN_FLAG 0x01
-#define TCP_FLAG_ALL 0x3F
+#define RTE_NTUPLE_TCP_FLAGS_MASK 0x3F /**< TCP flags filter can match. */
 
 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_net/rte_tcp.h b/lib/librte_net/rte_tcp.h
index 91f5898..2e89b5e 100644
--- a/lib/librte_net/rte_tcp.h
+++ b/lib/librte_net/rte_tcp.h
@@ -2,6 +2,7 @@
  * Copyright(c) 1982, 1986, 1990, 1993
  *  The Regents of the University of California.
  * Copyright(c) 2010-2014 Intel Corporation.
+ * Copyright(c) 2019 SmartShare Systems.
  * All rights reserved.
  */
 
@@ -35,6 +36,18 @@ struct tcp_hdr {
uint16_t tcp_urp;   /**< TCP urgent pointer, if any. */
 } __attribute__((__packed__));
 
+/**
+ * TCP Flags
+ */
+#define TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
+#define TCP_ECE_FLAG 0x40 /**< ECN-Echo */
+#define TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
+#define TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant */
+#define TCP_PSH_FLAG 0x08 /**< Push Function */
+#define TCP_RST_FLAG 0x04 /**< Reset the connection */
+#define TCP_SYN_FLAG 0x02 /**< Synchronize sequence numbers */
+#define TCP_FIN_FLAG 0x01 /**< No more data from sender */
+
 #ifdef __cplusplus
 }
 #endif
-- 
1.5.6

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

[Andrew Rybchenko]

On 5/10/19 5:18 PM, John McNamara wrote:

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

Signed-off-by: John McNamara 


[snip]


  * **Updated Solarflare network PMD.**
  
-  Updated the sfc_efx driver including the following changes:

+  Updated the Solarflare ``sfc_efx`` driver with changes including:
  
* Added support for Rx descriptor status and related API in a secondary

  process.
* Added support for Tx descriptor status API in a secondary process.
-  * Added support for RSS RETA and hash configuration get API in a secondary
+  * Added support for RSS RETA and hash configuration API in a secondary


I've tried to highlight that secondary process can read (get) RETA table 
and hash

configuration, but cannot change it (update).


  process.
* Added support for Rx packet types list in a secondary process.
* Added Tx prepare to do Tx offloads checks.


[snip]

Thanks,
Andrew.

[dpdk-dev] [PATCH] net/mlx5: fix device removal handler for multiport device

[Viacheslav Ovsiienko]

IBV_EVENT_DEVICE_FATAL event is generated by the driver once for
the entire multiport Infiniband device, not for each existing ports.
The port index is zero and it causes dropping the device removal
event. We should invoke the removal event processing routine
for each port we have installed handler for.

Fixes: 028b2a28c3cb ("net/mlx5: update event handler for multiport IB devices")

Signed-off-by: Viacheslav Ovsiienko 
---
 drivers/net/mlx5/mlx5_ethdev.c | 43 +-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 80ee98f..3962d41 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1116,6 +1116,35 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
 }
 
 /**
+ * Handle asynchronous removal event for entire multiport device.
+ *
+ * @param sh
+ *   Infiniband device shared context.
+ */
+static void
+mlx5_dev_interrupt_device_fatal(struct mlx5_ibv_shared *sh)
+{
+   uint32_t i;
+
+   for (i = 0; i < sh->max_port; ++i) {
+   struct rte_eth_dev *dev;
+
+   if (sh->port[i].ih_port_id >= RTE_MAX_ETHPORTS) {
+   /*
+* Or not existing port either no
+* handler installed for this port.
+*/
+   continue;
+   }
+   dev = &rte_eth_devices[sh->port[i].ih_port_id];
+   assert(dev);
+   if (dev->data->dev_conf.intr_conf.rmv)
+   _rte_eth_dev_callback_process
+   (dev, RTE_ETH_EVENT_INTR_RMV, NULL);
+   }
+}
+
+/**
  * Handle shared asynchronous events the NIC (removal event
  * and link status change). Supports multiport IB device.
  *
@@ -1137,6 +1166,16 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
break;
/* Retrieve and check IB port index. */
tmp = (uint32_t)event.element.port_num;
+   if (!tmp && event.event_type == IBV_EVENT_DEVICE_FATAL) {
+   /*
+* The DEVICE_FATAL event is called once for
+* entire device without port specifying.
+* We should notify all existing ports.
+*/
+   mlx5_glue->ack_async_event(&event);
+   mlx5_dev_interrupt_device_fatal(sh);
+   continue;
+   }
assert(tmp && (tmp <= sh->max_port));
if (!tmp ||
tmp > sh->max_port ||
@@ -1146,12 +1185,14 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
*fw_ver, size_t fw_size)
 * installed for this port.
 */
mlx5_glue->ack_async_event(&event);
+   DRV_LOG(DEBUG,
+   "port %u event type %d on not handled",
+   tmp, event.event_type);
continue;
}
/* Retrieve ethernet device descriptor. */
tmp = sh->port[tmp - 1].ih_port_id;
dev = &rte_eth_devices[tmp];
-   tmp = 0;
assert(dev);
if ((event.event_type == IBV_EVENT_PORT_ACTIVE ||
 event.event_type == IBV_EVENT_PORT_ERR) &&
-- 
1.8.3.1

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly"  wrote:

> On 09-May-19 10:50 AM, Ray Kinsella wrote:
> > 
> > 
> > On 09/05/2019 10:38, Thomas Monjalon wrote:  
> >> 09/05/2019 11:37, Burakov, Anatoly:  
> >>> On 09-May-19 10:06 AM, Bruce Richardson wrote:  
>  On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:  
> > On 09-May-19 8:05 AM, David Marchand wrote:  
> >> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >> mailto:step...@networkplumber.org>> wrote:
> >>
> >>   On Wed,  8 May 2019 17:48:06 -0500
> >>   Erik Gabriel Carrillo  >>   > wrote:
> >>  
> >>> Due to an upcoming fix to allow the timer library to safely 
> >> free its
> >>> allocations during the finalize() call[1], an ABI change will 
> >> be
> >>> required. A new lock will be added to the rte_mem_config 
> >> structure,
> >>> which will be used by the timer library to synchronize 
> >> init/finalize
> >>> calls among multiple processes.
> >>>
> >>> [1] http://patches.dpdk.org/patch/53334/
> >>>
> >>> Signed-off-by: Erik Gabriel Carrillo 
> >>  >>   >  
> >>> ---
> >>>  doc/guides/rel_notes/deprecation.rst | 4 
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/doc/guides/rel_notes/deprecation.rst  
> >>   b/doc/guides/rel_notes/deprecation.rst  
> >>> index b47c8c2..7551383 100644
> >>> --- a/doc/guides/rel_notes/deprecation.rst
> >>> +++ b/doc/guides/rel_notes/deprecation.rst
> >>> @@ -31,6 +31,10 @@ Deprecation Notices
> >>>
> >>>  + ``rte_eal_devargs_type_count``
> >>>
> >>> +* eal: the ``rte_mem_config`` struct will change to include 
> >> a  
> >>   new lock that  
> >>> +  will allow the timer subsystem to safely release its  
> >>   allocations at cleanup  
> >>> +  time. This will result in an ABI break.
> >>> +
> >>>  * vfio: removal of ``rte_vfio_dma_map`` and  
> >>   ``rte_vfio_dma_unmap`` APIs which  
> >>>have been replaced with ``rte_dev_dma_map`` and  
> >>   ``rte_dev_dma_unmap``  
> >>>functions.  The due date for the removal targets DPDK 
> >> 20.02.  
> >>
> >>   NAK
> >>
> >>   Please go to the effort of making rte_mem_config not part of the
> >>   visible ABI.
> >>   Then change it.
> >>
> >>
> >> +1.  
> >
> > I agree on principle, however this won't solve the issue. It doesn't 
> > need to
> > be externally visible, but that's not all of its problems - it's also 
> > shared
> > between processes so there's an ABI contract between primary and 
> > secondary
> > too. This means that, even if the structure itself is not public, any
> > changes to it will still result in an ABI break. That's the nature of 
> > our
> > shared memory.
> >
> > In other words, if your goal is to avoid ABI breaks on changing this
> > structure, making it internal won't help in the slightest.
> >  
> 
>  Is there an ABI contract between primary and secondary. I always assumed
>  that if using secondary processes the requirement (though undocumented) 
>  was
>  that both had to be linked against the exact same versions of DPDK?
>   
> >>>
> >>> The fact that it's undocumented means we can't assume everyone will do
> >>> that :)
> >>>
> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.  
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>  
> > 
> > +1,
> > 
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >   
> 
> That easily can be done, yes.
> 

FYI - I submitted patches to make lcore_config private.
These patches should handle mem_config.
And I started on making eal_config private (but mem_config got in the way).

Other candidates are the internals behind ethdev and devices.

[dpdk-dev] [PATCH] Fix off-by-one errors in snprintf in various files

[Michael Santana]

snprintf guarantees to always correctly place a null terminator in the buffer
string. So manually placing a null terminator in a buffer right after a call
to snprintf is redundant code.

Additionally, there is no need to use 'sizeof(buffer) - 1' in snprintf as this
means we are not using the last character in the buffer. 'sizeof(buffer)' is
enough.

Cc: sta...@dpdk.org

Signed-off-by: Michael Santana 
---
 drivers/net/qede/base/bcm_osal.c| 4 ++--
 drivers/net/qede/qede_filter.c  | 2 +-
 drivers/net/vdev_netvsc/vdev_netvsc.c   | 2 +-
 examples/multi_process/client_server_mp/shared/common.h | 2 +-
 examples/server_node_efd/shared/common.h| 2 +-
 lib/librte_eal/common/eal_common_options.c  | 3 +--
 lib/librte_eal/common/eal_filesystem.h  | 9 -
 lib/librte_eal/common/malloc_heap.c | 4 ++--
 8 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/net/qede/base/bcm_osal.c b/drivers/net/qede/base/bcm_osal.c
index 693328f11..9915df44f 100644
--- a/drivers/net/qede/base/bcm_osal.c
+++ b/drivers/net/qede/base/bcm_osal.c
@@ -128,7 +128,7 @@ void *osal_dma_alloc_coherent(struct ecore_dev *p_dev,
}
 
OSAL_MEM_ZERO(mz_name, sizeof(*mz_name));
-   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
+   snprintf(mz_name, sizeof(mz_name), "%lx",
(unsigned long)rte_get_timer_cycles());
if (core_id == (unsigned int)LCORE_ID_ANY)
core_id = rte_get_master_lcore();
@@ -167,7 +167,7 @@ void *osal_dma_alloc_coherent_aligned(struct ecore_dev 
*p_dev,
}
 
OSAL_MEM_ZERO(mz_name, sizeof(*mz_name));
-   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
+   snprintf(mz_name, sizeof(mz_name), "%lx",
(unsigned long)rte_get_timer_cycles());
if (core_id == (unsigned int)LCORE_ID_ANY)
core_id = rte_get_master_lcore();
diff --git a/drivers/net/qede/qede_filter.c b/drivers/net/qede/qede_filter.c
index 7aeef700d..9b4d7 100644
--- a/drivers/net/qede/qede_filter.c
+++ b/drivers/net/qede/qede_filter.c
@@ -290,7 +290,7 @@ qede_config_arfs_filter(struct rte_eth_dev *eth_dev,
/* soft_id could have been used as memzone string, but soft_id is
 * not currently used so it has no significance.
 */
-   snprintf(mz_name, sizeof(mz_name) - 1, "%lx",
+   snprintf(mz_name, sizeof(mz_name), "%lx",
 (unsigned long)rte_get_timer_cycles());
mz = rte_memzone_reserve_aligned(mz_name, QEDE_MAX_FDIR_PKT_LEN,
 SOCKET_ID_ANY, 0, RTE_CACHE_LINE_SIZE);
diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c 
b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 801f54c96..eee242b5c 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -330,7 +330,7 @@ vdev_netvsc_sysfs_readlink(char *buf, size_t size, const 
char *if_name,
char in[RTE_MAX(sizeof(ctx->yield), 256u)];
int ret;
 
-   ret = snprintf(in, sizeof(in) - 1, "/sys/class/net/%s/%s",
+   ret = snprintf(in, sizeof(in), "/sys/class/net/%s/%s",
   if_name, relpath);
if (ret == -1 || (size_t)ret >= sizeof(in))
return -ENOBUFS;
diff --git a/examples/multi_process/client_server_mp/shared/common.h 
b/examples/multi_process/client_server_mp/shared/common.h
index ac9175524..6dd43fcac 100644
--- a/examples/multi_process/client_server_mp/shared/common.h
+++ b/examples/multi_process/client_server_mp/shared/common.h
@@ -49,7 +49,7 @@ get_rx_queue_name(unsigned id)
 * by maximum 3 digits (plus an extra byte for safety) */
static char buffer[sizeof(MP_CLIENT_RXQ_NAME) + 2];
 
-   snprintf(buffer, sizeof(buffer) - 1, MP_CLIENT_RXQ_NAME, id);
+   snprintf(buffer, sizeof(buffer), MP_CLIENT_RXQ_NAME, id);
return buffer;
 }
 
diff --git a/examples/server_node_efd/shared/common.h 
b/examples/server_node_efd/shared/common.h
index b8b533d8c..130fd4f4e 100644
--- a/examples/server_node_efd/shared/common.h
+++ b/examples/server_node_efd/shared/common.h
@@ -61,7 +61,7 @@ get_rx_queue_name(unsigned int id)
 */
static char buffer[sizeof(MP_NODE_RXQ_NAME) + 2];
 
-   snprintf(buffer, sizeof(buffer) - 1, MP_NODE_RXQ_NAME, id);
+   snprintf(buffer, sizeof(buffer), MP_NODE_RXQ_NAME, id);
return buffer;
 }
 
diff --git a/lib/librte_eal/common/eal_common_options.c 
b/lib/librte_eal/common/eal_common_options.c
index 0c91024c4..512d5088e 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -260,8 +260,7 @@ eal_plugindir_init(const char *path)
while ((dent = readdir(d)) != NULL) {
struct stat sb;
 
-   snprintf(sopath, PATH_MAX-1, "%s/%s", path, dent->d_name);
-   sopath[PATH_MAX-

Re: [dpdk-dev] [PATCH v4] doc: announce ring API change

[Eads, Gage]

> 01/02/2019 15:36, Gage Eads:
> > In order to support the non-blocking ring[1], an API change
> > (additional argument to rte_ring_get_memsize()) is required in
> > librte_ring. This commit updates the deprecation notice to pave the
> > way for its inclusion in 19.08.
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> >
> > Signed-off-by: Gage Eads 
> 
> There is still no agreement on this change?
> 

Still none. I was hoping this discussion 
(http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to some 
clear direction, but at this point the effort is stalled.

Re: [dpdk-dev] [PATCH] Fix off-by-one errors in snprintf in various files

[Bruce Richardson]

On Fri, May 10, 2019 at 10:53:12AM -0400, Michael Santana wrote:
> snprintf guarantees to always correctly place a null terminator in the buffer
> string. So manually placing a null terminator in a buffer right after a call
> to snprintf is redundant code.
> 
> Additionally, there is no need to use 'sizeof(buffer) - 1' in snprintf as this
> means we are not using the last character in the buffer. 'sizeof(buffer)' is
> enough.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Michael Santana 
> ---
>  drivers/net/qede/base/bcm_osal.c| 4 ++--
>  drivers/net/qede/qede_filter.c  | 2 +-
>  drivers/net/vdev_netvsc/vdev_netvsc.c   | 2 +-
>  examples/multi_process/client_server_mp/shared/common.h | 2 +-
>  examples/server_node_efd/shared/common.h| 2 +-
>  lib/librte_eal/common/eal_common_options.c  | 3 +--
>  lib/librte_eal/common/eal_filesystem.h  | 9 -
>  lib/librte_eal/common/malloc_heap.c | 4 ++--
>  8 files changed, 13 insertions(+), 15 deletions(-)
> 
Looks a good cleanup, thanks.

Acked-by: Bruce Richardson 

Re: [dpdk-dev] [PATCH v4] doc: announce ring API change

[Stephen Hemminger]

On Fri, 10 May 2019 14:53:56 +
"Eads, Gage"  wrote:

> > 01/02/2019 15:36, Gage Eads:  
> > > In order to support the non-blocking ring[1], an API change
> > > (additional argument to rte_ring_get_memsize()) is required in
> > > librte_ring. This commit updates the deprecation notice to pave the
> > > way for its inclusion in 19.08.
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> > >
> > > Signed-off-by: Gage Eads   
> > 
> > There is still no agreement on this change?
> >   
> 
> Still none. I was hoping this discussion 
> (http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to 
> some clear direction, but at this point the effort is stalled.

The fundamental tradeoff is between non-blocking rings and ABI breakage.

Why not have a new ring type for non-blocking rings since non-blocking
rings are not necessary for all use cases.

Re: [dpdk-dev] [PATCH v4] doc: announce ring API change

[Ola Liljedahl]

On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote:
> On Fri, 10 May 2019 14:53:56 +
> "Eads, Gage"  wrote:
> 
> 01/02/2019 15:36, Gage Eads:  
> In order to support the non-blocking ring[1], an API change
> (additional argument to rte_ring_get_memsize()) is required in
> librte_ring. This commit updates the deprecation notice to pave the
> way for its inclusion in 19.08.
> 
> [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> 
> Signed-off-by: Gage Eads   
> 
> There is still no agreement on this change?
>   
> 
> Still none. I was hoping this discussion (
> http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to some
> clear direction, but at this point the effort is stalled.
> 
> The fundamental tradeoff is between non-blocking rings and ABI breakage.

It is also possible to do "non-blocking" (but not lock-free) rings with the
original element size (a pointer per ring slot) as implemented here:
https://github.com/ARM-software/progress64/blob/master/src/p64_ringbuf.c
Some extra (head&tail) metadata is required but I think there is space for that
in the rte_ring structure.

> Why not have a new ring type for non-blocking rings since non-blocking
> rings are not necessary for all use cases.

I proposed a new library ("rte_lfring") with lock-free rings here:
https://mails.dpdk.org/archives/dev/2019-January/124242.html
The lock-free design should be the same as in Gage's patch.

rte_lfring could of course be part of the rte_ring library.


-- 
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl

Re: [dpdk-dev] [PATCH] Fix off-by-one errors in snprintf in various files

[Burakov, Anatoly]

On 10-May-19 3:53 PM, Michael Santana wrote:

snprintf guarantees to always correctly place a null terminator in the buffer
string. So manually placing a null terminator in a buffer right after a call
to snprintf is redundant code.

Additionally, there is no need to use 'sizeof(buffer) - 1' in snprintf as this
means we are not using the last character in the buffer. 'sizeof(buffer)' is
enough.

Cc: sta...@dpdk.org

Signed-off-by: Michael Santana 
---


LGTM

Acked-by: Anatoly Burakov 

--
Thanks,
Anatoly

Re: [dpdk-dev] [dpdk-stable] [PATCH v3] eventdev: fix Rx adapter event flush logic

[Mattias Rönnblom]

On 2019-05-10 15:30, Thomas Monjalon wrote:

Any review please?



Reviewed-by: Mattias Rönnblom 

Mattias Elo reported "Thanks, I’ve tested this patch and can confirm 
that it fixes the problem." for the (nearly identical) v2 of this patch.

[dpdk-dev] [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

TCP flags were moved to the TCP header file from the Ethernet control
header file, keeping their names intact.

Missing TCP ECN flags were added.

The ALL mask did not include TCP ECN flags, so it was renamed to
reflect that it applies to N-tuple filtering only.

A driver using the ALL mask was updated accordingly.

Signed-off-by: Morten Brørup 
---
 app/test-pmd/cmdline.c   |4 ++--
 drivers/net/e1000/igb_ethdev.c   |8 
 lib/librte_ethdev/rte_eth_ctrl.h |8 +---
 lib/librte_net/rte_tcp.h |   13 +
 4 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e45..59a45c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9983,7 +9983,7 @@ cmd_2tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
@@ -10141,7 +10141,7 @@ cmd_5tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b897e8a..c2fe19a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3702,7 +3702,7 @@ ntuple_filter_to_2tuple(struct rte_eth_ntuple_filter 
*filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_port_mask) {
@@ -3782,7 +3782,7 @@ igb_inject_2uple_filter(struct rte_eth_dev *dev,
ttqf &= ~E1000_TTQF_MASK_ENABLE;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
@@ -4188,7 +4188,7 @@ ntuple_filter_to_5tuple_82576(struct 
rte_eth_ntuple_filter *filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_ip_mask) {
@@ -4318,7 +4318,7 @@ igb_inject_5tuple_filter_82576(struct rte_eth_dev *dev,
imir |= filter->filter_info.priority << E1000_IMIR_PRIORITY_SHIFT;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..f21e84b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -184,13 +184,7 @@ struct rte_eth_syn_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)
 
-#define TCP_URG_FLAG 0x20
-#define TCP_ACK_FLAG 0x10
-#define TCP_PSH_FLAG 0x08
-#define TCP_RST_FLAG 0x04
-#define TCP_SYN_FLAG 0x02
-#define TCP_FIN_FLAG 0x01
-#define TCP_FLAG_ALL 0x3F
+#define RTE_NTUPLE_TCP_FLAGS_MASK 0x3F /**< TCP flags filter can match. */
 
 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_net/rte_tcp.h b/lib/librte_net/rte_tcp.h
index 91f5898..2e89b5e 100644
--- a/lib/librte_net/rte_tcp.h
+++ b/lib/librte_net/rte_tcp.h
@@ -2,6 +2,7 @@
  * Copyright(c) 1982, 1986, 1990, 1993
  *  The Regents of the University of California.
  * Copyright(c) 2010-2014 Intel Corporation.
+ * Copyright(c) 2019 SmartShare Systems.
  * All rights reserved.
  */
 
@@ -35,6 +36,18 @@ struct tcp_hdr {
uint16_t tcp_urp;   /**< TCP urgent pointer, if any. */
 } __attribute__((__packed__));
 
+/**
+ * TCP Flags
+ */
+#define TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
+#define TCP_ECE_FLAG 0x40 /**< ECN-Echo */
+#define TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
+#define TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant */
+#define TCP_PSH_FLAG 0

Re: [dpdk-dev] [PATCH v4] doc: announce ring API change

[Eads, Gage]

> -Original Message-
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Friday, May 10, 2019 10:19 AM
> To: step...@networkplumber.org; Eads, Gage 
> Cc: arybche...@solarflare.com; nd ; Ananyev, Konstantin
> ; tho...@monjalon.net; Richardson,
> Bruce ; dev@dpdk.org;
> olivier.m...@6wind.com; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> 
> Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change
> 
> On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote:
> > On Fri, 10 May 2019 14:53:56 +
> > "Eads, Gage"  wrote:
> >
> > 01/02/2019 15:36, Gage Eads:
> > In order to support the non-blocking ring[1], an API change
> > (additional argument to rte_ring_get_memsize()) is required in
> > librte_ring. This commit updates the deprecation notice to pave the
> > way for its inclusion in 19.08.
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> >
> > Signed-off-by: Gage Eads 
> >
> > There is still no agreement on this change?
> >
> >
> > Still none. I was hoping this discussion (
> > http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead
> > to some clear direction, but at this point the effort is stalled.
> >
> > The fundamental tradeoff is between non-blocking rings and ABI breakage.
> 
> It is also possible to do "non-blocking" (but not lock-free) rings with the
> original element size (a pointer per ring slot) as implemented here:
> https://github.com/ARM-
> software/progress64/blob/master/src/p64_ringbuf.c
> Some extra (head&tail) metadata is required but I think there is space for
> that in the rte_ring structure.
> 
> > Why not have a new ring type for non-blocking rings since non-blocking
> > rings are not necessary for all use cases.
> 
> I proposed a new library ("rte_lfring") with lock-free rings here:
> https://mails.dpdk.org/archives/dev/2019-January/124242.html
> The lock-free design should be the same as in Gage's patch.
> 
> rte_lfring could of course be part of the rte_ring library.
> 

Just read through the API/ABI stability discussion 
(https://mails.dpdk.org/archives/dev/2019-April/128969.html). I'll drop my 
patchset and work on supporting this lfring API instead.

Thanks,
Gage

> 
> --
> Ola Liljedahl, Networking System Architect, Arm Phone +46706866373, Skype
> ola.liljedahl

[dpdk-dev] [PATCH] doc: fix doxygen documentation for timer API

[Erik Gabriel Carrillo]

Now that some of the symbols in the timer lib are versioned, the
Doxygen documentation that is generated is incorrect.  Group all
versioned symbols, listing the generic name first, and remove comments
for older versions of symbols.

Signed-off-by: Erik Gabriel Carrillo 
---
 lib/librte_timer/rte_timer.h | 54 
 1 file changed, 14 insertions(+), 40 deletions(-)

diff --git a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h
index b502f8c..2196934 100644
--- a/lib/librte_timer/rte_timer.h
+++ b/lib/librte_timer/rte_timer.h
@@ -169,14 +169,6 @@ int __rte_experimental rte_timer_data_dealloc(uint32_t id);
  *
  * Initializes internal variables (list, locks and so on) for the RTE
  * timer library.
- */
-void rte_timer_subsystem_init_v20(void);
-
-/**
- * Initialize the timer library.
- *
- * Initializes internal variables (list, locks and so on) for the RTE
- * timer library.
  *
  * @return
  *   - 0: Success
@@ -185,8 +177,9 @@ void rte_timer_subsystem_init_v20(void);
  *   - -ENOMEM: Unable to allocate memory needed to initialize timer
  *  subsystem
  */
-int rte_timer_subsystem_init_v1905(void);
 int rte_timer_subsystem_init(void);
+int rte_timer_subsystem_init_v1905(void);
+void rte_timer_subsystem_init_v20(void);
 
 /**
  * @warning
@@ -250,15 +243,15 @@ void rte_timer_init(struct rte_timer *tim);
  *   - 0: Success; the timer is scheduled.
  *   - (-1): Timer is in the RUNNING or CONFIG state.
  */
-int rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
-   enum rte_timer_type type, unsigned int tim_lcore,
-   rte_timer_cb_t fct, void *arg);
-int rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
- enum rte_timer_type type, unsigned int tim_lcore,
- rte_timer_cb_t fct, void *arg);
 int rte_timer_reset(struct rte_timer *tim, uint64_t ticks,
enum rte_timer_type type, unsigned tim_lcore,
rte_timer_cb_t fct, void *arg);
+int rte_timer_reset_v1905(struct rte_timer *tim, uint64_t ticks,
+ enum rte_timer_type type, unsigned int tim_lcore,
+ rte_timer_cb_t fct, void *arg);
+int rte_timer_reset_v20(struct rte_timer *tim, uint64_t ticks,
+   enum rte_timer_type type, unsigned int tim_lcore,
+   rte_timer_cb_t fct, void *arg);
 
 
 /**
@@ -315,9 +308,9 @@ rte_timer_reset_sync(struct rte_timer *tim, uint64_t ticks,
  *   - 0: Success; the timer is stopped.
  *   - (-1): The timer is in the RUNNING or CONFIG state.
  */
-int rte_timer_stop_v20(struct rte_timer *tim);
-int rte_timer_stop_v1905(struct rte_timer *tim);
 int rte_timer_stop(struct rte_timer *tim);
+int rte_timer_stop_v1905(struct rte_timer *tim);
+int rte_timer_stop_v20(struct rte_timer *tim);
 
 /**
  * Loop until rte_timer_stop() succeeds.
@@ -355,34 +348,14 @@ int rte_timer_pending(struct rte_timer *tim);
  * The precision of the timer depends on the call frequency of this
  * function. However, the more often the function is called, the more
  * CPU resources it will use.
- */
-void rte_timer_manage_v20(void);
-
-/**
- * Manage the timer list and execute callback functions.
- *
- * This function must be called periodically from EAL lcores
- * main_loop(). It browses the list of pending timers and runs all
- * timers that are expired.
- *
- * The precision of the timer depends on the call frequency of this
- * function. However, the more often the function is called, the more
- * CPU resources it will use.
  *
  * @return
  *   - 0: Success
  *   - -EINVAL: timer subsystem not yet initialized
  */
-int rte_timer_manage_v1905(void);
 int rte_timer_manage(void);
-
-/**
- * Dump statistics about timers.
- *
- * @param f
- *   A pointer to a file for output
- */
-void rte_timer_dump_stats_v20(FILE *f);
+int rte_timer_manage_v1905(void);
+void rte_timer_manage_v20(void);
 
 /**
  * Dump statistics about timers.
@@ -393,8 +366,9 @@ void rte_timer_dump_stats_v20(FILE *f);
  *   - 0: Success
  *   - -EINVAL: timer subsystem not yet initialized
  */
-int rte_timer_dump_stats_v1905(FILE *f);
 int rte_timer_dump_stats(FILE *f);
+int rte_timer_dump_stats_v1905(FILE *f);
+void rte_timer_dump_stats_v20(FILE *f);
 
 /**
  * @warning
-- 
2.6.4

Re: [dpdk-dev] [PATCH v2] event/dsw: ignore scheduling type for single-link queues

[Eads, Gage]

> The scheduling type parameter is not applicable for single link

> queues. DSW would, at the time of rte_event_queue_setup(), erroneously

> verify that scheduling type was one of the supported types, and

> returned -ENOTSUP in case of RTE_SCHED_TYPE_ORDERED.

>

> Fixes: 4540ee9c68 ("event/dsw: add device and queue configuration")

> Cc: sta...@dpdk.org

>

> Signed-off-by: Mattias Ronnblom 
> mailto:mattias.ronnb...@ericsson.com>>

Acked-by: Gage Eads 

[dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD

[Smoczynski, MarcinX]

Hi.
One of my patches submitted this week is breaking build on BSD systems. I dug
deeper and found out that it's because I'm using IPPROTO_* macros from
 in a header (rte_ip.h) which is included in the driver which uses
_XOPEN_SOURCE definition in its Makefile/meson.build.

On Linux and glibc this is not a problem, because:
1. Those IPPROTO macros are included unconditionally and
2. We're using _GNU_SOURCE at top level anyway which gives us visibility of
   every feature set. According to "features.h" from glibc 2.18
   (used in Ubuntu 18.04):

   
https://github.molgen.mpg.de/git-mirror/glibc/blob/release/2.18/master/include/features.h
 /* If _GNU_SOURCE was defined by the user, turn on all the other features. 
 */
 #ifdef _GNU_SOURCE
 # undef  _ISOC95_SOURCE
 # define _ISOC95_SOURCE1
 # undef  _ISOC99_SOURCE
 # define _ISOC99_SOURCE1
 # undef  _ISOC11_SOURCE
 # define _ISOC11_SOURCE1
 # undef  _POSIX_SOURCE
 # define _POSIX_SOURCE 1
 # undef  _POSIX_C_SOURCE
 # define _POSIX_C_SOURCE   200809L
 # undef  _XOPEN_SOURCE
 # define _XOPEN_SOURCE 700
 # undef  _XOPEN_SOURCE_EXTENDED
 # define _XOPEN_SOURCE_EXTENDED 1
 # undef_LARGEFILE64_SOURCE
 # define _LARGEFILE64_SOURCE1
 # undef  _BSD_SOURCE
 # define _BSD_SOURCE 1
 # undef  _SVID_SOURCE
 # define _SVID_SOURCE 1
 # undef  _ATFILE_SOURCE
 # define _ATFILE_SOURCE1
 #endif

BSD systems are a little bit more orthodox:
1. IPPROTOs are defined conditionally if __BSD_VISIBLE macro is defined. If I
   understand it correctly, they are not a part of any POSIX specification
   and that's why they are kept separated.
2. __BSD_VISIBLE is set to 0 if any of XOPEN_SOURCE or POSIX_C_SOURCE macros
   are defined. The reasoning here is: if you don't specify feature set you want
   to use you have it all, but when you do, you have exactly what you've
   explicitly asked for. Using XOPEN_SOURCE=700 means: give me POSIX 2k8 and
   XSI only. In other words using this macro alone is restricting portability;
   by default DPDK is building with full visibility.

   https://github.com/freebsd/freebsd/blob/release/12.0.0/sys/sys/cdefs.h
   Lines 680 to 765
 /* Deal with various X/Open Portability Guides and Single UNIX Spec. */
 #ifdef _XOPEN_SOURCE
 #if _XOPEN_SOURCE - 0 >= 700
 #define__XSI_VISIBLE700
 #undef _POSIX_C_SOURCE
 #define_POSIX_C_SOURCE  200809
 #elif _XOPEN_SOURCE - 0 >= 600
 #define__XSI_VISIBLE600
 #undef _POSIX_C_SOURCE
 #define_POSIX_C_SOURCE  200112
 #elif _XOPEN_SOURCE - 0 >= 500
 #define__XSI_VISIBLE500
 #undef _POSIX_C_SOURCE
 #define_POSIX_C_SOURCE  199506
 #endif
 #endif

 /*
 * Deal with all versions of POSIX.  The ordering relative to the tests 
above is
 * important.
 */
 #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
 #define_POSIX_C_SOURCE  198808
 #endif
 #ifdef _POSIX_C_SOURCE
 #if _POSIX_C_SOURCE >= 200809
 #define__POSIX_VISIBLE  200809
 #define__ISO_C_VISIBLE  1999
 #elif _POSIX_C_SOURCE >= 200112
 #define__POSIX_VISIBLE  200112
 #define__ISO_C_VISIBLE  1999
 #elif _POSIX_C_SOURCE >= 199506
 #define__POSIX_VISIBLE  199506
 #define__ISO_C_VISIBLE  1990
 #elif _POSIX_C_SOURCE >= 199309
 #define__POSIX_VISIBLE  199309
 #define__ISO_C_VISIBLE  1990
 #elif _POSIX_C_SOURCE >= 199209
 #define__POSIX_VISIBLE  199209
 #define__ISO_C_VISIBLE  1990
 #elif _POSIX_C_SOURCE >= 199009
 #define__POSIX_VISIBLE  199009
 #define__ISO_C_VISIBLE  1990
 #else
 #define__POSIX_VISIBLE  198808
 #define__ISO_C_VISIBLE  0
 #endif /* _POSIX_C_SOURCE */
 #else<- !!!
 /*-
 * Deal with _ANSI_SOURCE:
 * If it is defined, and no other compilation environment is explicitly
 * requested, then define our internal feature-test macros to zero.  This
 * makes no difference to the preprocessor (undefined symbols in 
preprocessing
 * expressions are defined to have value zero), but makes it more 
convenient for
 * a test program to print out the values.
 *
 * If a program mistakenly defines _ANSI_SOURCE and some other macro such as
 * _POSIX_C_SOURCE, we will assume that it wants the broader compilation
 * environment (and in fact we will never get here).
 */
 #if defined(_ANSI_SOURCE)  /* Hide almost everything. */
 #define__POSIX_VISIBLE  0
 #define__XSI_VISIBLE0
 #define__BSD_VISIBLE0
 #define__ISO_C_VISIBLE  1990
 #define__EXT1_VISIBLE   0
 #elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */
 #define__POSIX_VISIBLE   

[dpdk-dev] [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

TCP flags were moved to the TCP header file from the Ethernet control header 
file, keeping their names intact.
Missing TCP ECN flags were added.
The ALL mask did not include TCP ECN flags, so it was renamed to reflect that 
it applies to N-tuple filtering only.
A driver using the ALL mask was updated accordingly.

Signed-off-by: Morten Brørup 
---
 app/test-pmd/cmdline.c   |4 ++--
 drivers/net/e1000/igb_ethdev.c   |8 
 lib/librte_ethdev/rte_eth_ctrl.h |8 +---
 lib/librte_net/rte_tcp.h |   13 +
 4 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e45..59a45c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9983,7 +9983,7 @@ cmd_2tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
@@ -10141,7 +10141,7 @@ cmd_5tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b897e8a..c2fe19a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3702,7 +3702,7 @@ ntuple_filter_to_2tuple(struct rte_eth_ntuple_filter 
*filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_port_mask) {
@@ -3782,7 +3782,7 @@ igb_inject_2uple_filter(struct rte_eth_dev *dev,
ttqf &= ~E1000_TTQF_MASK_ENABLE;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
@@ -4188,7 +4188,7 @@ ntuple_filter_to_5tuple_82576(struct 
rte_eth_ntuple_filter *filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_ip_mask) {
@@ -4318,7 +4318,7 @@ igb_inject_5tuple_filter_82576(struct rte_eth_dev *dev,
imir |= filter->filter_info.priority << E1000_IMIR_PRIORITY_SHIFT;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..f21e84b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -184,13 +184,7 @@ struct rte_eth_syn_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)
 
-#define TCP_URG_FLAG 0x20
-#define TCP_ACK_FLAG 0x10
-#define TCP_PSH_FLAG 0x08
-#define TCP_RST_FLAG 0x04
-#define TCP_SYN_FLAG 0x02
-#define TCP_FIN_FLAG 0x01
-#define TCP_FLAG_ALL 0x3F
+#define RTE_NTUPLE_TCP_FLAGS_MASK 0x3F /**< TCP flags filter can match. */
 
 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_net/rte_tcp.h b/lib/librte_net/rte_tcp.h
index 91f5898..2e89b5e 100644
--- a/lib/librte_net/rte_tcp.h
+++ b/lib/librte_net/rte_tcp.h
@@ -2,6 +2,7 @@
  * Copyright(c) 1982, 1986, 1990, 1993
  *  The Regents of the University of California.
  * Copyright(c) 2010-2014 Intel Corporation.
+ * Copyright(c) 2019 SmartShare Systems.
  * All rights reserved.
  */
 
@@ -35,6 +36,18 @@ struct tcp_hdr {
uint16_t tcp_urp;   /**< TCP urgent pointer, if any. */
 } __attribute__((__packed__));
 
+/**
+ * TCP Flags
+ */
+#define TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
+#define TCP_ECE_FLAG 0x40 /**< ECN-Echo */
+#define TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
+#define TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant */
+#define TCP_PSH_FLAG 0x

[dpdk-dev] [PATCH] librte_net: define TCP flags in rte_tcp.h instead of in rte_eth_ctrl.h

[Morten Brørup]

TCP flags were moved to the TCP header file from the Ethernet control
header file, keeping their names intact.

Missing TCP ECN flags were added.

The ALL mask did not include TCP ECN flags, so it was renamed to reflect
that it applies to N-tuple filtering only.
A driver using the ALL mask was updated accordingly.

Signed-off-by: Morten Brørup 
---
 app/test-pmd/cmdline.c   |4 ++--
 drivers/net/e1000/igb_ethdev.c   |8 
 lib/librte_ethdev/rte_eth_ctrl.h |8 +---
 lib/librte_net/rte_tcp.h |   13 +
 4 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e45..59a45c1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -9983,7 +9983,7 @@ cmd_2tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
@@ -10141,7 +10141,7 @@ cmd_5tuple_filter_parsed(void *parsed_result,
" when protocol is TCP.\n");
return;
}
-   if (res->tcp_flags_value > TCP_FLAG_ALL) {
+   if (res->tcp_flags_value > RTE_NTUPLE_TCP_FLAGS_MASK) {
printf("invalid TCP flags.\n");
return;
}
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b897e8a..c2fe19a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3702,7 +3702,7 @@ ntuple_filter_to_2tuple(struct rte_eth_ntuple_filter 
*filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_port_mask) {
@@ -3782,7 +3782,7 @@ igb_inject_2uple_filter(struct rte_eth_dev *dev,
ttqf &= ~E1000_TTQF_MASK_ENABLE;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
@@ -4188,7 +4188,7 @@ ntuple_filter_to_5tuple_82576(struct 
rte_eth_ntuple_filter *filter,
return -EINVAL;
if (filter->priority > E1000_2TUPLE_MAX_PRI)
return -EINVAL;  /* filter index is out of range. */
-   if (filter->tcp_flags > TCP_FLAG_ALL)
+   if (filter->tcp_flags > RTE_NTUPLE_TCP_FLAGS_MASK)
return -EINVAL;  /* flags is invalid. */
 
switch (filter->dst_ip_mask) {
@@ -4318,7 +4318,7 @@ igb_inject_5tuple_filter_82576(struct rte_eth_dev *dev,
imir |= filter->filter_info.priority << E1000_IMIR_PRIORITY_SHIFT;
 
/* tcp flags bits setting. */
-   if (filter->filter_info.tcp_flags & TCP_FLAG_ALL) {
+   if (filter->filter_info.tcp_flags & RTE_NTUPLE_TCP_FLAGS_MASK) {
if (filter->filter_info.tcp_flags & TCP_URG_FLAG)
imir_ext |= E1000_IMIREXT_CTRL_URG;
if (filter->filter_info.tcp_flags & TCP_ACK_FLAG)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae2..f21e84b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -184,13 +184,7 @@ struct rte_eth_syn_filter {
RTE_NTUPLE_FLAGS_DST_PORT | \
RTE_NTUPLE_FLAGS_PROTO)
 
-#define TCP_URG_FLAG 0x20
-#define TCP_ACK_FLAG 0x10
-#define TCP_PSH_FLAG 0x08
-#define TCP_RST_FLAG 0x04
-#define TCP_SYN_FLAG 0x02
-#define TCP_FIN_FLAG 0x01
-#define TCP_FLAG_ALL 0x3F
+#define RTE_NTUPLE_TCP_FLAGS_MASK 0x3F /**< TCP flags filter can match. */
 
 /**
  * A structure used to define the ntuple filter entry
diff --git a/lib/librte_net/rte_tcp.h b/lib/librte_net/rte_tcp.h
index 91f5898..2e89b5e 100644
--- a/lib/librte_net/rte_tcp.h
+++ b/lib/librte_net/rte_tcp.h
@@ -2,6 +2,7 @@
  * Copyright(c) 1982, 1986, 1990, 1993
  *  The Regents of the University of California.
  * Copyright(c) 2010-2014 Intel Corporation.
+ * Copyright(c) 2019 SmartShare Systems.
  * All rights reserved.
  */
 
@@ -35,6 +36,18 @@ struct tcp_hdr {
uint16_t tcp_urp;   /**< TCP urgent pointer, if any. */
 } __attribute__((__packed__));
 
+/**
+ * TCP Flags
+ */
+#define TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
+#define TCP_ECE_FLAG 0x40 /**< ECN-Echo */
+#define TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
+#define TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant */
+#define TCP_PSH_FLAG 0x

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

[David Christensen]

+* Power 9 platforms with Mellanox(R) NICs combinations
+
+   * CPU:
+
+ * POWER9 2.2 (pvr 004e 1202) 2300MHz
+
+   * OS:
+
+ * Ubuntu 18.04.1 LTS (Bionic Beaver)
+
+   * NICs:
+
+ * Mellanox(R) ConnectX(R)-5 100G MCX556A-ECAT (2x100G)
+
+   * Host interface: PCI Express 3.0 x16


The P9 platform supports PCIe Gen4.  Is that not enabled in your testing 
or simply a typo?


Dave

Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD

[Thomas Monjalon]

10/05/2019 19:14, Smoczynski, MarcinX:
> To summarize we have different visibility sets for Linux and BSD when using
> XOPEN_SOURCE or POSIX_C_SOURCE explicitly. To overcome this situation we can
> either remove problematic XOPEN macros from mk/meson rules 
> (drivers/net/failsafe,
> drivers/net/mlx4, drivers/net/mlx5)

What is the consequence of removing these macros in mlx and failsafe PMDs?

> or add explicit -D__BSD_VISIBLE when
> building for BSD. I think also that defining _GNU_SOURCE for BSD builds makes 
> no
> sense although it does not cause any problems.
> 
> I have checked that removing those problematic macros solves build problems on
> FreeBSD12 and does not break on Ubuntu 18.04.

Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD

[Thomas Monjalon]

re-send with fixed Cc

10/05/2019 20:17, Thomas Monjalon:
> 10/05/2019 19:14, Smoczynski, MarcinX:
> > To summarize we have different visibility sets for Linux and BSD when using
> > XOPEN_SOURCE or POSIX_C_SOURCE explicitly. To overcome this situation we can
> > either remove problematic XOPEN macros from mk/meson rules 
> > (drivers/net/failsafe,
> > drivers/net/mlx4, drivers/net/mlx5)
> 
> What is the consequence of removing these macros in mlx and failsafe PMDs?
> 
> > or add explicit -D__BSD_VISIBLE when
> > building for BSD. I think also that defining _GNU_SOURCE for BSD builds 
> > makes no
> > sense although it does not cause any problems.
> > 
> > I have checked that removing those problematic macros solves build problems 
> > on
> > FreeBSD12 and does not break on Ubuntu 18.04.

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Thomas Monjalon]

10/05/2019 15:43, Bruce Richardson:
> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> > ( from the undersigned )
> > 
> > Hi folks,
> > 
> > In light of the renewed community discussion on API Stability
> > (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> > right time to open a discussion on how DPDK is distributed and updated.
> > 
> > To this point in time, DPDK's primary distribution method has been as
> > source code distributed as a tarball from dpdk.org. This distribution
> > method, in addition to abi instability and the dpdk's build system
> > default behaviour of static linking have all encouraged the "tight
> > coupling" or "vendorization" of DPDK.
> > 
> > These behaviours makes it a challenge for end users, those deploying
> > applications based on DPDK, to manage and update DPDK in a method
> > consistent with other system libraries. For instance, an end user may
> > not have any idea which version of DPDK a consuming application may be
> > using and if this DPDK version is reasonably up to date with the latest
> > upstream version. This would not be the case for other system libraries
> > such as glibc.
> > 
> > For these reasons, now is the right time for DPDK to embrace standard
> > Operating System practices for distributing and updating system
> > libraries. The current industry push towards cloud and
> > cloud-friendliness make addressing this issue all the more timely.
> > 
> > To this end, the following proposals are made for discussion at the next
> > techboard meeting:-
> > 
> > * The primary method of distributing DPDK should be as an operating
> > system package, dpdk.org should be updated to reflect this reality and
> > provide OS installation details in place of tarball downloads.
> 
> I really like that idea. Since DPDK is available in distro packages that
> should be the first port of call for users getting DPDK. Since it's just a
> doc update - as I understand it anyway - it should be easy to implement if
> agreed, which is a nice bonus.

Yes. The real effort will be to stay up to date with changes
in OS distributions. If distro maintainers are willing to maintain it,
that's fine. Thank you :)

> > * DPDK should build as a dynamic shared libraries by default, to
> > encourage loose coupling with consuming applications.
> 
> To a certain extent, this only applies with the "make" build system, which
> is due to be deprecated in the next release and removed sometime next year.
> With builds done with meson and ninja, both shared and static libraries are
> always built. The default setting though remains as "static" which applies
> only to the linking of applications as part of the DPDK build. This default
> was set mainly for legacy purposes, but also has benefits for us developers
> working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
> and EAL_PMD_PATH values for running applications we've built. Therefore,
> I'm not sure of the value of changing the default here - it's certainly
> less important than the default in the "make" build system where only one
> library type at a time was built.

Yes no need to change the default.
If you build DPDK yourself, it is more convenient to use static libs.
If you want something easier to update, you probably use
the packages from distributions which are shared libraries.

> > * Future guarantees around ABI/API stability should be provided, so that
> > OS packagers can offer safe upgrade paths for consuming applications.

DPDK is a set of libraries, some more stable than others.
If we cannot guarantee a full stability for a long time,
we may have some changes here and there sometimes.
And it's even worst with experimental functions.
I think it is more realistic to provide a level of stability
per DPDK library. In order to leverage such fine grained stability,
the libraries should be packaged separately in the OS.
Then the applications relying only on stable libraries will be able
to link with updated libraries without any change or re-compilation.

Re: [dpdk-dev] [PATCH] net/mlx5: fix device removal handler for multiport device

[Yongseok Koh]

> On May 10, 2019, at 7:36 AM, Viacheslav Ovsiienko  
> wrote:
> 
> IBV_EVENT_DEVICE_FATAL event is generated by the driver once for
> the entire multiport Infiniband device, not for each existing ports.
> The port index is zero and it causes dropping the device removal
> event. We should invoke the removal event processing routine
> for each port we have installed handler for.
> 
> Fixes: 028b2a28c3cb ("net/mlx5: update event handler for multiport IB 
> devices")
> 
> Signed-off-by: Viacheslav Ovsiienko 
> ---
> drivers/net/mlx5/mlx5_ethdev.c | 43 +-
> 1 file changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index 80ee98f..3962d41 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -1116,6 +1116,35 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
> *fw_ver, size_t fw_size)
> }
> 
> /**
> + * Handle asynchronous removal event for entire multiport device.
> + *
> + * @param sh
> + *   Infiniband device shared context.
> + */
> +static void
> +mlx5_dev_interrupt_device_fatal(struct mlx5_ibv_shared *sh)
> +{
> + uint32_t i;
> +
> + for (i = 0; i < sh->max_port; ++i) {
> + struct rte_eth_dev *dev;
> +
> + if (sh->port[i].ih_port_id >= RTE_MAX_ETHPORTS) {
> + /*
> +  * Or not existing port either no
> +  * handler installed for this port.
> +  */
> + continue;
> + }
> + dev = &rte_eth_devices[sh->port[i].ih_port_id];
> + assert(dev);
> + if (dev->data->dev_conf.intr_conf.rmv)
> + _rte_eth_dev_callback_process
> + (dev, RTE_ETH_EVENT_INTR_RMV, NULL);
> + }
> +}
> +
> +/**
>  * Handle shared asynchronous events the NIC (removal event
>  * and link status change). Supports multiport IB device.
>  *
> @@ -1137,6 +1166,16 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
> *fw_ver, size_t fw_size)
>   break;
>   /* Retrieve and check IB port index. */
>   tmp = (uint32_t)event.element.port_num;
> + if (!tmp && event.event_type == IBV_EVENT_DEVICE_FATAL) {
> + /*
> +  * The DEVICE_FATAL event is called once for
> +  * entire device without port specifying.
> +  * We should notify all existing ports.
> +  */
> + mlx5_glue->ack_async_event(&event);
> + mlx5_dev_interrupt_device_fatal(sh);
> + continue;
> + }

Then, you should clear the previous handle below, right? I mean this if-clause.

if (event.event_type == IBV_EVENT_DEVICE_FATAL &&

>   assert(tmp && (tmp <= sh->max_port));
>   if (!tmp ||
>   tmp > sh->max_port ||
> @@ -1146,12 +1185,14 @@ int mlx5_fw_version_get(struct rte_eth_dev *dev, char 
> *fw_ver, size_t fw_size)
>* installed for this port.
>*/
>   mlx5_glue->ack_async_event(&event);
> + DRV_LOG(DEBUG,
> + "port %u event type %d on not handled",

Needs to fix the sentence. Be more specific. For example,
port %u cannot handle an event (type %d) due to 
invalid IB port index

One more below. That should be something like 
port %u cannot handle an unknown event (type %d)

Thanks,
Yongseok

> + tmp, event.event_type);
>   continue;
>   }
>   /* Retrieve ethernet device descriptor. */
>   tmp = sh->port[tmp - 1].ih_port_id;
>   dev = &rte_eth_devices[tmp];
> - tmp = 0;
>   assert(dev);
>   if ((event.event_type == IBV_EVENT_PORT_ACTIVE ||
>event.event_type == IBV_EVENT_PORT_ERR) &&
> -- 
> 1.8.3.1
> 

[dpdk-dev] [PATCH 0/5] BBDEV PMD Drivers Extension for 19.08

[Nic Chautru]

This was deferred from 19.05 due to time running out. 
Addition of a PMD for 4G FEC encoding and decoding functions for Intel PAC N300 
FPGA. 
Extension of PMD based on Intel optimised SW libraries for 5G FEC. 
The HW dependency is available now.

Nicolas Chautru (5):
  baseband/fpga_lte_fec: addition of driver for 4G turbo FEC with PAC
N300 FPGA card
  bbdev : Extension of BBDEV for 5G FEC
  baseband/turbo_sw : Extension of turbo_sw for 5G FEC
  test-bbdev : Update of bbdec test-app for FPGA and 5G testing
  usertools: update to usertool to allow binding of baseband device

 app/test-bbdev/ldpc_dec_default.data   |1 +
 app/test-bbdev/ldpc_enc_default.data   |1 +
 app/test-bbdev/main.c  |   48 +-
 app/test-bbdev/main.h  |6 +-
 app/test-bbdev/meson.build |2 +-
 app/test-bbdev/test-bbdev.py   |9 +-
 app/test-bbdev/test_bbdev.c|   12 +-
 app/test-bbdev/test_bbdev_perf.c   | 1224 -
 app/test-bbdev/test_bbdev_vector.c |  521 +++-
 app/test-bbdev/test_bbdev_vector.h |   16 +-
 app/test-bbdev/test_vectors/ldpc_dec_HARQ_1_0.data |  354 +++
 app/test-bbdev/test_vectors/ldpc_dec_HARQ_1_1.data |  685 +
 app/test-bbdev/test_vectors/ldpc_dec_HARQ_1_2.data |  903 +++
 app/test-bbdev/test_vectors/ldpc_dec_HARQ_1_3.data |  939 +++
 app/test-bbdev/test_vectors/ldpc_dec_v11835.data   |   50 +
 app/test-bbdev/test_vectors/ldpc_dec_v14298.data   |  377 +++
 app/test-bbdev/test_vectors/ldpc_dec_v2342.data|  746 ++
 .../test_vectors/ldpc_dec_v2342_drop.data  |  746 ++
 app/test-bbdev/test_vectors/ldpc_dec_v7813.data|   49 +
 app/test-bbdev/test_vectors/ldpc_dec_v8480.data|   75 +
 app/test-bbdev/test_vectors/ldpc_dec_v8568.data|  256 ++
 .../test_vectors/ldpc_dec_v8568_low.data   |  256 ++
 app/test-bbdev/test_vectors/ldpc_dec_v9503.data| 1216 +
 .../test_vectors/ldpc_dec_vcrc_fail.data   | 1216 +
 .../ldpc_enc_c1_k1144_r0_e1380_rm.data |   51 +
 .../ldpc_enc_c1_k1144_r0_e1380_rm_crc24b.data  |   51 +
 .../test_vectors/ldpc_enc_c1_k330_r0_e360_rm.data  |   44 +
 .../test_vectors/ldpc_enc_c1_k720_r0_e832_rm.data  |   47 +
 .../ldpc_enc_c1_k720_r0_e864_rm_crc24b.data|   47 +
 .../ldpc_enc_c1_k8148_r0_e9372_rm.data |  110 +
 app/test-bbdev/test_vectors/ldpc_enc_v11835.data   |   42 +
 .../test_vectors/ldpc_enc_v3964_rv1.data   |   52 +
 app/test-bbdev/test_vectors/ldpc_enc_v7813.data|   42 +
 app/test-bbdev/test_vectors/ldpc_enc_v8568.data|   69 +
 .../test_vectors/ldpc_enc_v8568_crc24a.data|   69 +
 .../turbo_dec_c1_k160_r0_e23040_teq_negllr.data|  784 ++
 ...o_dec_c1_k160_r0_e23040_teq_negllr_scatter.data |  786 ++
 .../turbo_dec_c1_k160_r0_e23040_teq_posllr.data|  784 ++
 .../turbo_dec_c1_k3136_r0_e4914_sbd_negllr.data|  352 +++
 ...44_r0_e12248_crc24b_sbd_teq_negllr_scatter.data | 1034 
 ...urbo_dec_c1_k6144_r0_e34560_negllr_scatter.data |  647 +
 ...bo_dec_c2_k3136_r0_e4920_sbd_negllr_crc24b.data |5 +-
 ...turbo_dec_c2_k3136_r0_e4920_sbd_teq_negllr.data |  991 
 ...c_c2_k3136_r0_e4920_sbd_teq_negllr_scatter.data |  993 
 ...turbo_dec_c6_k5888_r3_e6912_sbd_teq_negllr.data | 2449 ++
 ...c_c6_k5888_r3_e6912_sbd_teq_negllr_scatter.data | 2451 ++
 .../turbo_enc_c1_k456_r0_e1380_scatter.data|   44 +
 ...urbo_enc_c3_k4352_r0_e13068_crc24b_scatter.data |  328 +++
 app/test-bbdev/turbo_enc_default.data  |2 +-
 config/common_base |9 +-
 doc/guides/bbdevs/fpga_lte_fec.rst |  318 +++
 doc/guides/bbdevs/index.rst|1 +
 doc/guides/bbdevs/turbo_sw.rst |   57 +-
 doc/guides/prog_guide/bbdev.rst|  509 +++-
 doc/guides/tools/testbbdev.rst |  125 +-
 drivers/baseband/Makefile  |2 +
 drivers/baseband/fpga_lte_fec/Makefile |   29 +
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c   | 2671 
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.h   |   73 +
 .../baseband/fpga_lte_fec/fpga_lte_fec_version.map |3 +
 drivers/baseband/turbo_sw/Makefile |   15 +-
 drivers/baseband/turbo_sw/bbdev_turbo_software.c   |  707 +-
 lib/librte_bbdev/rte_bbdev.c   |   22 +-
 lib/librte_bbdev/rte_bbdev.h   |  137 +-
 lib/librte_bbdev/rte_bbdev_op.h|  577 -
 mk/rte.app.mk  |9 +-
 usertools/dpdk-devbind.py  |   10 +-
 usertools/dpdk-setup.sh|6 +-
 68 files changed, 26858 insertions(+), 404 deletions(-)
 create mode 1006

[dpdk-dev] [PATCH 5/5] usertools: update to usertool to allow binding of baseband device

[Nic Chautru]

From: Nicolas Chautru 

 Signed-off-by: Nic Chautru 
---
 usertools/dpdk-devbind.py | 10 +-
 usertools/dpdk-setup.sh   |  6 +++---
 2 files changed, 12 insertions(+), 4 deletions(-)
 mode change 100755 => 100644 usertools/dpdk-devbind.py
 mode change 100755 => 100644 usertools/dpdk-setup.sh

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
old mode 100755
new mode 100644
index 9e79f0d..a6ee8f9
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -18,6 +18,8 @@
'SVendor': None, 'SDevice': None}
 intel_processor_class = {'Class': '0b', 'Vendor': '8086', 'Device': None,
'SVendor': None, 'SDevice': None}
+acceleration_class = {'Class': '12', 'Vendor': None, 'Device': None,
+   'SVendor': None, 'SDevice': None}
 cavium_sso = {'Class': '08', 'Vendor': '177d', 'Device': 'a04b,a04d',
   'SVendor': None, 'SDevice': None}
 cavium_fpa = {'Class': '08', 'Vendor': '177d', 'Device': 'a053',
@@ -40,6 +42,7 @@
 crypto_devices = [encryption_class, intel_processor_class]
 eventdev_devices = [cavium_sso, cavium_tim, octeontx2_sso]
 mempool_devices = [cavium_fpa, octeontx2_npa]
+baseband_devices = [acceleration_class]
 compress_devices = [cavium_zip]
 
 # global dict ethernet devices present. Dictionary indexed by PCI address.
@@ -89,7 +92,7 @@ def usage():
 
 --status-dev:
 Print the status of given device group. Supported device groups are:
-"net", "crypto", "event", "mempool" and "compress"
+"net", "crypto", "baseband", "event", "mempool" and "compress"
 
 -b driver, --bind=driver:
 Select the driver to use or \"none\" to unbind the device
@@ -586,6 +589,9 @@ def show_status():
 if status_dev == "crypto" or status_dev == "all":
 show_device_status(crypto_devices, "Crypto")
 
+if status_dev == "baseband" or status_dev == "all":
+show_device_status(baseband_devices, "Baseband")
+
 if status_dev == "event" or status_dev == "all":
 show_device_status(eventdev_devices, "Eventdev")
 
@@ -667,6 +673,7 @@ def do_arg_actions():
 # refresh if we have changed anything
 get_device_details(network_devices)
 get_device_details(crypto_devices)
+get_device_details(baseband_devices)
 get_device_details(eventdev_devices)
 get_device_details(mempool_devices)
 get_device_details(compress_devices)
@@ -688,6 +695,7 @@ def main():
 get_device_details(network_devices)
 get_device_details(crypto_devices)
 get_device_details(eventdev_devices)
+get_device_details(baseband_devices)
 get_device_details(mempool_devices)
 get_device_details(compress_devices)
 do_arg_actions()
diff --git a/usertools/dpdk-setup.sh b/usertools/dpdk-setup.sh
old mode 100755
new mode 100644
index d008074..15f91b8
--- a/usertools/dpdk-setup.sh
+++ b/usertools/dpdk-setup.sh
@@ -496,13 +496,13 @@ step2_func()
TEXT[5]="Setup hugepage mappings for NUMA systems"
FUNC[5]="set_numa_pages"
 
-   TEXT[6]="Display current Ethernet/Crypto device settings"
+   TEXT[6]="Display current Ethernet/Crypto/Baseband device settings"
FUNC[6]="show_devices"
 
-   TEXT[7]="Bind Ethernet/Crypto device to IGB UIO module"
+   TEXT[7]="Bind Ethernet/Crypto/Baseband device to IGB UIO module"
FUNC[7]="bind_devices_to_igb_uio"
 
-   TEXT[8]="Bind Ethernet/Crypto device to VFIO module"
+   TEXT[8]="Bind Ethernet/Crypto/Baseband device to VFIO module"
FUNC[8]="bind_devices_to_vfio"
 
TEXT[9]="Setup VFIO permissions"
-- 
1.8.3.1

[dpdk-dev] [PATCH 1/5] baseband/fpga_lte_fec: addition of driver for 4G turbo FEC with PAC N300 FPGA card

[Nic Chautru]

From: Nicolas Chautru 

---
 config/common_base |6 +
 doc/guides/bbdevs/fpga_lte_fec.rst |  318 +++
 doc/guides/bbdevs/index.rst|1 +
 drivers/baseband/Makefile  |2 +
 drivers/baseband/fpga_lte_fec/Makefile |   29 +
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c   | 2671 
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.h   |   73 +
 .../baseband/fpga_lte_fec/fpga_lte_fec_version.map |3 +
 mk/rte.app.mk  |1 +
 9 files changed, 3104 insertions(+)
 create mode 100644 doc/guides/bbdevs/fpga_lte_fec.rst
 create mode 100644 drivers/baseband/fpga_lte_fec/Makefile
 create mode 100644 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
 create mode 100644 drivers/baseband/fpga_lte_fec/fpga_lte_fec.h
 create mode 100644 drivers/baseband/fpga_lte_fec/fpga_lte_fec_version.map

diff --git a/config/common_base b/config/common_base
index 6b96e0e..ae52028 100644
--- a/config/common_base
+++ b/config/common_base
@@ -521,6 +521,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
 # EXPERIMENTAL: API may change without prior notice
 #
 CONFIG_RTE_LIBRTE_BBDEV=y
+CONFIG_RTE_LIBRTE_BBDEV_DEBUG=n
 CONFIG_RTE_BBDEV_MAX_DEVS=128
 CONFIG_RTE_BBDEV_OFFLOAD_COST=y
 
@@ -535,6 +536,11 @@ CONFIG_RTE_LIBRTE_PMD_BBDEV_NULL=y
 CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW=n
 
 #
+# Compile PMD for Intel FPGA LTE FEC bbdev device
+#
+CONFIG_RTE_LIBRTE_PMD_FPGA_LTE_FEC=y
+
+#
 # Compile generic crypto device library
 #
 CONFIG_RTE_LIBRTE_CRYPTODEV=y
diff --git a/doc/guides/bbdevs/fpga_lte_fec.rst 
b/doc/guides/bbdevs/fpga_lte_fec.rst
new file mode 100644
index 000..066907d
--- /dev/null
+++ b/doc/guides/bbdevs/fpga_lte_fec.rst
@@ -0,0 +1,318 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2018 Intel Corporation
+
+Intel(R) FPGA LTE FEC Poll Mode Driver
+==
+
+The BBDEV FPGA LTE FEC poll mode driver (PMD) supports an FPGA implementation 
of a VRAN
+Turbo Encode / Decode LTE wireless acceleration function, using Intel's PCI-e 
and FPGA
+based Vista Creek device.
+
+Features
+
+
+FPGA LTE FEC PMD supports the following features:
+
+- Turbo Encode in the DL with total throughput of 4.5 Gbits/s
+- Turbo Decode in the UL with total throughput of 1.5 Gbits/s assuming 8 
decoder iterations
+- 8 VFs per PF (physical device)
+- Maximum of 32 UL queues per VF
+- Maximum of 32 DL queues per VF
+- PCIe Gen-3 x8 Interface
+- MSI-X
+- SR-IOV
+
+
+FPGA LTE FEC PMD supports the following BBDEV capabilities:
+
+* For the turbo encode operation:
+   - ``RTE_BBDEV_TURBO_CRC_24B_ATTACH`` :  set to attach CRC24B to CB(s)
+   - ``RTE_BBDEV_TURBO_RATE_MATCH`` :  if set then do not do Rate Match bypass
+   - ``RTE_BBDEV_TURBO_ENC_INTERRUPTS`` :  set for encoder dequeue interrupts
+
+
+* For the turbo decode operation:
+   - ``RTE_BBDEV_TURBO_CRC_TYPE_24B`` :  check CRC24B from CB(s)
+   - ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE`` :  perform subblock 
de-interleave
+   - ``RTE_BBDEV_TURBO_DEC_INTERRUPTS`` :  set for decoder dequeue interrupts
+   - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN`` :  set if negative LLR encoder i/p 
is supported
+   - ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP`` :  keep CRC24B bits appended 
while decoding
+
+
+Limitations
+---
+
+FPGA LTE FEC does not support the following:
+
+- Scatter-Gather function
+
+
+Installation
+--
+
+Section 3 of the DPDK manual provides instuctions on installing and compiling 
DPDK. The
+default set of bbdev compile flags may be found in config/common_base, where 
for example
+the flag to build the FPGA LTE FEC device, 
``CONFIG_RTE_LIBRTE_PMD_FPGA_LTE_FEC``, is already
+set. It is assumed DPDK has been compiled for an icc 64-bit target using:
+
+.. code-block:: console
+
+  make install T=x86_64-native-linuxapp-icc
+
+
+DPDK requires hugepages to be configured as detailed in section 2 of the DPDK 
manual.
+The bbdev test application has been tested with a configuration 40 x 1GB 
hugepages. The
+hugepage configuration of a server may be examined using:
+
+.. code-block:: console
+
+   grep Huge* /proc/meminfo
+
+
+Initialization
+--
+
+When the device first powers up, its PCI Physical Functions (PF) can be listed 
through this command:
+
+.. code-block:: console
+
+  sudo lspci -vd1172:5052
+
+The physical and virtual functions are compatible with Linux UIO drivers:
+``vfio`` and ``igb_uio``. However, in order to work the FPGA LTE FEC device 
firstly needs
+to be bound to one of these linux drivers through DPDK.
+
+
+Bind PF UIO driver(s)
+~
+
+Install the DPDK igb_uio driver, bind it with the PF PCI device ID and use
+``lspci`` to confirm the PF device is under use by ``igb_uio`` DPDK UIO driver.
+
+The igb_uio driver may be bound to the PF PCI device using one of three 
methods:
+
+
+1. PCI functions (physical or virtual, depending on the use case) can

[dpdk-dev] [PATCH 3/5] baseband/turbo_sw : Extension of turbo_sw for 5G FEC

[Nic Chautru]

From: Nicolas Chautru 

Signed-off-by: Nic Chautru 
---
 app/test-bbdev/test_bbdev_vector.c   |   4 +-
 app/test-bbdev/test_bbdev_vector.h   |   2 +-
 config/common_base   |   3 +-
 doc/guides/bbdevs/turbo_sw.rst   |  57 +-
 drivers/baseband/turbo_sw/Makefile   |  15 +-
 drivers/baseband/turbo_sw/bbdev_turbo_software.c | 679 ++-
 mk/rte.app.mk|   8 +-
 7 files changed, 731 insertions(+), 37 deletions(-)

diff --git a/app/test-bbdev/test_bbdev_vector.c 
b/app/test-bbdev/test_bbdev_vector.c
index e4f68e2..e149ced 100644
--- a/app/test-bbdev/test_bbdev_vector.c
+++ b/app/test-bbdev/test_bbdev_vector.c
@@ -298,9 +298,9 @@
op_data = vector->entries[type].segments;
nb_ops = &vector->entries[type].nb_segments;
 
-   if (*nb_ops >= RTE_BBDEV_MAX_CODE_BLOCKS) {
+   if (*nb_ops >= RTE_BBDEV_TURBO_MAX_CODE_BLOCKS) {
printf("Too many segments (code blocks defined): %u, max %d!\n",
-   *nb_ops, RTE_BBDEV_MAX_CODE_BLOCKS);
+   *nb_ops, RTE_BBDEV_TURBO_MAX_CODE_BLOCKS);
return -1;
}
 
diff --git a/app/test-bbdev/test_bbdev_vector.h 
b/app/test-bbdev/test_bbdev_vector.h
index 476aae1..c85e94d 100644
--- a/app/test-bbdev/test_bbdev_vector.h
+++ b/app/test-bbdev/test_bbdev_vector.h
@@ -46,7 +46,7 @@ struct op_data_buf {
 };
 
 struct op_data_entries {
-   struct op_data_buf segments[RTE_BBDEV_MAX_CODE_BLOCKS];
+   struct op_data_buf segments[RTE_BBDEV_TURBO_MAX_CODE_BLOCKS];
unsigned int nb_segments;
 };
 
diff --git a/config/common_base b/config/common_base
index ae52028..78e41f2 100644
--- a/config/common_base
+++ b/config/common_base
@@ -523,7 +523,8 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
 CONFIG_RTE_LIBRTE_BBDEV=y
 CONFIG_RTE_LIBRTE_BBDEV_DEBUG=n
 CONFIG_RTE_BBDEV_MAX_DEVS=128
-CONFIG_RTE_BBDEV_OFFLOAD_COST=y
+CONFIG_RTE_BBDEV_OFFLOAD_COST=n
+CONFIG_RTE_LIBRTE_PMD_BBDEV_AVX512=n
 
 #
 # Compile PMD for NULL bbdev device
diff --git a/doc/guides/bbdevs/turbo_sw.rst b/doc/guides/bbdevs/turbo_sw.rst
index 29f7ec9..e67ecc4 100644
--- a/doc/guides/bbdevs/turbo_sw.rst
+++ b/doc/guides/bbdevs/turbo_sw.rst
@@ -1,26 +1,26 @@
 ..  SPDX-License-Identifier: BSD-3-Clause
 Copyright(c) 2017 Intel Corporation
 
-SW Turbo Poll Mode Driver
+SW FEC Poll Mode Driver
 =
 
-The SW Turbo PMD (**baseband_turbo_sw**) provides a poll mode bbdev driver 
that utilizes
-Intel optimized libraries for LTE Layer 1 workloads acceleration. This PMD
-supports the functions: Turbo FEC, Rate Matching and CRC functions.
+The SW FEC PMD (**baseband_turbo_sw**) provides a poll mode bbdev driver that 
utilizes
+Intel optimized libraries for LTE and 5GNR Layer 1 workloads acceleration. 
This PMD
+supports the functions: FEC, Rate Matching and CRC functions.
 
 Features
 
 
-SW Turbo PMD has support for the following capabilities:
+SW FEC PMD has support for the following capabilities:
 
-For the encode operation:
+For the LTE encode operation:
 
 * ``RTE_BBDEV_TURBO_CRC_24A_ATTACH``
 * ``RTE_BBDEV_TURBO_CRC_24B_ATTACH``
 * ``RTE_BBDEV_TURBO_RATE_MATCH``
 * ``RTE_BBDEV_TURBO_RV_INDEX_BYPASS``
 
-For the decode operation:
+For the LTE decode operation:
 
 * ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE``
 * ``RTE_BBDEV_TURBO_CRC_TYPE_24B``
@@ -29,11 +29,25 @@ For the decode operation:
 * ``RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP``
 * ``RTE_BBDEV_TURBO_EARLY_TERMINATION``
 
+For the LDPC encode operation:
+
+* ``RTE_BBDEV_LDPC_RATE_MATCH``
+* ``RTE_BBDEV_LDPC_CRC_24A_ATTACH``
+* ``RTE_BBDEV_LDPC_CRC_24B_ATTACH``
+
+For the LDPC decode operation:
+
+* ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK``
+* ``RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK``
+* ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP``
+* ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE``
+* ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE``
+* ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE``
 
 Limitations
 ---
 
-* In-place operations for Turbo encode and decode are not supported
+* In-place operations for encode and decode are not supported
 
 Installation
 
@@ -65,14 +79,14 @@ The following table maps DPDK versions with past FlexRAN 
SDK releases:
18.02  1.3.0
18.05  1.4.0
18.08  1.6.0
-   19.02  18.09
+   18.08-Patch19.04
=  
 
 FlexRAN SDK Installation
 
 
 The following are pre-requisites for building FlexRAN SDK Libraries:
- (a) An AVX2 supporting machine
+ (a) An AVX512 supporting machine
  (b) CentOS Linux release 7.2.1511 (Core) operating system
  (c) Intel ICC 18.0.1 20171018 compiler installed
 
@@ -84,25 +98,25 @@ The following instructions should be followed in this exact 
order:
 
 source /linux/bin/compilervars.sh 
intel64 -platform linux
 
-#. Extract the ``605167-f

[dpdk-dev] [PATCH 2/5] bbdev : Extension of BBDEV for 5G FEC

[Nic Chautru]

From: Nicolas Chautru 

Signed-off-by: Nic Chautru 
---
 doc/guides/prog_guide/bbdev.rst  | 509 ++--
 drivers/baseband/fpga_lte_fec/fpga_lte_fec.c |  24 +-
 drivers/baseband/turbo_sw/bbdev_turbo_software.c |  36 +-
 lib/librte_bbdev/rte_bbdev.c |  22 +-
 lib/librte_bbdev/rte_bbdev.h | 137 +-
 lib/librte_bbdev/rte_bbdev_op.h  | 577 ++-
 6 files changed, 1091 insertions(+), 214 deletions(-)

diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 658ffd4..d862260 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev 
device consists of
 one or more queues identified by queue IDs. While different devices may have
 different capabilities (e.g. support different operation types), all queues on
 a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initialization time.
+for only one type of operation and is configured at initializations time.
 When an operation is enqueued to a specific queue ID, the result is dequeued
 from the same queue ID.
 
@@ -91,8 +91,7 @@ and queue configuration is applied with
 ``rte_bbdev_queue_configure(dev_id,queue_id,conf)``. Note that, although all
 queues on a device support same capabilities, they can be configured 
differently
 and will then behave differently.
-Devices supporting interrupts can enable them by using
-``rte_bbdev_intr_enable(dev_id)``.
+Devices supporting interrupts can enable them by using 
``rte_bbdev_intr_enable(dev_id)``.
 
 The configuration of each bbdev device includes the following operations:
 
@@ -150,8 +149,6 @@ device. Once closed, it cannot be restarted.
 int rte_bbdev_start(uint16_t dev_id)
 int rte_bbdev_stop(uint16_t dev_id)
 int rte_bbdev_close(uint16_t dev_id)
-int rte_bbdev_queue_start(uint16_t dev_id, uint16_t queue_id)
-int rte_bbdev_queue_stop(uint16_t dev_id, uint16_t queue_id)
 
 
 By default, all queues are started when the device is started, but they can be
@@ -166,9 +163,9 @@ stopped individually.
 Logical Cores, Memory and Queues Relationships
 ~~
 
-The bbdev device Library as the Poll Mode Driver library support NUMA for when
-a processor's logical cores and interfaces utilize its local memory. Therefore
-baseband operations, the mbuf being operated on should be allocated from memory
+The bbdev poll mode device driver library supports NUMA architecture, in which
+a processor's logical cores and interfaces utilize it's local memory. Therefore
+with baseband operations, the mbuf being operated on should be allocated from 
memory
 pools created in the local memory. The buffers should, if possible, remain on
 the local processor to obtain the best performance results and buffer
 descriptors should be populated with mbufs allocated from a mempool allocated
@@ -220,9 +217,9 @@ relation to Turbo Encoding and Decoding operations.
 RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
 RTE_BBDEV_TURBO_EARLY_TERMINATION,
 .max_llr_modulus = 16,
-.num_buffers_src = RTE_BBDEV_MAX_CODE_BLOCKS,
+.num_buffers_src = RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
 .num_buffers_hard_out =
-RTE_BBDEV_MAX_CODE_BLOCKS,
+RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
 .num_buffers_soft_out = 0,
 }
 },
@@ -234,8 +231,8 @@ relation to Turbo Encoding and Decoding operations.
 RTE_BBDEV_TURBO_CRC_24A_ATTACH |
 RTE_BBDEV_TURBO_RATE_MATCH |
 RTE_BBDEV_TURBO_RV_INDEX_BYPASS,
-.num_buffers_src = RTE_BBDEV_MAX_CODE_BLOCKS,
-.num_buffers_dst = RTE_BBDEV_MAX_CODE_BLOCKS,
+.num_buffers_src = RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+.num_buffers_dst = RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
 }
 },
 RTE_BBDEV_END_OF_CAPABILITIES_LIST()
@@ -266,12 +263,13 @@ information:
 struct rte_bbdev_info {
 int socket_id;
 const char *dev_name;
-const struct rte_bus *bus;
+const struct rte_device *device;
 uint16_t num_queues;
 bool started;
 struct rte_bbdev_driver_info drv;
 };
 
+
 Operation Processing
 
 
@@ -335,14 +333,20 @@ processed on a particular bbdev device poll mode driver.
 int status;
 struct rte_mempool *mempool;
 void *opaque_data;
-struct rte_bbdev_op_turbo_enc turbo_enc;
+union {
+struct rte_bbdev_op_turbo_enc turbo_enc;
+struct rte_bbdev_op_ldpc_enc ldpc_enc;
+}
 };
 
 struct rte_bbdev_dec_op {
 int status;
 s