[dpdk-dev] [RFC 0/5] Introduce Intel FPGA BUS

[Rosen Xu]

Intel FPGA BUS in DPDK
-

RFC [1]: 
http://www.dpdk.org/ml/archives/dev/2018-March/092297.html
http://www.dpdk.org/ml/archives/dev/2018-March/092298.html
http://www.dpdk.org/ml/archives/dev/2018-March/092299.html
http://www.dpdk.org/ml/archives/dev/2018-March/092300.html
http://www.dpdk.org/ml/archives/dev/2018-March/092301.html

This patch set introduces Intel FPGA BUS support in DPDK.

Motivation
==

FPGA is used more and more widely in Cloud and NFV, one primary reason is that 
FPGA not only provide ASIC performance but also it's more flexible than ASIC. 
FPGA use Partial Reconfigure(PR) Parts of Bitstream to achieve its flexibility. 
Another reason is that one FPGA can be shared by different Users, and each User 
can use some of AFUs of One FPGA.

That means One FPGA Device Bitstream is divided into many Parts of 
Bitstream(each Part of Bitstream is defined as AFU-Accelerated Function Unit), 
and each AFU is a Hardware Acceleration Unit and it can dynamically Reload 
respectively.

Scope
=

The Intel FPGA BUS implementation is target towards various FPGA Devices use PR 
to provide many Acceleration Function. Specific PMDs may also bind to its AFU. 
And Applications don't care they are using ASIC Acceleration or FPGA AFU 
Acceleration.

Proposed Solution
=
 - Involve Rawdev to take FPGA Partial Configuration(Download/PR)
 - Defined FPGA-BUS for Acceleration Drivers of AFUs
   - FPGA PCI Scan(1st Scan) follows DPDK UIO/VFIO PCI Scan Process, probe 
Intel FPGA Rawdev Driver
   - AFU Scan(2nd Scan) bind DPDK Driver to FPGA Partial-Bitstream

Status
=
With integrating Intel PSG FPGA Software Stack OPAE(Open Programmable 
Acceleration Engine) Share Code, Intel FPGA BUS runs well in Intel PSG FPGA 
Cards.

Patch set Information


This patch set includes 6 patches:
* 0  : Introduce the Intel FPGA BUS library and enable its compilation.
* 1  : Adds command parse code, for start-up application with Intel FPGA BUS.
* 2  : Adds Driver Probe Code, for AFU Drivers should probed after PCI Drivers.
* 3  : Adds Intel FPGA BUS library code, for AFU Device scan and AFU Drivers 
probe.
* 4  : Adds a Intel FPGA rawdevice driver, for FPGA Device Management such as 
PR.
* 5  : Adds Intel OPAE(Open Programmable Acceleration Engine) Share Code, it's 
Intel FPGA Software Stack.

Rosen Xu (5):
  Add Intel FPGA BUS Command Parse Code
  Add Intel FPGA BUS Probe Code
  Add Intel FPGA BUS Lib Code
  Add Intel FPGA BUS Rawdev Code
  Add Intel OPAE Share Code

 drivers/bus/ifpga/Makefile |   64 +
 drivers/bus/ifpga/ifpga_bus.c  |  573 +++
 drivers/bus/ifpga/ifpga_common.c   |  154 ++
 drivers/bus/ifpga/ifpga_common.h   |   25 +
 drivers/bus/ifpga/ifpga_logs.h |   32 +
 drivers/bus/ifpga/rte_bus_ifpga.h  |  141 ++
 drivers/bus/ifpga/rte_bus_ifpga_version.map|8 +
 drivers/raw/ifpga_rawdev/Makefile  |   63 +
 drivers/raw/ifpga_rawdev/base/Makefile |   54 +
 drivers/raw/ifpga_rawdev/base/ifpga_api.c  |  420 +
 drivers/raw/ifpga_rawdev/base/ifpga_api.h  |   78 +
 drivers/raw/ifpga_rawdev/base/ifpga_compat.h   |   85 +
 drivers/raw/ifpga_rawdev/base/ifpga_defines.h  | 1699 
 drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c|  808 ++
 drivers/raw/ifpga_rawdev/base/ifpga_enumerate.h|   39 +
 drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c  |  305 
 drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h  |  197 +++
 drivers/raw/ifpga_rawdev/base/ifpga_fme.c  |  731 +
 drivers/raw/ifpga_rawdev/base/ifpga_fme_dperf.c|  297 
 drivers/raw/ifpga_rawdev/base/ifpga_fme_error.c|  399 +
 drivers/raw/ifpga_rawdev/base/ifpga_fme_iperf.c|  711 
 drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c   |  364 +
 drivers/raw/ifpga_rawdev/base/ifpga_hw.h   |  145 ++
 drivers/raw/ifpga_rawdev/base/ifpga_port.c |  699 
 drivers/raw/ifpga_rawdev/base/ifpga_port_error.c   |  112 ++
 drivers/raw/ifpga_rawdev/base/opae_debug.c |   95 ++
 drivers/raw/ifpga_rawdev/base/opae_debug.h |   15 +
 drivers/raw/ifpga_rawdev/base/opae_hw_api.c|  355 
 drivers/raw/ifpga_rawdev/base/opae_hw_api.h|  235 +++
 drivers/raw/ifpga_rawdev/base/opae_ifpga_hw_api.c  |  120 ++
 drivers/raw/ifpga_rawdev/base/opae_ifpga_hw_api.h  |  253 +++
 drivers/raw/ifpga_rawdev/base/opae_osdep.h |   87 +
 .../ifpga_rawdev/base/osdep_raw/osdep_generic.h|   69 +
 .../ifpga_rawdev/base/osdep_rte/osdep_generic.h|   41 +
 drivers/raw/ifpga_rawdev/ifpga_rawdev.c|  472 ++
 drivers/raw/ifpga_rawdev/ifpga_rawdev.h|   38 +
 drivers/raw/ifpga_rawdev/ifpga_rawdev_example.c|   99 ++
 .../ifpga_rawdev/rte_pmd_ifpga_rawdev_version.map  |4 +
 lib/librte_eal/common/eal_common_

Re: [dpdk-dev] [PATCH v2 6/8] net/mrvl: add extended statistics

[Tomasz Duszynski]

On Wed, Mar 14, 2018 at 05:21:07PM +, Ferruh Yigit wrote:
> On 3/12/2018 8:42 AM, Tomasz Duszynski wrote:
> > Add extended statistics implementation.
> >
> > Signed-off-by: Natalie Samsonov 
> > Signed-off-by: Tomasz Duszynski 
>
> <...>
>
> > @@ -1674,6 +1784,94 @@ mrvl_eth_filter_ctrl(struct rte_eth_dev *dev 
> > __rte_unused,
> > }
> >  }
> >
> > +/**
> > + * DPDK callback to get xstats by id.
> > + *
> > + * @param dev
> > + *   Pointer to the device structure.
> > + * @param ids
> > + *   Pointer to the ids table.
> > + * @param values
> > + *   Pointer to the values table.
> > + * @param n
> > + *   Values table size.
> > + * @returns
> > + *   Number of read values, negative value otherwise.
> > + */
> > +static int
> > +mrvl_xstats_get_by_id(struct rte_eth_dev *dev, const uint64_t *ids,
> > + uint64_t *values, unsigned int n)
> > +{
> > +   unsigned int i, num = RTE_DIM(mrvl_xstats_tbl);
> > +   uint64_t vals[n];
> > +   int ret;
> > +
> > +   if (!ids) {
>
> You will not get NULL ids, this case covered by ethdev layer, for both by_id()
> functions.
>
> > +   struct rte_eth_xstat xstats[num];
> > +   int j;
> > +
> > +   ret = mrvl_xstats_get(dev, xstats, num);
> > +   for (j = 0; j < ret; i++)
> > +   values[j] = xstats[j].value;
> > +
> > +   return ret;
> > +   }
> > +
> > +   ret = mrvl_xstats_get_by_id(dev, NULL, vals, n);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   for (i = 0; i < n; i++) {
> > +   if (ids[i] >= num) {
> > +   RTE_LOG(ERR, PMD, "id value is not valid\n");
> > +   return -1;
> > +   }
> > +
> > +   values[i] = vals[ids[i]];
> > +   }
> > +
> > +   return n;
> > +}
> > +
> > +/**
> > + * DPDK callback to get xstats names by ids.
> > + *
> > + * @param dev
> > + *   Pointer to the device structure.
> > + * @param xstats_names
> > + *   Pointer to table with xstats names.
> > + * @param ids
> > + *   Pointer to table with ids.
> > + * @param size
> > + *   Xstats names table size.
> > + * @returns
> > + *   Number of names read, negative value otherwise.
> > + */
> > +static int
> > +mrvl_xstats_get_names_by_id(struct rte_eth_dev *dev,
> > +   struct rte_eth_xstat_name *xstats_names,
> > +   const uint64_t *ids, unsigned int size)
> > +{
> > +   unsigned int i, num = RTE_DIM(mrvl_xstats_tbl);
> > +   struct rte_eth_xstat_name names[num];
> > +
> > +   if (!ids)
> > +   return mrvl_xstats_get_names(dev, xstats_names, size);
> > +
> > +   mrvl_xstats_get_names(dev, names, size);
> > +   for (i = 0; i < size; i++) {
> > +   if (ids[i] >= num) {
> > +   RTE_LOG(ERR, PMD, "id value is not valid");
> > +   return -1;
> > +   }
> > +
> > +   snprintf(xstats_names[i].name, RTE_ETH_XSTATS_NAME_SIZE,
> > +"%s", names[ids[i]].name);
> > +   }
> > +
> > +   return size;
> > +}
>
> Specific to *_by_id() implementations, please check ethdev layer APIs for 
> these
> devops, they already do same thing as you did here.
>
> These devops are to access specific ids efficiently with support of PMD, if 
> you
> don't have a quick way to access to an extended stat by id, you may just left
> these unimplemented and abstraction layer will do the work for you, it is up 
> to you.

Good point. Since *_by_id() are using xstats_get_names()/xstats_get()
anyway they do not provide a real speedup. I'll drop that in v3.

>
>
> Thanks,
> ferruh

--
- Tomasz Duszyński

[dpdk-dev] [PATCH v3 0/8] net/mrvl: add new features to PMD

[Tomasz Duszynski]

This patch series comes along with a set of features,
documentation updates and fixes.

Below one can find a short summary of introduced changes:

o Added support for selective Tx queue start and stop.
o Added support for Rx flow control.
o Added support for extended statistics counters.
o Added support for ingress policer, egress scheduler and egress rate
  limiter.
o Added support for configuring hardware classifier via a flow API.
o Documented new features and their usage.

Natalie Samsonov (1):
  net/mrvl: fix crash when port is closed without starting

Tomasz Duszynski (7):
  net/mrvl: add ingress policer support
  net/mrvl: add egress scheduler/rate limiter support
  net/mrvl: document policer/scheduler/rate limiter usage
  net/mrvl: add classifier support
  net/mrvl: add extended statistics
  net/mrvl: add Rx flow control
  net/mrvl: add Tx queue start/stop

v3:
- Remove *_by_id() ops from xstats since they are handled by ether layer.

v2:
- Convert license header of a new file to SPDX tags.

 doc/guides/nics/features/mrvl.ini |2 +
 doc/guides/nics/mrvl.rst  |  257 +++-
 drivers/net/mrvl/Makefile |1 +
 drivers/net/mrvl/mrvl_ethdev.c|  357 -
 drivers/net/mrvl/mrvl_ethdev.h|   11 +
 drivers/net/mrvl/mrvl_flow.c  | 2759 +
 drivers/net/mrvl/mrvl_qos.c   |  301 +++-
 drivers/net/mrvl/mrvl_qos.h   |   22 +
 8 files changed, 3692 insertions(+), 18 deletions(-)
 create mode 100644 drivers/net/mrvl/mrvl_flow.c

--
2.7.4

[dpdk-dev] [PATCH v3 1/8] net/mrvl: fix crash when port is closed without starting

[Tomasz Duszynski]

From: Natalie Samsonov 

Fixes: 0ddc9b815b11 ("net/mrvl: add net PMD skeleton")
Cc: sta...@dpdk.org

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 drivers/net/mrvl/mrvl_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index ac8f2d6..e313768 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -658,7 +658,8 @@ mrvl_dev_stop(struct rte_eth_dev *dev)
pp2_cls_qos_tbl_deinit(priv->qos_tbl);
priv->qos_tbl = NULL;
}
-   pp2_ppio_deinit(priv->ppio);
+   if (priv->ppio)
+   pp2_ppio_deinit(priv->ppio);
priv->ppio = NULL;
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH v3 4/8] net/mrvl: document policer/scheduler/rate limiter usage

[Tomasz Duszynski]

Add documentation and example for ingress policer, egress scheduler
and egress rate limiter.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 doc/guides/nics/mrvl.rst | 86 
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/doc/guides/nics/mrvl.rst b/doc/guides/nics/mrvl.rst
index b7f3292..6794cbb 100644
--- a/doc/guides/nics/mrvl.rst
+++ b/doc/guides/nics/mrvl.rst
@@ -149,17 +149,36 @@ Configuration syntax
[port  default]
default_tc = 
mapping_priority = 
+   policer_enable = 
+   token_unit = 
+   color = 
+   cir = 
+   ebs = 
+   cbs = 
+
+   rate_limit_enable = 
+   rate_limit = 
+   burst_size = 
 
[port  tc ]
rxq = 
pcp = 
dscp = 
+   default_color = 
 
[port  tc ]
rxq = 
pcp = 
dscp = 
 
+   [port  txq ]
+   sched_mode = 
+   wrr_weight = 
+
+   rate_limit_enable = 
+   rate_limit = 
+   burst_size = 
+
 Where:
 
 - : DPDK Port number (0..n).
@@ -176,6 +195,30 @@ Where:
 
 - : List of DSCP values to handle in particular TC (e.g. 0-12 
32-48 63).
 
+- : Enable ingress policer.
+
+- : Policer token unit (`bytes` or `packets`).
+
+- : Policer color mode (`aware` or `blind`).
+
+- : Committed information rate in unit of kilo bits per second (data 
rate) or packets per second.
+
+- : Committed burst size in unit of kilo bytes or number of packets.
+
+- : Excess burst size in unit of kilo bytes or number of packets.
+
+- : Default color for specific tc.
+
+- : Enables per port or per txq rate limiting.
+
+- : Committed information rate, in kilo bits per second.
+
+- : Committed burst size, in kilo bytes.
+
+- : Egress scheduler mode (`wrr` or `sp`).
+
+- : Txq weight.
+
 Setting PCP/DSCP values for the default TC is not required. All PCP/DSCP
 values not assigned explicitly to particular TC will be handled by the
 default TC.
@@ -187,11 +230,26 @@ Configuration file example
 
[port 0 default]
default_tc = 0
-   qos_mode = ip
+   mapping_priority = ip
+
+   rate_limit_enable = 1
+   rate_limit = 1000
+   burst_size = 2000
 
[port 0 tc 0]
rxq = 0 1
 
+   [port 0 txq 0]
+   sched_mode = wrr
+   wrr_weight = 10
+
+   [port 0 txq 1]
+   sched_mode = wrr
+   wrr_weight = 100
+
+   [port 0 txq 2]
+   sched_mode = sp
+
[port 0 tc 1]
rxq = 2
pcp = 5 6 7
@@ -199,15 +257,31 @@ Configuration file example
 
[port 1 default]
default_tc = 0
-   qos_mode = vlan/ip
+   mapping_priority = vlan/ip
+
+   policer_enable = 1
+   token_unit = bytes
+   color = blind
+   cir = 10
+   ebs = 64
+   cbs = 64
 
[port 1 tc 0]
rxq = 0
+   dscp = 10
 
[port 1 tc 1]
-   rxq = 1 2
-   pcp = 5 6 7
-   dscp = 26-38
+   rxq = 1
+   dscp = 11-20
+
+   [port 1 tc 2]
+   rxq = 2
+   dscp = 30
+
+   [port 1 txq 0]
+   rate_limit_enable = 1
+   rate_limit = 1
+   burst_size = 2000
 
 Usage example
 ^
@@ -215,7 +289,7 @@ Usage example
 .. code-block:: console
 
./testpmd --vdev=eth_mrvl,iface=eth0,iface=eth2,cfg=/home/user/mrvl.conf \
- -c 7 -- -i -a --rxq=2
+ -c 7 -- -i -a --disable-hw-vlan-strip --rxq=3 --txq=3
 
 
 Building DPDK
-- 
2.7.4

[dpdk-dev] [PATCH v3 2/8] net/mrvl: add ingress policer support

[Tomasz Duszynski]

Add ingress policer support.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 drivers/net/mrvl/mrvl_ethdev.c |   6 ++
 drivers/net/mrvl/mrvl_ethdev.h |   1 +
 drivers/net/mrvl/mrvl_qos.c| 160 +++--
 drivers/net/mrvl/mrvl_qos.h|   3 +
 4 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index e313768..d1faa3d 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -661,6 +661,12 @@ mrvl_dev_stop(struct rte_eth_dev *dev)
if (priv->ppio)
pp2_ppio_deinit(priv->ppio);
priv->ppio = NULL;
+
+   /* policer must be released after ppio deinitialization */
+   if (priv->policer) {
+   pp2_cls_plcr_deinit(priv->policer);
+   priv->policer = NULL;
+   }
 }
 
 /**
diff --git a/drivers/net/mrvl/mrvl_ethdev.h b/drivers/net/mrvl/mrvl_ethdev.h
index aee853a..2cc229e 100644
--- a/drivers/net/mrvl/mrvl_ethdev.h
+++ b/drivers/net/mrvl/mrvl_ethdev.h
@@ -85,6 +85,7 @@ struct mrvl_priv {
struct pp2_cls_qos_tbl_params qos_tbl_params;
struct pp2_cls_tbl *qos_tbl;
uint16_t nb_rx_queues;
+   struct pp2_cls_plcr *policer;
 };
 
 #endif /* _MRVL_ETHDEV_H_ */
diff --git a/drivers/net/mrvl/mrvl_qos.c b/drivers/net/mrvl/mrvl_qos.c
index d206dc6..0205157 100644
--- a/drivers/net/mrvl/mrvl_qos.c
+++ b/drivers/net/mrvl/mrvl_qos.c
@@ -43,6 +43,22 @@
 #define MRVL_TOK_VLAN_IP "vlan/ip"
 #define MRVL_TOK_WEIGHT "weight"
 
+/* policer specific configuration tokens */
+#define MRVL_TOK_PLCR_ENABLE "policer_enable"
+#define MRVL_TOK_PLCR_UNIT "token_unit"
+#define MRVL_TOK_PLCR_UNIT_BYTES "bytes"
+#define MRVL_TOK_PLCR_UNIT_PACKETS "packets"
+#define MRVL_TOK_PLCR_COLOR "color_mode"
+#define MRVL_TOK_PLCR_COLOR_BLIND "blind"
+#define MRVL_TOK_PLCR_COLOR_AWARE "aware"
+#define MRVL_TOK_PLCR_CIR "cir"
+#define MRVL_TOK_PLCR_CBS "cbs"
+#define MRVL_TOK_PLCR_EBS "ebs"
+#define MRVL_TOK_PLCR_DEFAULT_COLOR "default_color"
+#define MRVL_TOK_PLCR_DEFAULT_COLOR_GREEN "green"
+#define MRVL_TOK_PLCR_DEFAULT_COLOR_YELLOW "yellow"
+#define MRVL_TOK_PLCR_DEFAULT_COLOR_RED "red"
+
 /** Number of tokens in range a-b = 2. */
 #define MAX_RNG_TOKENS 2
 
@@ -296,6 +312,25 @@ parse_tc_cfg(struct rte_cfgfile *file, int port, int tc,
}
cfg->port[port].tc[tc].dscps = n;
}
+
+   entry = rte_cfgfile_get_entry(file, sec_name,
+   MRVL_TOK_PLCR_DEFAULT_COLOR);
+   if (entry) {
+   if (!strncmp(entry, MRVL_TOK_PLCR_DEFAULT_COLOR_GREEN,
+   sizeof(MRVL_TOK_PLCR_DEFAULT_COLOR_GREEN))) {
+   cfg->port[port].tc[tc].color = PP2_PPIO_COLOR_GREEN;
+   } else if (!strncmp(entry, MRVL_TOK_PLCR_DEFAULT_COLOR_YELLOW,
+   sizeof(MRVL_TOK_PLCR_DEFAULT_COLOR_YELLOW))) {
+   cfg->port[port].tc[tc].color = PP2_PPIO_COLOR_YELLOW;
+   } else if (!strncmp(entry, MRVL_TOK_PLCR_DEFAULT_COLOR_RED,
+   sizeof(MRVL_TOK_PLCR_DEFAULT_COLOR_RED))) {
+   cfg->port[port].tc[tc].color = PP2_PPIO_COLOR_RED;
+   } else {
+   RTE_LOG(ERR, PMD, "Error while parsing: %s\n", entry);
+   return -1;
+   }
+   }
+
return 0;
 }
 
@@ -368,6 +403,88 @@ mrvl_get_qoscfg(const char *key __rte_unused, const char 
*path,
}
 
entry = rte_cfgfile_get_entry(file, sec_name,
+   MRVL_TOK_PLCR_ENABLE);
+   if (entry) {
+   if (get_val_securely(entry, &val) < 0)
+   return -1;
+   (*cfg)->port[n].policer_enable = val;
+   }
+
+   if ((*cfg)->port[n].policer_enable) {
+   enum pp2_cls_plcr_token_unit unit;
+
+   /* Read policer token unit */
+   entry = rte_cfgfile_get_entry(file, sec_name,
+   MRVL_TOK_PLCR_UNIT);
+   if (entry) {
+   if (!strncmp(entry, MRVL_TOK_PLCR_UNIT_BYTES,
+   sizeof(MRVL_TOK_PLCR_UNIT_BYTES))) {
+   unit = PP2_CLS_PLCR_BYTES_TOKEN_UNIT;
+   } else if (!strncmp(entry,
+   MRVL_TOK_PLCR_UNIT_PACKETS,
+   sizeof(MRVL_TOK_PLCR_UNIT_PACKETS))) {
+   unit = PP2_CLS_PLCR_PACKETS_TOKEN_UNIT;
+   } else {
+   RTE_LOG(ERR, PMD, "Unknown token: %s\n",
+   entry);
+   return -1;

[dpdk-dev] [PATCH v3 3/8] net/mrvl: add egress scheduler/rate limiter support

[Tomasz Duszynski]

Add egress scheduler and egress rate limiter support.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 drivers/net/mrvl/mrvl_ethdev.c |   6 +-
 drivers/net/mrvl/mrvl_qos.c| 141 +++--
 drivers/net/mrvl/mrvl_qos.h|  19 ++
 3 files changed, 161 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index d1faa3d..7e00dbd 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -320,6 +320,11 @@ mrvl_dev_configure(struct rte_eth_dev *dev)
if (ret < 0)
return ret;
 
+   ret = mrvl_configure_txqs(priv, dev->data->port_id,
+ dev->data->nb_tx_queues);
+   if (ret < 0)
+   return ret;
+
priv->ppio_params.outqs_params.num_outqs = dev->data->nb_tx_queues;
priv->ppio_params.maintain_stats = 1;
priv->nb_rx_queues = dev->data->nb_rx_queues;
@@ -1537,7 +1542,6 @@ mrvl_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
idx, uint16_t desc,
dev->data->tx_queues[idx] = txq;
 
priv->ppio_params.outqs_params.outqs_params[idx].size = desc;
-   priv->ppio_params.outqs_params.outqs_params[idx].weight = 1;
 
return 0;
 }
diff --git a/drivers/net/mrvl/mrvl_qos.c b/drivers/net/mrvl/mrvl_qos.c
index 0205157..e9c4531 100644
--- a/drivers/net/mrvl/mrvl_qos.c
+++ b/drivers/net/mrvl/mrvl_qos.c
@@ -36,12 +36,19 @@
 #define MRVL_TOK_PCP "pcp"
 #define MRVL_TOK_PORT "port"
 #define MRVL_TOK_RXQ "rxq"
-#define MRVL_TOK_SP "SP"
 #define MRVL_TOK_TC "tc"
 #define MRVL_TOK_TXQ "txq"
 #define MRVL_TOK_VLAN "vlan"
 #define MRVL_TOK_VLAN_IP "vlan/ip"
-#define MRVL_TOK_WEIGHT "weight"
+
+/* egress specific configuration tokens */
+#define MRVL_TOK_BURST_SIZE "burst_size"
+#define MRVL_TOK_RATE_LIMIT "rate_limit"
+#define MRVL_TOK_RATE_LIMIT_ENABLE "rate_limit_enable"
+#define MRVL_TOK_SCHED_MODE "sched_mode"
+#define MRVL_TOK_SCHED_MODE_SP "sp"
+#define MRVL_TOK_SCHED_MODE_WRR "wrr"
+#define MRVL_TOK_WRR_WEIGHT "wrr_weight"
 
 /* policer specific configuration tokens */
 #define MRVL_TOK_PLCR_ENABLE "policer_enable"
@@ -119,12 +126,69 @@ get_outq_cfg(struct rte_cfgfile *file, int port, int outq,
if (rte_cfgfile_num_sections(file, sec_name, strlen(sec_name)) <= 0)
return 0;
 
+   /* Read scheduling mode */
+   entry = rte_cfgfile_get_entry(file, sec_name, MRVL_TOK_SCHED_MODE);
+   if (entry) {
+   if (!strncmp(entry, MRVL_TOK_SCHED_MODE_SP,
+   strlen(MRVL_TOK_SCHED_MODE_SP))) {
+   cfg->port[port].outq[outq].sched_mode =
+   PP2_PPIO_SCHED_M_SP;
+   } else if (!strncmp(entry, MRVL_TOK_SCHED_MODE_WRR,
+   strlen(MRVL_TOK_SCHED_MODE_WRR))) {
+   cfg->port[port].outq[outq].sched_mode =
+   PP2_PPIO_SCHED_M_WRR;
+   } else {
+   RTE_LOG(ERR, PMD, "Unknown token: %s\n", entry);
+   return -1;
+   }
+   }
+
+   /* Read wrr weight */
+   if (cfg->port[port].outq[outq].sched_mode == PP2_PPIO_SCHED_M_WRR) {
+   entry = rte_cfgfile_get_entry(file, sec_name,
+   MRVL_TOK_WRR_WEIGHT);
+   if (entry) {
+   if (get_val_securely(entry, &val) < 0)
+   return -1;
+   cfg->port[port].outq[outq].weight = val;
+   }
+   }
+
+   /*
+* There's no point in setting rate limiting for specific outq as
+* global port rate limiting has priority.
+*/
+   if (cfg->port[port].rate_limit_enable) {
+   RTE_LOG(WARNING, PMD, "Port %d rate limiting already enabled\n",
+   port);
+   return 0;
+   }
+
entry = rte_cfgfile_get_entry(file, sec_name,
-   MRVL_TOK_WEIGHT);
+   MRVL_TOK_RATE_LIMIT_ENABLE);
if (entry) {
if (get_val_securely(entry, &val) < 0)
return -1;
-   cfg->port[port].outq[outq].weight = (uint8_t)val;
+   cfg->port[port].outq[outq].rate_limit_enable = val;
+   }
+
+   if (!cfg->port[port].outq[outq].rate_limit_enable)
+   return 0;
+
+   /* Read CBS (in kB) */
+   entry = rte_cfgfile_get_entry(file, sec_name, MRVL_TOK_BURST_SIZE);
+   if (entry) {
+   if (get_val_securely(entry, &val) < 0)
+   return -1;
+   cfg->port[port].outq[outq].rate_limit_params.cbs = val;
+   }
+
+   /* Read CIR (in kbps) */
+   entry = rte_cfgfile_get_entry(file, sec_name, MRVL_TOK_RATE_LIMIT);
+   if (entry) {
+   if (get_val_securely(entry, &val) < 0)
+   return -1;
+   

[dpdk-dev] [PATCH v3 8/8] net/mrvl: add Tx queue start/stop

[Tomasz Duszynski]

Add Tx queue start/stop feature.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 doc/guides/nics/mrvl.rst   |  1 +
 drivers/net/mrvl/mrvl_ethdev.c | 92 +-
 2 files changed, 91 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/mrvl.rst b/doc/guides/nics/mrvl.rst
index 550bd79..f9ec9d6 100644
--- a/doc/guides/nics/mrvl.rst
+++ b/doc/guides/nics/mrvl.rst
@@ -73,6 +73,7 @@ Features of the MRVL PMD are:
 - Extended stats
 - QoS
 - RX flow control
+- TX queue start/stop
 
 
 Limitations
diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index bf596f4..fac924f 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -134,6 +134,7 @@ struct mrvl_txq {
int port_id;
uint64_t bytes_sent;
struct mrvl_shadow_txq shadow_txqs[RTE_MAX_LCORE];
+   int tx_deferred_start;
 };
 
 static int mrvl_lcore_first;
@@ -459,6 +460,70 @@ mrvl_dev_set_link_down(struct rte_eth_dev *dev)
 }
 
 /**
+ * DPDK callback to start tx queue.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ * @param queue_id
+ *   Transmit queue index.
+ *
+ * @return
+ *   0 on success, negative error value otherwise.
+ */
+static int
+mrvl_tx_queue_start(struct rte_eth_dev *dev, uint16_t queue_id)
+{
+   struct mrvl_priv *priv = dev->data->dev_private;
+   int ret;
+
+   if (!priv)
+   return -EPERM;
+
+   /* passing 1 enables given tx queue */
+   ret = pp2_ppio_set_outq_state(priv->ppio, queue_id, 1);
+   if (ret) {
+   RTE_LOG(ERR, PMD, "Failed to start txq %d\n", queue_id);
+   return ret;
+   }
+
+   dev->data->tx_queue_state[queue_id] = RTE_ETH_QUEUE_STATE_STARTED;
+
+   return 0;
+}
+
+/**
+ * DPDK callback to stop tx queue.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ * @param queue_id
+ *   Transmit queue index.
+ *
+ * @return
+ *   0 on success, negative error value otherwise.
+ */
+static int
+mrvl_tx_queue_stop(struct rte_eth_dev *dev, uint16_t queue_id)
+{
+   struct mrvl_priv *priv = dev->data->dev_private;
+   int ret;
+
+   if (!priv->ppio)
+   return -EPERM;
+
+   /* passing 0 disables given tx queue */
+   ret = pp2_ppio_set_outq_state(priv->ppio, queue_id, 0);
+   if (ret) {
+   RTE_LOG(ERR, PMD, "Failed to stop txq %d\n", queue_id);
+   return ret;
+   }
+
+   dev->data->tx_queue_state[queue_id] = RTE_ETH_QUEUE_STATE_STOPPED;
+
+   return 0;
+}
+
+/**
  * DPDK callback to start the device.
  *
  * @param dev
@@ -472,7 +537,7 @@ mrvl_dev_start(struct rte_eth_dev *dev)
 {
struct mrvl_priv *priv = dev->data->dev_private;
char match[MRVL_MATCH_LEN];
-   int ret = 0, def_init_size;
+   int ret = 0, i, def_init_size;
 
snprintf(match, sizeof(match), "ppio-%d:%d",
 priv->pp_id, priv->ppio_id);
@@ -559,6 +624,24 @@ mrvl_dev_start(struct rte_eth_dev *dev)
goto out;
}
 
+   /* start tx queues */
+   for (i = 0; i < dev->data->nb_tx_queues; i++) {
+   struct mrvl_txq *txq = dev->data->tx_queues[i];
+
+   dev->data->tx_queue_state[i] = RTE_ETH_QUEUE_STATE_STARTED;
+
+   if (!txq->tx_deferred_start)
+   continue;
+
+   /*
+* All txqs are started by default. Stop them
+* so that tx_deferred_start works as expected.
+*/
+   ret = mrvl_tx_queue_stop(dev, i);
+   if (ret)
+   goto out;
+   }
+
return 0;
 out:
RTE_LOG(ERR, PMD, "Failed to start device\n");
@@ -1330,9 +1413,11 @@ static void mrvl_txq_info_get(struct rte_eth_dev *dev, 
uint16_t tx_queue_id,
  struct rte_eth_txq_info *qinfo)
 {
struct mrvl_priv *priv = dev->data->dev_private;
+   struct mrvl_txq *txq = dev->data->tx_queues[tx_queue_id];
 
qinfo->nb_desc =
priv->ppio_params.outqs_params.outqs_params[tx_queue_id].size;
+   qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
 }
 
 /**
@@ -1643,7 +1728,7 @@ mrvl_tx_queue_offloads_okay(struct rte_eth_dev *dev, 
uint64_t requested)
  * @param socket
  *   NUMA socket on which memory must be allocated.
  * @param conf
- *   Thresholds parameters.
+ *   Tx queue configuration parameters.
  *
  * @return
  *   0 on success, negative error value otherwise.
@@ -1671,6 +1756,7 @@ mrvl_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
idx, uint16_t desc,
txq->priv = priv;
txq->queue_id = idx;
txq->port_id = dev->data->port_id;
+   txq->tx_deferred_start = conf->tx_deferred_start;
dev->data->tx_queues[idx] = txq;
 
priv->ppio_params.outqs_params.outqs_params[idx].size = desc;
@@ -1886,6 +1972,8 @@ static const struct eth_dev_ops mrvl_ops = {
.rxq_in

[dpdk-dev] [PATCH v3 5/8] net/mrvl: add classifier support

[Tomasz Duszynski]

Add classifier configuration support via rte_flow api.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 doc/guides/nics/mrvl.rst   |  168 +++
 drivers/net/mrvl/Makefile  |1 +
 drivers/net/mrvl/mrvl_ethdev.c |   59 +
 drivers/net/mrvl/mrvl_ethdev.h |   10 +
 drivers/net/mrvl/mrvl_flow.c   | 2759 
 5 files changed, 2997 insertions(+)
 create mode 100644 drivers/net/mrvl/mrvl_flow.c

diff --git a/doc/guides/nics/mrvl.rst b/doc/guides/nics/mrvl.rst
index 6794cbb..9230d5e 100644
--- a/doc/guides/nics/mrvl.rst
+++ b/doc/guides/nics/mrvl.rst
@@ -113,6 +113,9 @@ Prerequisites
   approval has been granted, library can be found by typing ``musdk`` in
   the search box.
 
+  To get better understanding of the library one can consult documentation
+  available in the ``doc`` top level directory of the MUSDK sources.
+
   MUSDK must be configured with the following features:
 
   .. code-block:: console
@@ -318,6 +321,171 @@ the path to the MUSDK installation directory needs to be 
exported.
sed -ri 's,(MRVL_PMD=)n,\1y,' build/.config
make
 
+Flow API
+
+
+PPv2 offers packet classification capabilities via classifier engine which
+can be configured via generic flow API offered by DPDK.
+
+Supported flow actions
+~~
+
+Following flow action items are supported by the driver:
+
+* DROP
+* QUEUE
+
+Supported flow items
+
+
+Following flow items and their respective fields are supported by the driver:
+
+* ETH
+
+  * source MAC
+  * destination MAC
+  * ethertype
+
+* VLAN
+
+  * PCP
+  * VID
+
+* IPV4
+
+  * DSCP
+  * protocol
+  * source address
+  * destination address
+
+* IPV6
+
+  * flow label
+  * next header
+  * source address
+  * destination address
+
+* UDP
+
+  * source port
+  * destination port
+
+* TCP
+
+  * source port
+  * destination port
+
+Classifier match engine
+~~~
+
+Classifier has an internal match engine which can be configured to
+operate in either exact or maskable mode.
+
+Mode is selected upon creation of the first unique flow rule as follows:
+
+* maskable, if key size is up to 8 bytes.
+* exact, otherwise, i.e for keys bigger than 8 bytes.
+
+Where the key size equals the number of bytes of all fields specified
+in the flow items.
+
+.. table:: Examples of key size calculation
+
+   
++---+-+
+   | Flow pattern  
 | Key size in bytes | Used engine |
+   
++===+=+
+   | ETH (destination MAC) / VLAN (VID)
 | 6 + 2 = 8 | Maskable|
+   
++---+-+
+   | VLAN (VID) / IPV4 (source address)
 | 2 + 4 = 6 | Maskable|
+   
++---+-+
+   | TCP (source port, destination port)   
 | 2 + 2 = 4 | Maskable|
+   
++---+-+
+   | VLAN (priority) / IPV4 (source address)   
 | 1 + 4 = 5 | Maskable|
+   
++---+-+
+   | IPV4 (destination address) / UDP (source port, destination port)  
 | 6 + 2 + 2 = 10| Exact   |
+   
++---+-+
+   | VLAN (VID) / IPV6 (flow label, destination address)   
 | 2 + 3 + 16 = 21   | Exact   |
+   
++---+-+
+   | IPV4 (DSCP, source address, destination address)  
 | 1 + 4 + 4 = 9 | Exact   |
+   
++---+-+
+   | IPV6 (flow label, source address, destination address)
 | 3 + 16 + 16 = 35  | Exact   |
+   
++---+-+
+
+From the user perspective maskable mode means that masks specified
+via flow rules are respected. In case of exact match mode, masks
+which do not provide exact matching (all bits masked) are ignored.
+
+If the flow matches more than one classifier rule the first
+(with the lowest index) matched takes precedence.
+
+Flow rules usage example
+

[dpdk-dev] [PATCH v3 6/8] net/mrvl: add extended statistics

[Tomasz Duszynski]

Add extended statistics implementation.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 doc/guides/nics/features/mrvl.ini |   1 +
 doc/guides/nics/mrvl.rst  |   1 +
 drivers/net/mrvl/mrvl_ethdev.c| 115 +-
 3 files changed, 116 insertions(+), 1 deletion(-)

diff --git a/doc/guides/nics/features/mrvl.ini 
b/doc/guides/nics/features/mrvl.ini
index 00d9621..120fd4d 100644
--- a/doc/guides/nics/features/mrvl.ini
+++ b/doc/guides/nics/features/mrvl.ini
@@ -19,5 +19,6 @@ L3 checksum offload  = Y
 L4 checksum offload  = Y
 Packet type parsing  = Y
 Basic stats  = Y
+Extended stats   = Y
 ARMv8= Y
 Usage doc= Y
diff --git a/doc/guides/nics/mrvl.rst b/doc/guides/nics/mrvl.rst
index 9230d5e..7678265 100644
--- a/doc/guides/nics/mrvl.rst
+++ b/doc/guides/nics/mrvl.rst
@@ -70,6 +70,7 @@ Features of the MRVL PMD are:
 - L4 checksum offload
 - Packet type parsing
 - Basic stats
+- Extended stats
 - QoS
 
 
diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index 34b9ef7..880bd0b 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -145,6 +145,32 @@ static inline void mrvl_free_sent_buffers(struct pp2_ppio 
*ppio,
struct pp2_hif *hif, unsigned int core_id,
struct mrvl_shadow_txq *sq, int qid, int force);
 
+#define MRVL_XSTATS_TBL_ENTRY(name) { \
+   #name, offsetof(struct pp2_ppio_statistics, name),  \
+   sizeof(((struct pp2_ppio_statistics *)0)->name) \
+}
+
+/* Table with xstats data */
+static struct {
+   const char *name;
+   unsigned int offset;
+   unsigned int size;
+} mrvl_xstats_tbl[] = {
+   MRVL_XSTATS_TBL_ENTRY(rx_bytes),
+   MRVL_XSTATS_TBL_ENTRY(rx_packets),
+   MRVL_XSTATS_TBL_ENTRY(rx_unicast_packets),
+   MRVL_XSTATS_TBL_ENTRY(rx_errors),
+   MRVL_XSTATS_TBL_ENTRY(rx_fullq_dropped),
+   MRVL_XSTATS_TBL_ENTRY(rx_bm_dropped),
+   MRVL_XSTATS_TBL_ENTRY(rx_early_dropped),
+   MRVL_XSTATS_TBL_ENTRY(rx_fifo_dropped),
+   MRVL_XSTATS_TBL_ENTRY(rx_cls_dropped),
+   MRVL_XSTATS_TBL_ENTRY(tx_bytes),
+   MRVL_XSTATS_TBL_ENTRY(tx_packets),
+   MRVL_XSTATS_TBL_ENTRY(tx_unicast_packets),
+   MRVL_XSTATS_TBL_ENTRY(tx_errors)
+};
+
 static inline int
 mrvl_get_bpool_size(int pp2_id, int pool_id)
 {
@@ -1110,6 +1136,90 @@ mrvl_stats_reset(struct rte_eth_dev *dev)
 }
 
 /**
+ * DPDK callback to get extended statistics.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ * @param stats
+ *   Pointer to xstats table.
+ * @param n
+ *   Number of entries in xstats table.
+ * @return
+ *   Negative value on error, number of read xstats otherwise.
+ */
+static int
+mrvl_xstats_get(struct rte_eth_dev *dev,
+   struct rte_eth_xstat *stats, unsigned int n)
+{
+   struct mrvl_priv *priv = dev->data->dev_private;
+   struct pp2_ppio_statistics ppio_stats;
+   unsigned int i;
+
+   if (!stats)
+   return 0;
+
+   pp2_ppio_get_statistics(priv->ppio, &ppio_stats, 0);
+   for (i = 0; i < n && i < RTE_DIM(mrvl_xstats_tbl); i++) {
+   uint64_t val;
+
+   if (mrvl_xstats_tbl[i].size == sizeof(uint32_t))
+   val = *(uint32_t *)((uint8_t *)&ppio_stats +
+   mrvl_xstats_tbl[i].offset);
+   else if (mrvl_xstats_tbl[i].size == sizeof(uint64_t))
+   val = *(uint64_t *)((uint8_t *)&ppio_stats +
+   mrvl_xstats_tbl[i].offset);
+   else
+   return -EINVAL;
+
+   stats[i].id = i;
+   stats[i].value = val;
+   }
+
+   return n;
+}
+
+/**
+ * DPDK callback to reset extended statistics.
+ *
+ * @param dev
+ *   Pointer to Ethernet device structure.
+ */
+static void
+mrvl_xstats_reset(struct rte_eth_dev *dev)
+{
+   mrvl_stats_reset(dev);
+}
+
+/**
+ * DPDK callback to get extended statistics names.
+ *
+ * @param dev (unused)
+ *   Pointer to Ethernet device structure.
+ * @param xstats_names
+ *   Pointer to xstats names table.
+ * @param size
+ *   Size of the xstats names table.
+ * @return
+ *   Number of read names.
+ */
+static int
+mrvl_xstats_get_names(struct rte_eth_dev *dev __rte_unused,
+ struct rte_eth_xstat_name *xstats_names,
+ unsigned int size)
+{
+   unsigned int i;
+
+   if (!xstats_names)
+   return RTE_DIM(mrvl_xstats_tbl);
+
+   for (i = 0; i < size && i < RTE_DIM(mrvl_xstats_tbl); i++)
+   snprintf(xstats_names[i].name, RTE_ETH_XSTATS_NAME_SIZE, "%s",
+mrvl_xstats_tbl[i].name);
+
+   return size;
+}
+
+/**
  * DPDK callback to get information about the device.
  *
  * @param dev
@@ -1692,6 +1802,9 @@ static const struct eth_dev_ops mrvl_ops = {
 

[dpdk-dev] [PATCH v3 7/8] net/mrvl: add Rx flow control

[Tomasz Duszynski]

Add Rx side flow control support.

Signed-off-by: Natalie Samsonov 
Signed-off-by: Tomasz Duszynski 
---
 doc/guides/nics/features/mrvl.ini |  1 +
 doc/guides/nics/mrvl.rst  |  1 +
 drivers/net/mrvl/mrvl_ethdev.c| 78 +++
 3 files changed, 80 insertions(+)

diff --git a/doc/guides/nics/features/mrvl.ini 
b/doc/guides/nics/features/mrvl.ini
index 120fd4d..8673a56 100644
--- a/doc/guides/nics/features/mrvl.ini
+++ b/doc/guides/nics/features/mrvl.ini
@@ -13,6 +13,7 @@ Allmulticast mode= Y
 Unicast MAC filter   = Y
 Multicast MAC filter = Y
 RSS hash = Y
+Flow control = Y
 VLAN filter  = Y
 CRC offload  = Y
 L3 checksum offload  = Y
diff --git a/doc/guides/nics/mrvl.rst b/doc/guides/nics/mrvl.rst
index 7678265..550bd79 100644
--- a/doc/guides/nics/mrvl.rst
+++ b/doc/guides/nics/mrvl.rst
@@ -72,6 +72,7 @@ Features of the MRVL PMD are:
 - Basic stats
 - Extended stats
 - QoS
+- RX flow control
 
 
 Limitations
diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index 880bd0b..bf596f4 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -1696,6 +1696,82 @@ mrvl_tx_queue_release(void *txq)
 }
 
 /**
+ * DPDK callback to get flow control configuration.
+ *
+ * @param dev
+ *  Pointer to Ethernet device structure.
+ * @param fc_conf
+ *  Pointer to the flow control configuration.
+ *
+ * @return
+ *  0 on success, negative error value otherwise.
+ */
+static int
+mrvl_flow_ctrl_get(struct rte_eth_dev *dev, struct rte_eth_fc_conf *fc_conf)
+{
+   struct mrvl_priv *priv = dev->data->dev_private;
+   int ret, en;
+
+   if (!priv)
+   return -EPERM;
+
+   ret = pp2_ppio_get_rx_pause(priv->ppio, &en);
+   if (ret) {
+   RTE_LOG(ERR, PMD, "Failed to read rx pause state\n");
+   return ret;
+   }
+
+   fc_conf->mode = en ? RTE_FC_RX_PAUSE : RTE_FC_NONE;
+
+   return 0;
+}
+
+/**
+ * DPDK callback to set flow control configuration.
+ *
+ * @param dev
+ *  Pointer to Ethernet device structure.
+ * @param fc_conf
+ *  Pointer to the flow control configuration.
+ *
+ * @return
+ *  0 on success, negative error value otherwise.
+ */
+static int
+mrvl_flow_ctrl_set(struct rte_eth_dev *dev, struct rte_eth_fc_conf *fc_conf)
+{
+   struct mrvl_priv *priv = dev->data->dev_private;
+
+   if (!priv)
+   return -EPERM;
+
+   if (fc_conf->high_water ||
+   fc_conf->low_water ||
+   fc_conf->pause_time ||
+   fc_conf->mac_ctrl_frame_fwd ||
+   fc_conf->autoneg) {
+   RTE_LOG(ERR, PMD, "Flowctrl parameter is not supported\n");
+
+   return -EINVAL;
+   }
+
+   if (fc_conf->mode == RTE_FC_NONE ||
+   fc_conf->mode == RTE_FC_RX_PAUSE) {
+   int ret, en;
+
+   en = fc_conf->mode == RTE_FC_NONE ? 0 : 1;
+   ret = pp2_ppio_set_rx_pause(priv->ppio, en);
+   if (ret)
+   RTE_LOG(ERR, PMD,
+   "Failed to change flowctrl on RX side\n");
+
+   return ret;
+   }
+
+   return 0;
+}
+
+/**
  * Update RSS hash configuration
  *
  * @param dev
@@ -1814,6 +1890,8 @@ static const struct eth_dev_ops mrvl_ops = {
.rx_queue_release = mrvl_rx_queue_release,
.tx_queue_setup = mrvl_tx_queue_setup,
.tx_queue_release = mrvl_tx_queue_release,
+   .flow_ctrl_get = mrvl_flow_ctrl_get,
+   .flow_ctrl_set = mrvl_flow_ctrl_set,
.rss_hash_update = mrvl_rss_hash_update,
.rss_hash_conf_get = mrvl_rss_hash_conf_get,
.filter_ctrl = mrvl_eth_filter_ctrl,
-- 
2.7.4

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Remy Horton]

On 14/03/2018 15:10, Shreyansh Jain wrote:
[..]

What do you think renaming structure and variable name,
"preferred_dev_config" perhaps?


I missed this naming while reading this patch. In the deprecation
notice, 'preferred_size' was the name we came up with precisely on
this issue of structure having queue length and burst size.

What about using that same name?


Because of namespace issues it will need at least the rte_ prefix. 
Otherwise seems good to me as I cannot think of anything else that is 
relatively short.

[dpdk-dev] [PATCH v2] drivers/net/i40e/i40e_ethdev_vf.c: fix missing promiscuous disable at device stop

[Rosen Xu]

In scenario of Kernel Driver runs on PF and PMD runs on VF, PMD exit doesn't
disable promiscuous mode, this will cause vlan filter set by Kernel Driver
will not take effect.

This patch will fix it, add promiscuous disable at device stop.

Signed-off-by: Rosen Xu 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index fd003fe..f395b02 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2051,6 +2051,8 @@ static int eth_i40evf_pci_remove(struct rte_pci_device 
*pci_dev)
 
if (hw->adapter_stopped == 1)
return;
+   i40evf_dev_promiscuous_disable(dev);
+   i40evf_dev_allmulticast_disable(dev);
i40evf_stop_queues(dev);
i40evf_disable_queues_intr(dev);
i40e_dev_clear_queues(dev);
-- 
1.8.3.1

[dpdk-dev] [PATCH v2 2/5] net/virtio: add checking for cvq

[zhiyong . yang]

Add checking for cvq to judge if virtio_ack_link_announce is called.
The original code doesn't cause issue, and add the checking just to look
more reasonable.

Signed-off-by: Zhiyong Yang 
---
 drivers/net/virtio/virtio_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index b38582c8d..74943a5a9 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1338,7 +1338,8 @@ virtio_interrupt_handler(void *param)
 
if (isr & VIRTIO_NET_S_ANNOUNCE) {
virtio_notify_peers(dev);
-   virtio_ack_link_announce(dev);
+   if (hw->cvq)
+   virtio_ack_link_announce(dev);
}
 }
 
-- 
2.14.3

[dpdk-dev] [PATCH v2 0/5] add support for virtio-user server mode

[zhiyong . yang]

In a container environment if the vhost-user backend restarts, there's no way
for it to reconnect to virtio-user currently. To address this, support for
server mode is added. In this mode the socket file is created by virtio-user,
which the backend then connects to. This means that if the backend restarts,
it can reconnect to virtio-user and continue communications.

The series add support for the feature and target for 18.05 release.

Virtio-user with server mode creates socket file and then starts to wait for the
first connection from vhost user with client mode in blocking mode.

Virtio-user with server mode supports many times' vhost reconnections with same 
configurations. 

Virtio-user supports only one connection at the same time in server/client mode.

How to test?
The following scripts are as reference.

./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -m 256,0 --no-pci \
--file-prefix=testpmd0 --vdev=net_virtio_user0,mac=00:11:22:33:44:10, \
path=/tmp/sock0,server=1,queues=1 -- -i --rxq=1 --txq=1 --no-numa

./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3e000 -n 4 --socket-mem 256,0 \
--vdev 'net_vhost0,iface=/tmp/sock0,client=1,queues=1' -- -i --rxq=1 --txq=1 \
--nb-cores=1 --no-numa

step1 : at the virio-user side, run "start"
step2: at the vhost-user side run "start tx_first 4"

Changes in V2:
1. split two patch 1/5 and 2/5 from v1 patchset to fix some existing issues 
which is not
strongly related to support for server mode according to Maxime's comments.
2. move fdset related functions to librte_eal from librte_vhost exposed as
new APIs according to Thomas' comments.
3. release note is added in the patch 5/5.
4. squash data structure change patch into 4/5 according to Maxime's suggestion.

Zhiyong Yang (5):
  net/virtio: fix add pointer checking
  net/virtio: add checking for cvq
  eal: expose fdset related APIs
  net/virtio-user: add support for server mode
  net/vhost: add memory checking

 doc/guides/rel_notes/release_18_05.rst |   7 +
 drivers/net/vhost/rte_eth_vhost.c  |   9 +
 drivers/net/virtio/virtio_ethdev.c |  10 +-
 drivers/net/virtio/virtio_user/vhost_user.c|  77 +-
 drivers/net/virtio/virtio_user/virtio_user_dev.c   |  44 ++--
 drivers/net/virtio/virtio_user/virtio_user_dev.h   |   8 +
 drivers/net/virtio/virtio_user_ethdev.c|  82 +-
 lib/librte_eal/common/include/rte_eal_interrupts.h |  56 +
 lib/librte_eal/linuxapp/eal/eal_interrupts.c   | 257 +++
 lib/librte_eal/rte_eal_version.map |  10 +
 lib/librte_vhost/Makefile  |   2 +-
 lib/librte_vhost/fd_man.c  | 274 -
 lib/librte_vhost/fd_man.h  |  40 ---
 lib/librte_vhost/socket.c  |  22 +-
 14 files changed, 548 insertions(+), 350 deletions(-)
 delete mode 100644 lib/librte_vhost/fd_man.c
 delete mode 100644 lib/librte_vhost/fd_man.h

-- 
2.14.3

[dpdk-dev] [PATCH v2 1/5] net/virtio: fix add pointer checking

[zhiyong . yang]

It is necessary to add pointer checking because in some case the
code will cause crash.
For example,
The code goes here before memory allocation of rxvq is done.

Fixes: 7365504f77e3("net/virtio: support guest announce")
Cc: sta...@dpdk.org
Signed-off-by: Zhiyong Yang 
---
 drivers/net/virtio/virtio_ethdev.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 884f74ad0..b38582c8d 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1273,9 +1273,14 @@ static void
 virtio_notify_peers(struct rte_eth_dev *dev)
 {
struct virtio_hw *hw = dev->data->dev_private;
-   struct virtnet_rx *rxvq = dev->data->rx_queues[0];
+   struct virtnet_rx *rxvq;
struct rte_mbuf *rarp_mbuf;
 
+   if (!dev->data->rx_queues)
+   return;
+
+   rxvq = dev->data->rx_queues[0];
+
rarp_mbuf = rte_net_make_rarp_packet(rxvq->mpool,
(struct ether_addr *)hw->mac_addr);
if (rarp_mbuf == NULL) {
-- 
2.14.3

[dpdk-dev] [PATCH v2 3/5] eal: expose fdset related APIs

[zhiyong . yang]

The patch moves fdset related functions from lib vhost to lib eal and
expose them as new APIs in order that they can be reused.
Just move the code to the new place "eal_interrupts.c" and add prefix
"rte_ " to functions name, and don't change any functionality.

Librte_vhost changes new function names accordingly when invoking.
Remove the files fd_man.h and fd_man.c and remove fd_mac.c from Makefile
from librte_vhost.

Signed-off-by: Zhiyong Yang 
---
 lib/librte_eal/common/include/rte_eal_interrupts.h |  56 +
 lib/librte_eal/linuxapp/eal/eal_interrupts.c   | 257 +++
 lib/librte_eal/rte_eal_version.map |  10 +
 lib/librte_vhost/Makefile  |   2 +-
 lib/librte_vhost/fd_man.c  | 274 -
 lib/librte_vhost/fd_man.h  |  40 ---
 lib/librte_vhost/socket.c  |  22 +-
 7 files changed, 336 insertions(+), 325 deletions(-)
 delete mode 100644 lib/librte_vhost/fd_man.c
 delete mode 100644 lib/librte_vhost/fd_man.h

diff --git a/lib/librte_eal/common/include/rte_eal_interrupts.h 
b/lib/librte_eal/common/include/rte_eal_interrupts.h
index 3f792a97f..1886d0dd0 100644
--- a/lib/librte_eal/common/include/rte_eal_interrupts.h
+++ b/lib/librte_eal/common/include/rte_eal_interrupts.h
@@ -17,6 +17,9 @@
 #ifndef _RTE_EAL_INTERRUPTS_H_
 #define _RTE_EAL_INTERRUPTS_H_
 
+#include 
+#include "rte_compat.h"
+
 #define RTE_MAX_RXTX_INTR_VEC_ID 32
 #define RTE_INTR_VEC_ZERO_OFFSET  0
 #define RTE_INTR_VEC_RXTX_OFFSET  1
@@ -82,6 +85,24 @@ struct rte_intr_handle {
 };
 
 #define RTE_EPOLL_PER_THREAD-1  /**< to hint using per thread epfd */
+#define RTE_MAX_FDS 1024
+
+typedef void (*fd_cb)(int fd, void *dat, int *remove);
+
+struct rte_fdentry {
+   int fd; /* -1 indicates this entry is empty */
+   fd_cb rcb;  /* callback when this fd is readable. */
+   fd_cb wcb;  /* callback when this fd is writeable.*/
+   void *dat;  /* fd context */
+   int busy;   /* whether this entry is being used in cb. */
+};
+
+struct rte_fdset {
+   struct pollfd rwfds[RTE_MAX_FDS];
+   struct rte_fdentry fd[RTE_MAX_FDS];
+   pthread_mutex_t fd_mutex;
+   int num;/* current fd number of this fdset */
+};
 
 /**
  * It waits for events on the epoll instance.
@@ -218,4 +239,39 @@ rte_intr_allow_others(struct rte_intr_handle *intr_handle);
 int
 rte_intr_cap_multiple(struct rte_intr_handle *intr_handle);
 
+/**
+ * Initialize struct rte_fdset.
+ *
+ * @param intr_handle
+ *   Pointer to struct rte_fdset.
+ */
+void __rte_experimental
+rte_fdset_init(struct rte_fdset *pfdset);
+
+/**
+ * Register the fd in the fdset with read/write handler and context.
+ *
+ * @param intr_handle
+ *   Pointer to struct rte_fdset.
+ */
+int __rte_experimental
+rte_fdset_add(struct rte_fdset *pfdset, int fd,
+   fd_cb rcb, fd_cb wcb, void *dat);
+
+/**
+ * Unregister the fd in the fdset.
+ *
+ * @param intr_handle
+ *   Pointer to struct rte_fdset.
+ */
+void * __rte_experimental
+rte_fdset_del(struct rte_fdset *pfdset, int fd);
+
+/**
+ * This functions runs in infinite blocking loop until there is no fd in
+ * pfdset. It calls corresponding r/w handler if there is event on the fd.
+ */
+void * __rte_experimental
+rte_fdset_event_dispatch(void *arg);
+
 #endif /* _RTE_EAL_INTERRUPTS_H_ */
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c 
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index f86f22f7b..95a382525 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -1230,3 +1230,260 @@ rte_intr_cap_multiple(struct rte_intr_handle 
*intr_handle)
 
return 0;
 }
+
+#define FDPOLLERR (POLLERR | POLLHUP | POLLNVAL)
+
+static int
+get_last_valid_idx(struct rte_fdset *pfdset, int last_valid_idx)
+{
+   int i;
+
+   for (i = last_valid_idx; i >= 0 && pfdset->fd[i].fd == -1; i--)
+   ;
+
+   return i;
+}
+
+static void
+fdset_move(struct rte_fdset *pfdset, int dst, int src)
+{
+   pfdset->fd[dst]= pfdset->fd[src];
+   pfdset->rwfds[dst] = pfdset->rwfds[src];
+}
+
+static void
+fdset_shrink_nolock(struct rte_fdset *pfdset)
+{
+   int i;
+   int last_valid_idx = get_last_valid_idx(pfdset, pfdset->num - 1);
+
+   for (i = 0; i < last_valid_idx; i++) {
+   if (pfdset->fd[i].fd != -1)
+   continue;
+
+   fdset_move(pfdset, i, last_valid_idx);
+   last_valid_idx = get_last_valid_idx(pfdset, last_valid_idx - 1);
+   }
+   pfdset->num = last_valid_idx + 1;
+}
+
+/*
+ * Find deleted fd entries and remove them
+ */
+static void
+fdset_shrink(struct rte_fdset *pfdset)
+{
+   pthread_mutex_lock(&pfdset->fd_mutex);
+   fdset_shrink_nolock(pfdset);
+   pthread_mutex_unlock(&pfdset->fd_mutex);
+}
+
+/**
+ * Returns the index in the fdset for a given fd.
+ * @return
+ 

[dpdk-dev] [PATCH v2 4/5] net/virtio-user: add support for server mode

[zhiyong . yang]

virtio-user adds support for server mode in this patch.

Virtio-user with server mode creates socket file and then starts to wait
for the first connection from vhost user with client mode in blocking mode.

Server mode virtio-user supports many times' vhost reconnections with
same configurations.

Signed-off-by: Zhiyong Yang 
---
 drivers/net/virtio/virtio_user/vhost_user.c  | 77 --
 drivers/net/virtio/virtio_user/virtio_user_dev.c | 44 +
 drivers/net/virtio/virtio_user/virtio_user_dev.h |  8 +++
 drivers/net/virtio/virtio_user_ethdev.c  | 82 ++--
 4 files changed, 188 insertions(+), 23 deletions(-)

diff --git a/drivers/net/virtio/virtio_user/vhost_user.c 
b/drivers/net/virtio/virtio_user/vhost_user.c
index 91c6449bb..cd30f713a 100644
--- a/drivers/net/virtio/virtio_user/vhost_user.c
+++ b/drivers/net/virtio/virtio_user/vhost_user.c
@@ -378,6 +378,55 @@ vhost_user_sock(struct virtio_user_dev *dev,
return 0;
 }
 
+static void
+virtio_user_set_block(int fd, bool enabled)
+{
+   int f;
+
+   f = fcntl(fd, F_GETFL);
+   if (enabled)
+   fcntl(fd, F_SETFL, f & ~O_NONBLOCK);
+   else
+   fcntl(fd, F_SETFL, f | O_NONBLOCK);
+}
+
+#define MAX_VIRTIO_USER_BACKLOG 128
+static int
+virtio_user_start_server(struct virtio_user_dev *dev, struct sockaddr_un *un)
+{
+   int ret;
+   int fd = dev->listenfd;
+   int connectfd;
+
+   ret = bind(fd, (struct sockaddr *)un, sizeof(*un));
+   if (ret < 0) {
+   PMD_DRV_LOG(ERR, "failed to bind to %s: %s; remove it and try 
again\n",
+   dev->path, strerror(errno));
+   goto err;
+   }
+   ret = listen(fd, MAX_VIRTIO_USER_BACKLOG);
+   if (ret < 0)
+   goto err;
+
+   virtio_user_set_block(fd, true);
+   PMD_DRV_LOG(NOTICE, "virtio user server mode is waiting for connection 
from vhost user.");
+   while (1) {
+   connectfd = accept(fd, NULL, NULL);
+   if (connectfd >= 0) {
+   dev->connected = true;
+   break;
+   }
+   }
+
+   dev->vhostfd = connectfd;
+   virtio_user_set_block(connectfd, true);
+
+   return 0;
+err:
+   close(fd);
+   return -1;
+}
+
 /**
  * Set up environment to talk with a vhost user backend.
  *
@@ -390,6 +439,7 @@ vhost_user_setup(struct virtio_user_dev *dev)
 {
int fd;
int flag;
+   int ret;
struct sockaddr_un un;
 
fd = socket(AF_UNIX, SOCK_STREAM, 0);
@@ -405,13 +455,30 @@ vhost_user_setup(struct virtio_user_dev *dev)
memset(&un, 0, sizeof(un));
un.sun_family = AF_UNIX;
snprintf(un.sun_path, sizeof(un.sun_path), "%s", dev->path);
-   if (connect(fd, (struct sockaddr *)&un, sizeof(un)) < 0) {
-   PMD_DRV_LOG(ERR, "connect error, %s", strerror(errno));
-   close(fd);
-   return -1;
+
+   if (dev->is_server) {
+   static pthread_t fdset_tid;
+
+   dev->listenfd = fd;
+   if (fdset_tid == 0) {
+   ret = pthread_create(&fdset_tid, NULL,
+rte_fdset_event_dispatch,
+&dev->fdset);
+   if (ret < 0)
+   PMD_DRV_LOG(ERR, "failed to create fdset 
handling thread");
+   }
+   return virtio_user_start_server(dev, &un);
+
+   } else {
+   dev->vhostfd = fd;
+   if (connect(fd, (struct sockaddr *)&un, sizeof(un)) < 0) {
+   PMD_DRV_LOG(ERR, "connect error, %s", strerror(errno));
+   close(fd);
+   return -1;
+   }
+   dev->connected = true;
}
 
-   dev->vhostfd = fd;
return 0;
 }
 
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c 
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index f90fee9e5..23312344f 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -142,6 +142,9 @@ int virtio_user_stop_device(struct virtio_user_dev *dev)
 {
uint32_t i;
 
+   if (!dev->connected)
+   return -1;
+
for (i = 0; i < dev->max_queue_pairs; ++i)
dev->ops->enable_qp(dev, i, 0);
 
@@ -267,21 +270,27 @@ virtio_user_dev_setup(struct virtio_user_dev *dev)
dev->vhostfds = NULL;
dev->tapfds = NULL;
 
-   if (is_vhost_user_by_type(dev->path)) {
-   dev->ops = &ops_user;
+   if (dev->is_server) {
+   dev->ops = &ops_user;/* server mode only supports vhost user */
} else {
-   dev->ops = &ops_kernel;
-
-   dev->vhostfds = malloc(dev->max_queue_pairs * sizeof(int));
-   dev->tapfds = malloc(dev->max_queue_pairs * sizeof(i

[dpdk-dev] [PATCH v2 5/5] net/vhost: add memory checking

[zhiyong . yang]

When vhost user PMD works in client mode to connect/reconnect virtio-user
with server mode, new thread sometimes may run to new_device before
queue_setup has been done, So have to wait until memory allocation is
done.

Release note is updated in the patch.

Signed-off-by: Zhiyong Yang 
---
 doc/guides/rel_notes/release_18_05.rst | 7 +++
 drivers/net/vhost/rte_eth_vhost.c  | 9 +
 2 files changed, 16 insertions(+)

diff --git a/doc/guides/rel_notes/release_18_05.rst 
b/doc/guides/rel_notes/release_18_05.rst
index 3923dc253..7b301f021 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -41,6 +41,13 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Added support for virtio-user server mode.**
+
+  In a container environment if the vhost-user backend restarts, there's no way
+  for it to reconnect to virtio-user. To address this, support for server mode
+  is added. In this mode the socket file is created by virtio-user, which the
+  backend then connects to. This means that if the backend restarts, it can
+  reconnect to virtio-user and continue communications.
 
 API Changes
 ---
diff --git a/drivers/net/vhost/rte_eth_vhost.c 
b/drivers/net/vhost/rte_eth_vhost.c
index 3aae01c39..2490bad0b 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -580,6 +580,15 @@ new_device(int vid)
eth_dev->data->numa_node = newnode;
 #endif
 
+   /* The thread may run here before eth_dev->data->rx_queues or
+* eth_dev->data->tx_queues have gotten valid memory, so have to
+* wait until memory allocation is done.
+*/
+   while (!eth_dev->data->rx_queues ||
+  !eth_dev->data->tx_queues) {
+   usleep(1);
+   }
+
for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
vq = eth_dev->data->rx_queues[i];
if (vq == NULL)
-- 
2.14.3

Re: [dpdk-dev] [PATCH v1 3/9] mempool: remove callback to get capabilities

[Burakov, Anatoly]

On 14-Mar-18 5:24 PM, Andrew Rybchenko wrote:

On 03/14/2018 07:53 PM, Burakov, Anatoly wrote:

On 14-Mar-18 4:12 PM, Andrew Rybchenko wrote:

On 03/14/2018 05:40 PM, Burakov, Anatoly wrote:

On 10-Mar-18 3:39 PM, Andrew Rybchenko wrote:

The callback was introduced to let generic code to know octeontx
mempool driver requirements to use single physically contiguous
memory chunk to store all objects and align object address to
total object size. Now these requirements are met using a new
callbacks to calculate required memory chunk size and to populate
objects using provided memory chunk.

These capability flags are not used anywhere else.

Restricting capabilities to flags is not generic and likely to
be insufficient to describe mempool driver features. If required
in the future, API which returns structured information may be
added.

Signed-off-by: Andrew Rybchenko 
---


Just a general comment - it is not enough to describe minimum 
memchunk requirements. With memory hotplug patchset that's hopefully 
getting merged in 18.05, memzones will no longer be guaranteed to be 
IOVA-contiguous. So, if a driver requires its mempool to not only be 
populated from a single memzone, but a single *physically 
contiguous* memzone, going by only callbacks will not do, because 
whether or not something should be a single memzone says nothing 
about whether this memzone has to also be IOVA-contiguous.


So i believe this needs to stay in one form or another.

(also it would be nice to have a flag that a user could pass to 
mempool_create that would force memzone reservation be 
IOVA-contiguous, but that's a topic for another conversation. prime 
user for this would be KNI.)


I think that min_chunk_size should be treated as IOVA-contiguous.


Why? It's perfectly reasonable to e.g. implement a software mempool 
driver that would perform some optimizations due to all objects being 
in the same VA-contiguous memzone, yet not be dependent on underlying 
physical memory layout. These are two separate concerns IMO.


It looks like there is some misunderstanding here or I simply don't 
understand your point.
Above I mean that driver should be able to advertise its requirements on 
IOVA-contiguous regions.

If driver do not care about physical memory layout, no problem.


Please correct me if i'm wrong, but my understanding was that you wanted 
to use min_chunk as a way to express minimum requirements for 
IOVA-contiguous memory. If i understood you correctly, i don't think 
that's the way to go because there could be valid use cases where a 
mempool driver would like to advertise min_chunk_size to be equal to its 
total size (i.e. allocate everything in a single memzone), yet not 
require that memzone to be IOVA-contiguous. I think these are two 
different concerns, and one does not, and should not imply the other.





> So, we

have 4 levels:
  - MEMPOOL_F_NO_PHYS_CONTIG (min_chunk_size == 0) -- 
IOVA-congtiguous is not required at all
  - no MEMPOOL_F_NO_PHYS_CONTIG (min_chunk_size == total_obj_size) -- 
object should be IOVA-contiguous
  - min_chunk_size > total_obj_size  -- group of objects should be 
IOVA-contiguous
  - min_chunk_size ==  -- all objects should be 
IOVA-contiguous


I don't think this "automagic" decision on what should be 
IOVA-contiguous or not is the way to go. It needlessly complicates 
things, when all it takes is another flag passed to mempool allocator 
somewhere.


No, it is not just one flag. We really need option (3) above: group of 
objects IOVA-contiguous in [1].
Of course, it is possible to use option (4) instead: everything 
IOVA-contigous, but I think it is bad - it may be very big and 
hard/impossible to allocate due to fragmentation.




Exactly: we shouldn't be forcing IOVA-contiguous memory just because 
mempool requrested a big min_chunk_size, nor do i think it is wise to 
encode such heuristics (referring to your 4 "levels" quoted above) into 
the mempool allocator.


I'm not sure what is the best solution here. Perhaps another option 
would be to let mempool drivers allocate their memory as well? I.e. 
leave current behavior as default, as it's likely that it would be 
suitable for nearly all use cases, but provide another option to 
override memory allocation completely, so that e.g. octeontx could 
just do a memzone_reserve_contig() without regard for default 
allocation settings. I think this could be the cleanest solution.


For me it is hard to say. I don't know DPDK history good enough to say 
why there is a mempool API to populate objects on externally provided 
memory. If it may be removed, it is OK for me to do memory allocation 
inside rte_mempool or mempool drivers. Otherwise, if it is still allowed 
to allocate memory externally and pass it to mempool, it must be a way 
to express IOVA-contiguos requirements.


[1] https://dpdk.org/dev/patchwork/patch/34338/


Populating mempool objects is not the same as reserving memory where 
those objects would reside. The closest to 

Re: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alternative

[Trahe, Fiona]

> -Original Message-
> From: Verma, Shally [mailto:shally.ve...@cavium.com]
> Sent: Thursday, March 15, 2018 4:12 AM
> To: Ahmed Mansour ; Trahe, Fiona 
> ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo ; Athreya, Narayana 
> Prasad
> ; Gupta, Ashish ; 
> Sahu, Sunila
> ; Challa, Mahipal ; Jain, 
> Deepak K
> ; Hemant Agrawal ; Roy Pledge
> ; Youri Querry ; Daly, Lee 
> ;
> Jozwiak, TomaszX ; Alok Makhariya 
> ; Shreyansh
> Jain 
> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alternative
> 
> @Trahe, Fiona>> We're proposing, in the interest of getting the API out in 
> 18.05, to stick with mbufs -
> acknowledging
> >> that they're not optimal for storage and we may propose changes in 18.08.
> [Shally] Sounds good to us too.
> 
> @Ahmed Mansour . I am assuming that transferring from mbuf to regular buffers 
> and back does
> >not involve some time consuming work like data copying and such.
> [Shally] I too assume copying shouldn't be a need and a big no-no. We 
> normally extract and pass buf_addr
> from mbuf as it is to HW.
> So implicit assumption is data memory is dma-able to device.
[Fiona] agreed

> 
> Thanks
> Shally
> 
> >-Original Message-
> >From: Ahmed Mansour [mailto:ahmed.mans...@nxp.com]
> >Sent: 15 March 2018 00:32
> >To: Trahe, Fiona ; Verma, Shally 
> >; dev@dpdk.org
> >Cc: De Lara Guarch, Pablo ; Athreya, 
> >Narayana Prasad
> ;
> >Gupta, Ashish ; Sahu, Sunila 
> >; Challa, Mahipal
> >; Jain, Deepak K ; 
> >Hemant Agrawal
> ; Roy
> >Pledge ; Youri Querry ; Daly, Lee
> ; Jozwiak, TomaszX
> >; Alok Makhariya ; 
> >Shreyansh Jain
> 
> >Subject: Re: [dpdk-dev] [PATCH] compressdev: implement API - mbuf alternative
> >
> >Hi All,
> >
> >Sticking with mbufs until at least 1805 works for us. We also see
> >storage as the main use case, but ipcomp maybe an important customer use
> >case in the future. Nonetheless, I see the mbuf formatting as inherently
> >external to the compressdev APIs. An application doing ipcomp should
> >just do the mbuf packaging outside of compressdev. At least that is what
> >current software implementation of ipcomp do when using zlib.net. I am
> >assuming that transferring from mbuf to regular buffers and back does
> >not involve some time consuming work like data copying and such.
> >
> >Thanks,
> >
> >Ahmed
> >
> >On 3/14/2018 2:39 PM, Trahe, Fiona wrote:
> >> Hi Shally, Ahmed, et al,
> >>
> >> Following internal and community feedback we've decided that there's still 
> >> too much churn in this.
> >> We're proposing, in the interest of getting the API out in 18.05, to stick 
> >> with mbufs - acknowledging
> >> that they're not optimal for storage and we may propose changes in 18.08.
> >> Compressdev will start as an experimental API in 18.05 - we'll POC and 
> >> benchmark alternatives
> >> or API extensions once we get time to do so.
> >>
> >> Regards,
> >> Fiona
> >>
> >>> -Original Message-
> >>> From: Verma, Shally [mailto:shally.ve...@cavium.com]
> >>> Sent: Wednesday, March 14, 2018 12:51 PM
> >>> To: Trahe, Fiona ; Ahmed Mansour 
> >>> ;
> dev@dpdk.org
> >>> Cc: De Lara Guarch, Pablo ; Athreya, 
> >>> Narayana Prasad
> >>> ; Gupta, Ashish 
> >>> ; Sahu, Sunila
> >>> ; Challa, Mahipal ; 
> >>> Jain, Deepak K
> >>> ; Hemant Agrawal ; Roy 
> >>> Pledge
> >>> ; Youri Querry ; Daly, Lee 
> >>> ;
> >>> Jozwiak, TomaszX 
> >>> Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf 
> >>> alternative
> >>>
> >>>
> >>>
>  -Original Message-
>  From: Trahe, Fiona [mailto:fiona.tr...@intel.com]
>  Sent: 13 March 2018 21:22
>  To: Verma, Shally ; Ahmed Mansour 
>  ;
> >>> dev@dpdk.org
>  Cc: De Lara Guarch, Pablo ; Athreya, 
>  Narayana Prasad
> >>> ;
>  Gupta, Ashish ; Sahu, Sunila 
>  ; Challa,
> Mahipal
>  ; Jain, Deepak K ; 
>  Hemant Agrawal
> >>> ; Roy
>  Pledge ; Youri Querry ; 
>  Daly, Lee
> >>> ; Jozwiak, TomaszX
>  ; Trahe, Fiona 
>  Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf 
>  alternative
> 
>  Hi Shally,
> 
> > -Original Message-
> > From: Verma, Shally [mailto:shally.ve...@cavium.com]
> > Sent: Tuesday, March 13, 2018 8:15 AM
> > To: Trahe, Fiona ; Ahmed Mansour 
> > ;
> >>> dev@dpdk.org
> > Cc: De Lara Guarch, Pablo ; Athreya, 
> > Narayana Prasad
> > ; Gupta, Ashish 
> > ; Sahu,
> Sunila
> > ; Challa, Mahipal ; 
> > Jain, Deepak K
> > ; Hemant Agrawal ; Roy 
> > Pledge
> > ; Youri Querry ; 
> > fiona.tr...@gmail.com; Daly,
> Lee
> > ; Jozwiak, TomaszX 
> > Subject: RE: [dpdk-dev] [PATCH] compressdev: implement API - mbuf 
> > alternative
> >
> > HI Fiona
> >
> > So I understand we're moving away from mbufs because of its size 
> > limitation (64k) and cacheline
> >>> overhead
> > and their more suitability to n/w applications. Given that, I 
> > understand benefit of having another
> >>> str

Re: [dpdk-dev] [PATCH v2 6/6] vhost: export new apis

[Wang, Zhihong]

> -Original Message-
> From: Tan, Jianfeng
> Sent: Tuesday, March 6, 2018 5:52 PM
> To: Wang, Zhihong ; dev@dpdk.org
> Cc: Bie, Tiwei ; maxime.coque...@redhat.com;
> y...@fridaylinux.org; Liang, Cunming ; Wang, Xiao
> W ; Daly, Dan 
> Subject: RE: [PATCH v2 6/6] vhost: export new apis
> 
> 
> 
> > -Original Message-
> > From: Wang, Zhihong
> > Sent: Tuesday, February 13, 2018 5:21 PM
> > To: dev@dpdk.org
> > Cc: Tan, Jianfeng; Bie, Tiwei; maxime.coque...@redhat.com;
> > y...@fridaylinux.org; Liang, Cunming; Wang, Xiao W; Daly, Dan; Wang,
> > Zhihong
> > Subject: [PATCH v2 6/6] vhost: export new apis
> >
> > This patch exports new APIs as experimental.
> 
> How about squeezing this patch with patch 2 where the APIs are introduced,
> as well as the related doc update?

Ok, will do that.

Thanks
-Zhihong

> 
> Thanks,
> Jianfeng
> 
> >
> > Signed-off-by: Zhihong Wang 
> > ---
> >  lib/librte_vhost/rte_vdpa.h| 16 +++-
> >  lib/librte_vhost/rte_vhost.h   | 33 ++-
> --
> >  lib/librte_vhost/rte_vhost_version.map | 19 +++
> >  3 files changed, 52 insertions(+), 16 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vdpa.h b/lib/librte_vhost/rte_vdpa.h
> > index 1bde36f7f..23fb471be 100644
> > --- a/lib/librte_vhost/rte_vdpa.h
> > +++ b/lib/librte_vhost/rte_vdpa.h
> > @@ -100,15 +100,21 @@ extern struct rte_vdpa_engine *vdpa_engines[];
> >  extern uint32_t vdpa_engine_num;
> >
> >  /* engine management */
> > -int rte_vdpa_register_engine(const char *name, struct
> rte_vdpa_eng_addr
> > *addr);
> > -int rte_vdpa_unregister_engine(int eid);
> > +int __rte_experimental
> > +rte_vdpa_register_engine(const char *name, struct rte_vdpa_eng_addr
> > *addr);
> >
> > -int rte_vdpa_find_engine_id(struct rte_vdpa_eng_addr *addr);
> > +int __rte_experimental
> > +rte_vdpa_unregister_engine(int eid);
> >
> > -int rte_vdpa_info_query(int eid, struct rte_vdpa_eng_attr *attr);
> > +int __rte_experimental
> > +rte_vdpa_find_engine_id(struct rte_vdpa_eng_addr *addr);
> > +
> > +int __rte_experimental
> > +rte_vdpa_info_query(int eid, struct rte_vdpa_eng_attr *attr);
> >
> >  /* driver register api */
> > -void rte_vdpa_register_driver(struct rte_vdpa_eng_driver *drv);
> > +void __rte_experimental
> > +rte_vdpa_register_driver(struct rte_vdpa_eng_driver *drv);
> >
> >  #define RTE_VDPA_REGISTER_DRIVER(nm, drv) \
> >  RTE_INIT(vdpainitfn_ ##nm); \
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index 48005d9ff..d5589c543 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -187,7 +187,8 @@ int rte_vhost_driver_unregister(const char *path);
> >   * @return
> >   *  0 on success, -1 on failure
> >   */
> > -int rte_vhost_driver_set_vdpa_eid(const char *path, int eid);
> > +int __rte_experimental
> > +rte_vhost_driver_set_vdpa_eid(const char *path, int eid);
> >
> >  /**
> >   * Set the device id, enforce single connection per socket
> > @@ -199,7 +200,8 @@ int rte_vhost_driver_set_vdpa_eid(const char
> *path,
> > int eid);
> >   * @return
> >   *  0 on success, -1 on failure
> >   */
> > -int rte_vhost_driver_set_vdpa_did(const char *path, int did);
> > +int __rte_experimental
> > +rte_vhost_driver_set_vdpa_did(const char *path, int did);
> >
> >  /**
> >   * Get the engine id
> > @@ -209,7 +211,8 @@ int rte_vhost_driver_set_vdpa_did(const char
> *path,
> > int did);
> >   * @return
> >   *  Engine id, -1 on failure
> >   */
> > -int rte_vhost_driver_get_vdpa_eid(const char *path);
> > +int __rte_experimental
> > +rte_vhost_driver_get_vdpa_eid(const char *path);
> >
> >  /**
> >   * Get the device id
> > @@ -219,7 +222,8 @@ int rte_vhost_driver_get_vdpa_eid(const char
> *path);
> >   * @return
> >   *  Device id, -1 on failure
> >   */
> > -int rte_vhost_driver_get_vdpa_did(const char *path);
> > +int __rte_experimental
> > +rte_vhost_driver_get_vdpa_did(const char *path);
> >
> >  /**
> >   * Set the feature bits the vhost-user driver supports.
> > @@ -286,7 +290,8 @@ int rte_vhost_driver_get_features(const char *path,
> > uint64_t *features);
> >   * @return
> >   *  0 on success, -1 on failure
> >   */
> > -int rte_vhost_driver_get_protocol_features(const char *path,
> > +int __rte_experimental
> > +rte_vhost_driver_get_protocol_features(const char *path,
> > uint64_t *protocol_features);
> >
> >  /**
> > @@ -299,7 +304,8 @@ int rte_vhost_driver_get_protocol_features(const
> > char *path,
> >   * @return
> >   *  0 on success, -1 on failure
> >   */
> > -int rte_vhost_driver_get_queue_num(const char *path, uint32_t
> > *queue_num);
> > +int __rte_experimental
> > +rte_vhost_driver_get_queue_num(const char *path, uint32_t
> > *queue_num);
> >
> >  /**
> >   * Get the feature bits after negotiation
> > @@ -523,7 +529,8 @@ uint32_t rte_vhost_rx_queue_count(int vid,
> uint16_t
> > qid);
> >   * @return
> >   *  0 on success, -1 on failure
> >   */
> > -int rt

Re: [dpdk-dev] [PATCH v2 1/6] vhost: export vhost feature definitions

[Wang, Zhihong]

> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> Sent: Tuesday, March 6, 2018 10:03 PM
> To: Tan, Jianfeng ; Wang, Zhihong
> ; dev@dpdk.org
> Cc: Bie, Tiwei ; y...@fridaylinux.org; Liang, Cunming
> ; Wang, Xiao W ; Daly,
> Dan 
> Subject: Re: [PATCH v2 1/6] vhost: export vhost feature definitions
> 
> 
> 
> On 03/06/2018 10:37 AM, Tan, Jianfeng wrote:
> >
> >
> >> -Original Message-
> >> From: Wang, Zhihong
> >> Sent: Tuesday, February 13, 2018 5:21 PM
> >> To: dev@dpdk.org
> >> Cc: Tan, Jianfeng; Bie, Tiwei; maxime.coque...@redhat.com;
> >> y...@fridaylinux.org; Liang, Cunming; Wang, Xiao W; Daly, Dan; Wang,
> >> Zhihong
> >> Subject: [PATCH v2 1/6] vhost: export vhost feature definitions
> >>
> >> This patch exports vhost-user protocol features to support device driver
> >> development.
> >>
> >> Signed-off-by: Zhihong Wang 
> >> ---
> >>   lib/librte_vhost/rte_vhost.h  |  8 
> >>   lib/librte_vhost/vhost.h  |  4 +---
> >>   lib/librte_vhost/vhost_user.c |  9 +
> >>   lib/librte_vhost/vhost_user.h | 20 +++-
> >>   4 files changed, 21 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> >> index d33206997..b05162366 100644
> >> --- a/lib/librte_vhost/rte_vhost.h
> >> +++ b/lib/librte_vhost/rte_vhost.h
> >> @@ -29,6 +29,14 @@ extern "C" {
> >>   #define RTE_VHOST_USER_DEQUEUE_ZERO_COPY (1ULL << 2)
> >>   #define RTE_VHOST_USER_IOMMU_SUPPORT (1ULL << 3)
> >>
> >> +#define RTE_VHOST_USER_PROTOCOL_F_MQ  0
> >
> > Instead of adding a "RTE_" prefix. I prefer to define it like this:
> > #ifndef VHOST_USER_PROTOCOL_F_MQ
> > #define VHOST_USER_PROTOCOL_F_MQ   0
> > #endif
> >
> > Similar to other macros.
> 
> I agree, it is better to keep same naming as in the spec IMHO.

Ok. Thanks Jianfeng and Maxime.

> 
> >> +#define RTE_VHOST_USER_PROTOCOL_F_LOG_SHMFD   1
> >> +#define RTE_VHOST_USER_PROTOCOL_F_RARP2
> >> +#define RTE_VHOST_USER_PROTOCOL_F_REPLY_ACK   3
> >> +#define RTE_VHOST_USER_PROTOCOL_F_NET_MTU 4
> >> +#define RTE_VHOST_USER_PROTOCOL_F_SLAVE_REQ   5
> >> +#define RTE_VHOST_USER_F_PROTOCOL_FEATURES30
> 
> Please put the above declaration separately, it could be misleading,
> making to think it is a vhost-user protocol feature whereas it is a
> Virtio feature.

Good point. Will change it.

-Zhihong

> 
> >> +
> >>   /**
> >>* Information relating to memory regions including offsets to
> >>* addresses in QEMUs memory file.
> >> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> >> index 58aec2e0d..a0b0520e2 100644
> >> --- a/lib/librte_vhost/vhost.h
> >> +++ b/lib/librte_vhost/vhost.h
> >> @@ -174,8 +174,6 @@ struct vhost_msg {
> >>#define VIRTIO_F_VERSION_1 32
> >>   #endif
> >>
> >> -#define VHOST_USER_F_PROTOCOL_FEATURES30
> >> -
> >>   /* Features supported by this builtin vhost-user net driver. */
> >>   #define VIRTIO_NET_SUPPORTED_FEATURES ((1ULL <<
> >> VIRTIO_NET_F_MRG_RXBUF) | \
> >>(1ULL << VIRTIO_F_ANY_LAYOUT) | \
> >> @@ -185,7 +183,7 @@ struct vhost_msg {
> >>(1ULL << VIRTIO_NET_F_MQ)  | \
> >>(1ULL << VIRTIO_F_VERSION_1)   | \
> >>(1ULL << VHOST_F_LOG_ALL)  | \
> >> -  (1ULL <<
> >> VHOST_USER_F_PROTOCOL_FEATURES) | \
> >> +  (1ULL <<
> >> RTE_VHOST_USER_F_PROTOCOL_FEATURES) | \
> >>(1ULL << VIRTIO_NET_F_GSO) | \
> >>(1ULL << VIRTIO_NET_F_HOST_TSO4) | \
> >>(1ULL << VIRTIO_NET_F_HOST_TSO6) | \
> >> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> >> index 5c5361066..c93e48e4d 100644
> >> --- a/lib/librte_vhost/vhost_user.c
> >> +++ b/lib/librte_vhost/vhost_user.c
> >> @@ -527,7 +527,7 @@ vhost_user_set_vring_addr(struct virtio_net
> **pdev,
> >> VhostUserMsg *msg)
> >>vring_invalidate(dev, vq);
> >>
> >>if (vq->enabled && (dev->features &
> >> -  (1ULL <<
> >> VHOST_USER_F_PROTOCOL_FEATURES))) {
> >> +  (1ULL <<
> >> RTE_VHOST_USER_F_PROTOCOL_FEATURES))) {
> >>dev = translate_ring_addresses(dev, msg-
> >>> payload.addr.index);
> >>if (!dev)
> >>return -1;
> >> @@ -897,11 +897,11 @@ vhost_user_set_vring_kick(struct virtio_net
> >> **pdev, struct VhostUserMsg *pmsg)
> >>vq = dev->virtqueue[file.index];
> >>
> >>/*
> >> -   * When VHOST_USER_F_PROTOCOL_FEATURES is not negotiated,
> >> +   * When RTE_VHOST_USER_F_PROTOCOL_FEATURES is not
> >> negotiated,
> >> * the ring starts already enabled. Otherwise, it is enabled via
> >> * the SET_VRING_ENABLE message.
> >> */
> >> -  if (!(dev->features & (1ULL <<
> >> VHOST_USER_F_PROTOCOL_FEATUR

[dpdk-dev] [PATCH] net/mlx5: fix TSO enablement

[Shahaf Shuler]

TSO should be set if either of the TSO offload flags is requested.

Fixes: dbccb4cddcd2 ("net/mlx5: convert to new Tx offloads API")
Cc: sta...@dpdk.org

Signed-off-by: Shahaf Shuler 
Acked-by: Yongseok Koh 
---
 drivers/net/mlx5/mlx5_txq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index ed1c713ea..42996e8db 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -651,7 +651,9 @@ txq_set_params(struct mlx5_txq_ctrl *txq_ctrl)
unsigned int inline_max_packet_sz;
eth_tx_burst_t tx_pkt_burst = priv_select_tx_function(priv, priv->dev);
int is_empw_func = is_empw_burst_func(tx_pkt_burst);
-   int tso = !!(txq_ctrl->txq.offloads & DEV_TX_OFFLOAD_TCP_TSO);
+   int tso = !!(txq_ctrl->txq.offloads & (DEV_TX_OFFLOAD_TCP_TSO |
+  DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
+  DEV_TX_OFFLOAD_GRE_TNL_TSO));
 
txq_inline = (config->txq_inline == MLX5_ARG_UNSET) ?
0 : config->txq_inline;
-- 
2.12.0

Re: [dpdk-dev] [PATCH v1 3/9] mempool: remove callback to get capabilities

[Andrew Rybchenko]

On 03/15/2018 12:48 PM, Burakov, Anatoly wrote:

On 14-Mar-18 5:24 PM, Andrew Rybchenko wrote:

On 03/14/2018 07:53 PM, Burakov, Anatoly wrote:

On 14-Mar-18 4:12 PM, Andrew Rybchenko wrote:

On 03/14/2018 05:40 PM, Burakov, Anatoly wrote:

On 10-Mar-18 3:39 PM, Andrew Rybchenko wrote:

The callback was introduced to let generic code to know octeontx
mempool driver requirements to use single physically contiguous
memory chunk to store all objects and align object address to
total object size. Now these requirements are met using a new
callbacks to calculate required memory chunk size and to populate
objects using provided memory chunk.

These capability flags are not used anywhere else.

Restricting capabilities to flags is not generic and likely to
be insufficient to describe mempool driver features. If required
in the future, API which returns structured information may be
added.

Signed-off-by: Andrew Rybchenko 
---


Just a general comment - it is not enough to describe minimum 
memchunk requirements. With memory hotplug patchset that's 
hopefully getting merged in 18.05, memzones will no longer be 
guaranteed to be IOVA-contiguous. So, if a driver requires its 
mempool to not only be populated from a single memzone, but a 
single *physically contiguous* memzone, going by only callbacks 
will not do, because whether or not something should be a single 
memzone says nothing about whether this memzone has to also be 
IOVA-contiguous.


So i believe this needs to stay in one form or another.

(also it would be nice to have a flag that a user could pass to 
mempool_create that would force memzone reservation be 
IOVA-contiguous, but that's a topic for another conversation. 
prime user for this would be KNI.)


I think that min_chunk_size should be treated as IOVA-contiguous.


Why? It's perfectly reasonable to e.g. implement a software mempool 
driver that would perform some optimizations due to all objects 
being in the same VA-contiguous memzone, yet not be dependent on 
underlying physical memory layout. These are two separate concerns IMO.


It looks like there is some misunderstanding here or I simply don't 
understand your point.
Above I mean that driver should be able to advertise its requirements 
on IOVA-contiguous regions.

If driver do not care about physical memory layout, no problem.


Please correct me if i'm wrong, but my understanding was that you 
wanted to use min_chunk as a way to express minimum requirements for 
IOVA-contiguous memory. If i understood you correctly, i don't think 
that's the way to go because there could be valid use cases where a 
mempool driver would like to advertise min_chunk_size to be equal to 
its total size (i.e. allocate everything in a single memzone), yet not 
require that memzone to be IOVA-contiguous. I think these are two 
different concerns, and one does not, and should not imply the other.


Aha, you're saying that virtual-contiguous and IOVA-contiguous 
requirements are different things that it could be usecases where 
virtual contiguous is important but IOVA-contiguos is not required. It 
is perfectly fine.
As I understand IOVA-contiguous (physical) typically means 
virtual-contiguous as well. Requirements to have everything virtually 
contiguous and some blocks physically contiguous are unlikely. So, it 
may be reduced to either virtual or physical contiguous. If mempool does 
not care about physical contiguous at all, MEMPOOL_F_NO_PHYS_CONTIG flag 
should be used and min_chunk_size should mean virtual contiguous 
requirements. If mempool requires physical contiguous objects, there is 
*no* MEMPOOL_F_NO_PHYS_CONTIG flag and min_chunk_size means physical 
contiguous requirements.





> So, we

have 4 levels:
  - MEMPOOL_F_NO_PHYS_CONTIG (min_chunk_size == 0) -- 
IOVA-congtiguous is not required at all
  - no MEMPOOL_F_NO_PHYS_CONTIG (min_chunk_size == total_obj_size) 
-- object should be IOVA-contiguous
  - min_chunk_size > total_obj_size  -- group of objects should be 
IOVA-contiguous
  - min_chunk_size ==  -- all objects should be 
IOVA-contiguous


I don't think this "automagic" decision on what should be 
IOVA-contiguous or not is the way to go. It needlessly complicates 
things, when all it takes is another flag passed to mempool 
allocator somewhere.


No, it is not just one flag. We really need option (3) above: group 
of objects IOVA-contiguous in [1].
Of course, it is possible to use option (4) instead: everything 
IOVA-contigous, but I think it is bad - it may be very big and 
hard/impossible to allocate due to fragmentation.




Exactly: we shouldn't be forcing IOVA-contiguous memory just because 
mempool requrested a big min_chunk_size, nor do i think it is wise to 
encode such heuristics (referring to your 4 "levels" quoted above) 
into the mempool allocator.


I'm not sure what is the best solution here. Perhaps another option 
would be to let mempool drivers allocate their memory as well? I.e. 
leave current behavior as default, as it

Re: [dpdk-dev] [PATCH v1 3/9] mempool: remove callback to get capabilities

[Burakov, Anatoly]

On 15-Mar-18 11:49 AM, Andrew Rybchenko wrote:

On 03/15/2018 12:48 PM, Burakov, Anatoly wrote:

On 14-Mar-18 5:24 PM, Andrew Rybchenko wrote:

On 03/14/2018 07:53 PM, Burakov, Anatoly wrote:

On 14-Mar-18 4:12 PM, Andrew Rybchenko wrote:

On 03/14/2018 05:40 PM, Burakov, Anatoly wrote:

On 10-Mar-18 3:39 PM, Andrew Rybchenko wrote:

The callback was introduced to let generic code to know octeontx
mempool driver requirements to use single physically contiguous
memory chunk to store all objects and align object address to
total object size. Now these requirements are met using a new
callbacks to calculate required memory chunk size and to populate
objects using provided memory chunk.

These capability flags are not used anywhere else.

Restricting capabilities to flags is not generic and likely to
be insufficient to describe mempool driver features. If required
in the future, API which returns structured information may be
added.

Signed-off-by: Andrew Rybchenko 
---


Just a general comment - it is not enough to describe minimum 
memchunk requirements. With memory hotplug patchset that's 
hopefully getting merged in 18.05, memzones will no longer be 
guaranteed to be IOVA-contiguous. So, if a driver requires its 
mempool to not only be populated from a single memzone, but a 
single *physically contiguous* memzone, going by only callbacks 
will not do, because whether or not something should be a single 
memzone says nothing about whether this memzone has to also be 
IOVA-contiguous.


So i believe this needs to stay in one form or another.

(also it would be nice to have a flag that a user could pass to 
mempool_create that would force memzone reservation be 
IOVA-contiguous, but that's a topic for another conversation. 
prime user for this would be KNI.)


I think that min_chunk_size should be treated as IOVA-contiguous.


Why? It's perfectly reasonable to e.g. implement a software mempool 
driver that would perform some optimizations due to all objects 
being in the same VA-contiguous memzone, yet not be dependent on 
underlying physical memory layout. These are two separate concerns IMO.


It looks like there is some misunderstanding here or I simply don't 
understand your point.
Above I mean that driver should be able to advertise its requirements 
on IOVA-contiguous regions.

If driver do not care about physical memory layout, no problem.


Please correct me if i'm wrong, but my understanding was that you 
wanted to use min_chunk as a way to express minimum requirements for 
IOVA-contiguous memory. If i understood you correctly, i don't think 
that's the way to go because there could be valid use cases where a 
mempool driver would like to advertise min_chunk_size to be equal to 
its total size (i.e. allocate everything in a single memzone), yet not 
require that memzone to be IOVA-contiguous. I think these are two 
different concerns, and one does not, and should not imply the other.


Aha, you're saying that virtual-contiguous and IOVA-contiguous 
requirements are different things that it could be usecases where 
virtual contiguous is important but IOVA-contiguos is not required. It 
is perfectly fine.
As I understand IOVA-contiguous (physical) typically means 
virtual-contiguous as well. Requirements to have everything virtually 
contiguous and some blocks physically contiguous are unlikely. So, it 
may be reduced to either virtual or physical contiguous. If mempool does 
not care about physical contiguous at all, MEMPOOL_F_NO_PHYS_CONTIG flag 
should be used and min_chunk_size should mean virtual contiguous 
requirements. If mempool requires physical contiguous objects, there is 
*no* MEMPOOL_F_NO_PHYS_CONTIG flag and min_chunk_size means physical 
contiguous requirements.




Fair point. I think we're in agreement now :) This will need to be 
documented then.


--
Thanks,
Anatoly

[dpdk-dev] [PATCH] net/mrvl: use proper constant for Rx descriptors number

[Tomasz Duszynski]

Since filling hardware buffer pool (bpool) is Rx related
constant describing maximum number of rx descriptors
instead of maximum number of Tx descriptors should be used.

Fixes: 0ddc9b815b11 ("net/mrvl: add net PMD skeleton")
Cc: sta...@dpdk.org

Signed-off-by: Marcin Wojtas 
Signed-off-by: Tomasz Duszynski 
---
 drivers/net/mrvl/mrvl_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mrvl/mrvl_ethdev.c b/drivers/net/mrvl/mrvl_ethdev.c
index ac8f2d6..be63739 100644
--- a/drivers/net/mrvl/mrvl_ethdev.c
+++ b/drivers/net/mrvl/mrvl_ethdev.c
@@ -1233,8 +1233,8 @@ mrvl_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
vlan_id, int on)
 static int
 mrvl_fill_bpool(struct mrvl_rxq *rxq, int num)
 {
-   struct buff_release_entry entries[MRVL_PP2_TXD_MAX];
-   struct rte_mbuf *mbufs[MRVL_PP2_TXD_MAX];
+   struct buff_release_entry entries[MRVL_PP2_RXD_MAX];
+   struct rte_mbuf *mbufs[MRVL_PP2_RXD_MAX];
int i, ret;
unsigned int core_id;
struct pp2_hif *hif;
-- 
2.7.4

Re: [dpdk-dev] [PATCH v1 3/9] mempool: remove callback to get capabilities

[Andrew Rybchenko]

On 03/15/2018 03:00 PM, Burakov, Anatoly wrote:

On 15-Mar-18 11:49 AM, Andrew Rybchenko wrote:

On 03/15/2018 12:48 PM, Burakov, Anatoly wrote:

On 14-Mar-18 5:24 PM, Andrew Rybchenko wrote:

On 03/14/2018 07:53 PM, Burakov, Anatoly wrote:

On 14-Mar-18 4:12 PM, Andrew Rybchenko wrote:

On 03/14/2018 05:40 PM, Burakov, Anatoly wrote:

On 10-Mar-18 3:39 PM, Andrew Rybchenko wrote:

The callback was introduced to let generic code to know octeontx
mempool driver requirements to use single physically contiguous
memory chunk to store all objects and align object address to
total object size. Now these requirements are met using a new
callbacks to calculate required memory chunk size and to populate
objects using provided memory chunk.

These capability flags are not used anywhere else.

Restricting capabilities to flags is not generic and likely to
be insufficient to describe mempool driver features. If required
in the future, API which returns structured information may be
added.

Signed-off-by: Andrew Rybchenko 
---


Just a general comment - it is not enough to describe minimum 
memchunk requirements. With memory hotplug patchset that's 
hopefully getting merged in 18.05, memzones will no longer be 
guaranteed to be IOVA-contiguous. So, if a driver requires its 
mempool to not only be populated from a single memzone, but a 
single *physically contiguous* memzone, going by only callbacks 
will not do, because whether or not something should be a single 
memzone says nothing about whether this memzone has to also be 
IOVA-contiguous.


So i believe this needs to stay in one form or another.

(also it would be nice to have a flag that a user could pass to 
mempool_create that would force memzone reservation be 
IOVA-contiguous, but that's a topic for another conversation. 
prime user for this would be KNI.)


I think that min_chunk_size should be treated as IOVA-contiguous.


Why? It's perfectly reasonable to e.g. implement a software 
mempool driver that would perform some optimizations due to all 
objects being in the same VA-contiguous memzone, yet not be 
dependent on underlying physical memory layout. These are two 
separate concerns IMO.


It looks like there is some misunderstanding here or I simply don't 
understand your point.
Above I mean that driver should be able to advertise its 
requirements on IOVA-contiguous regions.

If driver do not care about physical memory layout, no problem.


Please correct me if i'm wrong, but my understanding was that you 
wanted to use min_chunk as a way to express minimum requirements for 
IOVA-contiguous memory. If i understood you correctly, i don't think 
that's the way to go because there could be valid use cases where a 
mempool driver would like to advertise min_chunk_size to be equal to 
its total size (i.e. allocate everything in a single memzone), yet 
not require that memzone to be IOVA-contiguous. I think these are 
two different concerns, and one does not, and should not imply the 
other.


Aha, you're saying that virtual-contiguous and IOVA-contiguous 
requirements are different things that it could be usecases where 
virtual contiguous is important but IOVA-contiguos is not required. 
It is perfectly fine.
As I understand IOVA-contiguous (physical) typically means 
virtual-contiguous as well. Requirements to have everything virtually 
contiguous and some blocks physically contiguous are unlikely. So, it 
may be reduced to either virtual or physical contiguous. If mempool 
does not care about physical contiguous at all, 
MEMPOOL_F_NO_PHYS_CONTIG flag should be used and min_chunk_size 
should mean virtual contiguous requirements. If mempool requires 
physical contiguous objects, there is *no* MEMPOOL_F_NO_PHYS_CONTIG 
flag and min_chunk_size means physical contiguous requirements.




Fair point. I think we're in agreement now :) This will need to be 
documented then.


OK, I'll do. I don't mind to rebase mine patch series on top of yours, 
but I'd like to do it a bit later when yours is closer to final version 
or even applied - it has really many prerequisites (pre-series) which 
should be collected first. It is really major changes.

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Ananyev, Konstantin]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, March 14, 2018 9:03 PM
> To: Ananyev, Konstantin ; Shreyansh Jain 
> ; Horton, Remy
> ; dev@dpdk.org
> Cc: Lu, Wenzhuo ; Wu, Jingjing ; 
> Zhang, Qi Z ; Xing, Beilei
> ; Thomas Monjalon 
> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned 
> Tx/Rx parameters
> 
> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> >> Sent: Wednesday, March 14, 2018 5:52 PM
> >> To: Shreyansh Jain ; Horton, Remy 
> >> ; dev@dpdk.org
> >> Cc: Lu, Wenzhuo ; Wu, Jingjing 
> >> ; Zhang, Qi Z ; Xing, Beilei
> >> ; Thomas Monjalon 
> >> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
> >> PMD-tuned Tx/Rx parameters
> >>
> >> On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
>  -Original Message-
>  From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
>  Sent: Wednesday, March 14, 2018 10:13 PM
>  To: Remy Horton ; dev@dpdk.org
>  Cc: Wenzhuo Lu ; Jingjing Wu
>  ; Qi Zhang ; Beilei Xing
>  ; Shreyansh Jain ;
>  Thomas Monjalon 
>  Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
>  tuned Tx/Rx parameters
> 
>  On 3/14/2018 3:48 PM, Remy Horton wrote:
> >
> > On 14/03/2018 14:43, Ferruh Yigit wrote:
> > [..]
> >>>  lib/librte_ether/rte_ethdev.c | 18 ++
> >>>  lib/librte_ether/rte_ethdev.h | 15 +++
> >>
> >> Can you please remove deprecation notice in this patch.
> >
> > Done.
> >
> >>> + /* Defaults for drivers that don't implement preferred
> >>> +  * queue parameters.
> > [..]
> >> Not sure about having these defaults here. It is OK to have defaults
>  in driver,
> >> in application or in config file, but I am not sure if putting them
>  into device
> >> abstraction layer hides them.
> >>
> >> What about not providing any default in ethdev layer, and get zero
>  as invalid
> >> when using them?
> >
> > This is something I have been thinking about, and I am going to
>  remove
> > them for the V2. Original motive was to avoid breaking testpmd for
>  PMDs
> > that don't give defaults (i.e. almost all of them). The alternative
>  is
> > to put place-holders into all the PMDs themselves, but I am not sure
>  if
> > this is appropriate.
> 
>  I think preferred values should be optional, PMD should have right to
>  not
>  provide any. Implementation in 4/4 forces preferred values, either in
>  all PMDs
>  or in ethdev layer.
> 
>  What about changing approach in application:
>   is preferred value provided [1] ?
>    yes => use it by sending value 0
>    no => use application provided value, same as now, so control should
>  be in
>  application.
> 
>  I am aware this breaks the comfort of just providing 0 and PMD values
>  will be
>  used but covers the case there is no PMD values.
> 
>  [1]
>  it can be possible to check if preferred value provided by comparing 0,
>  but if 0
>  is a valid value that can be problem. It may not be problem with
>  current
>  variables but it may be when this struct extended, it may be good to
>  think about
>  alternative here.
> >>>
> >>> I don't think we should use the condition of "yes => use it by sending 
> >>> value 0". That is non-intuitive. Ideally, the application should query
> >> and then if query responds with value as '0' (which can be valid for some 
> >> variables in future), it sends its own value to setup functions
> >> (whether '0' or something else, in case of 0 response, would depend on the 
> >> knob).
> >>
> >> Right, at that stage application already knows what is the preferred value 
> >> and
> >> can directly use it.
> >>
> >>
> >> Will it be too much to:
> >>
> >> 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer PMD
> >> values. "prefer_device_values" ?
> >> Application can provide values as usual, but if that field is set, 
> >> abstraction
> >> layer overwrites the application values with PMD preferred ones. If there 
> >> is no
> >> PMD preferred values continue using application ones.
> >>
> >>
> >> 2) Add a bitwise "is_set" field to new "preferred_size" struct, which may 
> >> show
> >> status of other fields in the struct, if PMD set a valid value for them or 
> >> not,
> >> so won't have to rely on the 0 check.
> >
> > That all seems like too much hassle for such small thing.
> 
> Fair enough.
> 
> > If we really want to allow PMD not to provide preferred values -
> > then instead of adding rte_eth_dev_pref_info into dev_info we can simply
> > introduce a new optional ethdev API call:
> > rte_eth_get_pref_params() or so.
> > If the PMD doesn’t want to provide preferred params to the user it s

Re: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup

[Ananyev, Konstantin]

Hi Qi,

> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 15, 2018 3:14 AM
> To: Ananyev, Konstantin ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing 
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> 
> Hi Konstantin:
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Wednesday, March 14, 2018 8:32 PM
> > To: Zhang, Qi Z ; tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo ; Zhang, Qi Z
> > 
> > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> >
> > Hi Qi,
> >
> > >
> > > The patch let etherdev driver expose the capability flag through
> > > rte_eth_dev_info_get when it support deferred queue configuraiton,
> > > then base on the flag rte_eth_[rx|tx]_queue_setup could decide
> > > continue to setup the queue or just return fail when device already
> > > started.
> > >
> > > Signed-off-by: Qi Zhang 
> > > ---
> > >  doc/guides/nics/features.rst  |  8 
> > > lib/librte_ether/rte_ethdev.c | 30 ++
> > > lib/librte_ether/rte_ethdev.h | 11 +++
> > >  3 files changed, 37 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/doc/guides/nics/features.rst
> > > b/doc/guides/nics/features.rst index 1b4fb979f..36ad21a1f 100644
> > > --- a/doc/guides/nics/features.rst
> > > +++ b/doc/guides/nics/features.rst
> > > @@ -892,7 +892,15 @@ Documentation describes performance values.
> > >
> > >  See ``dpdk.org/doc/perf/*``.
> > >
> > > +.. _nic_features_queue_deferred_setup_capabilities:
> > >
> > > +Queue deferred setup capabilities
> > > +-
> > > +
> > > +Supports queue setup / release after device started.
> > > +
> > > +* **[provides] rte_eth_dev_info**:
> > >
> > ``deferred_queue_config_capa:DEV_DEFERRED_RX_QUEUE_SETUP,DEV_DEFE
> > RRED_
> > > TX_QUEUE_SETUP,DEV_DEFERRED_RX_QUEUE_RELE
> > > ASE,DEV_DEFERRED_TX_QUEUE_RELEASE``.
> > > +* **[related]  API**: ``rte_eth_dev_info_get()``.
> > >
> > >  .. _nic_features_other:
> > >
> > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > b/lib/librte_ether/rte_ethdev.c index a6ce2a5ba..6c906c4df 100644
> > > --- a/lib/librte_ether/rte_ethdev.c
> > > +++ b/lib/librte_ether/rte_ethdev.c
> > > @@ -1425,12 +1425,6 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> > uint16_t rx_queue_id,
> > >   return -EINVAL;
> > >   }
> > >
> > > - if (dev->data->dev_started) {
> > > - RTE_PMD_DEBUG_TRACE(
> > > - "port %d must be stopped to allow configuration\n", 
> > > port_id);
> > > - return -EBUSY;
> > > - }
> > > -
> > >   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get,
> > -ENOTSUP);
> > >   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_setup,
> > -ENOTSUP);
> > >
> > > @@ -1474,10 +1468,19 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> > uint16_t rx_queue_id,
> > >   return -EINVAL;
> > >   }
> > >
> > > + if (dev->data->dev_started &&
> > > + !(dev_info.deferred_queue_config_capa &
> > > + DEV_DEFERRED_RX_QUEUE_SETUP))
> > > + return -EINVAL;
> > > +
> >
> > I think now you have to check here that the queue is stopped.
> > Otherwise you might attempt to reconfigure running queue.
> 
> I'm not sure if it's necessary to let application use different API sequence 
> for a deferred configure and deferred re-configure.
> Can we just call dev_ops->rx_queue_stop before rx_queue_release here

I don't follow you here.
Let say now inside queue_start() we do check:

if (dev->data->rx_queue_state[rx_queue_id] != RTE_ETH_QUEUE_STATE_STOPPED)

Right now it is not possible to call queue_setup() without dev_stop() before it 
-
that's why we have check if (dev->data->dev_started) in queue_setup() right now.
Though with your patch it not the case anymore - user is able to call 
queue_setup()
without stopping the whole device.
But he still has to stop the queue. 

> 
> >
> >
> > >   rxq = dev->data->rx_queues;
> > >   if (rxq[rx_queue_id]) {
> > >   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_release,
> > >   -ENOTSUP);
> >
> > I don't think it is *that* straightforward.
> > rx_queue_setup() parameters can imply different rx function (and related dev
> > icesettings) that are already setuped by previous queue_setup()/dev_start.
> > So I think you need to do one of 2 things:
> > 1. rework ethdev layer to introduce a separate rx function (and related
> > settings) for each queue.
> > 2. at rx_queue_setup() if it is invoked after dev_start - check that given
> > queue settings wouldn't contradict with current device settings  (rx 
> > function,
> > etc.).
> > If they do - return an error.
> Yes, I think what we have is option 2 here, the dev_ops->rx_queue_setup will 
> return fail if conflict with previous setting

Hmm and what makes you think that?
As I know it is not the case  right now.
Let say I do:

   rx_queue_setup(port=

Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup

[Ananyev, Konstantin]

> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 15, 2018 3:22 AM
> To: Ananyev, Konstantin ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing 
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Wednesday, March 14, 2018 8:36 PM
> > To: Zhang, Qi Z ; tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo ; Zhang, Qi Z
> > 
> > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > setup
> >
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > Sent: Friday, March 2, 2018 4:13 AM
> > > To: tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo ; Zhang,
> > Qi
> > > Z 
> > > Subject: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > > setup
> > >
> > > Expose the deferred queue configuration capability and enhance
> > > i40e_dev_[rx|tx]_queue_[setup|release] to handle the situation when
> > > device already started.
> > >
> > > Signed-off-by: Qi Zhang 
> > > ---
> > >  drivers/net/i40e/i40e_ethdev.c |  6 
> > >  drivers/net/i40e/i40e_rxtx.c   | 62
> > --
> > >  2 files changed, 66 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > b/drivers/net/i40e/i40e_ethdev.c index 06b0f03a1..843a0c42a 100644
> > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > @@ -3195,6 +3195,12 @@ i40e_dev_info_get(struct rte_eth_dev *dev,
> > struct rte_eth_dev_info *dev_info)
> > >   DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > >   DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > >   DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> > > + dev_info->deferred_queue_config_capa =
> > > + DEV_DEFERRED_RX_QUEUE_SETUP |
> > > + DEV_DEFERRED_TX_QUEUE_SETUP |
> > > + DEV_DEFERRED_RX_QUEUE_RELEASE |
> > > + DEV_DEFERRED_TX_QUEUE_RELEASE;
> > > +
> > >   dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
> > >   sizeof(uint32_t);
> > >   dev_info->reta_size = pf->hash_lut_size; diff --git
> > > a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c index
> > > 1217e5a61..e5f532cf7 100644
> > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > @@ -1712,6 +1712,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev
> > *dev,
> > >   uint16_t len, i;
> > >   uint16_t reg_idx, base, bsf, tc_mapping;
> > >   int q_offset, use_def_burst_func = 1;
> > > + int ret = 0;
> > >
> > >   if (hw->mac.type == I40E_MAC_VF || hw->mac.type ==
> > I40E_MAC_X722_VF) {
> > >   vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > > @@ -1841,6 +1842,25 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev
> > *dev,
> > >   rxq->dcb_tc = i;
> > >   }
> > >
> > > + if (dev->data->dev_started) {
> > > + ret = i40e_rx_queue_init(rxq);
> > > + if (ret != I40E_SUCCESS) {
> > > + PMD_DRV_LOG(ERR,
> > > + "Failed to do RX queue initialization");
> > > + return ret;
> > > + }
> > > + if (ad->rx_vec_allowed)
> >
> > Better to check what rx function is installed right now.
> Yes, it should be fixed, need to return fail if any conflict
> >
> > > + i40e_rxq_vec_setup(rxq);
> > > + if (!rxq->rx_deferred_start) {
> > > + ret = i40e_dev_rx_queue_start(dev, queue_idx);
> >
> > I don't think it is a good idea to start/stop queue inside
> > queue_setup/queue_release.
> > There is special API (queue_start/queue_stop) to do this.
> 
> The idea is if dev already started, the queue is supposed to be started 
> automatically after queue_setup.

Why is that?
Might be user doesn't want to start queue, might be he only wants to start it.
Might be he would need to call queue_setup() once again later before starting 
it - based on some logic?
If the user wants to setup and start the queue immediately he can always do:

rc = queue_setup(...);
if (rc == 0)
   queue_start(...);

We have a pretty well defined API here let's keep it like that.
Konstantin

Re: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for deferred queue setup

[Ananyev, Konstantin]

> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 15, 2018 3:58 AM
> To: Ananyev, Konstantin ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing 
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for 
> deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Thursday, March 15, 2018 1:39 AM
> > To: Zhang, Qi Z ; tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo ; Zhang, Qi Z
> > 
> > Subject: RE: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for
> > deferred queue setup
> >
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > Sent: Friday, March 2, 2018 4:13 AM
> > > To: tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo ; Zhang,
> > Qi
> > > Z 
> > > Subject: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for
> > > deferred queue setup
> > >
> > > Add two parameters:
> > > rxq-setup: set the number of RX queues be setup before device started
> > > txq-setup: set the number of TX queues be setup before device started.
> >
> > Not sure we do need these new parameters at all - in next patch you
> > introduce ability to do queue_setup from command-line.
> > Plus we already have an ability to do queue_stop/queue_start from
> > command-line.
> > I think that would be enough for testing.
> > Konstantin
> 
> Without these parameters, we can only reconfigure a queue after dev_start, 
> but not the case that deferred configure a fresh queue.

We do have:
port stop
port config all (rxq|txq) (value)
port start

If we'll add a new command to specify which queues should be deferred at 
dev_start -
wouldn't that be enough?


> 
> >
> >
> > >
> > > Signed-off-by: Qi Zhang 
> > > ---
> > >  app/test-pmd/parameters.c | 29
> > +
> > >  app/test-pmd/testpmd.c|  8 ++--
> > >  app/test-pmd/testpmd.h|  2 ++
> > >  doc/guides/testpmd_app_ug/run_app.rst | 12 
> > >  4 files changed, 49 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> > > index 97d22b860..497259ee7 100644
> > > --- a/app/test-pmd/parameters.c
> > > +++ b/app/test-pmd/parameters.c
> > > @@ -146,8 +146,12 @@ usage(char* progname)
> > >   printf("  --rss-ip: set RSS functions to IPv4/IPv6 only .\n");
> > >   printf("  --rss-udp: set RSS functions to IPv4/IPv6 + UDP.\n");
> > >   printf("  --rxq=N: set the number of RX queues per port to N.\n");
> > > + printf("  --rxq-setup=N: set the number of RX queues be setup before"
> > > +"device start to N.\n");
> > >   printf("  --rxd=N: set the number of descriptors in RX rings to N.\n");
> > >   printf("  --txq=N: set the number of TX queues per port to N.\n");
> > > + printf("  --txq-setup=N: set the number of TX queues be setup before"
> > > +"device start to N.\n");
> > >   printf("  --txd=N: set the number of descriptors in TX rings to N.\n");
> > >   printf("  --burst=N: set the number of packets per burst to N.\n");
> > >   printf("  --mbcache=N: set the cache of mbuf memory pool to N.\n");
> > > @@ -596,7 +600,9 @@ launch_args_parse(int argc, char** argv)
> > >   { "rss-ip", 0, 0, 0 },
> > >   { "rss-udp",0, 0, 0 },
> > >   { "rxq",1, 0, 0 },
> > > + { "rxq-setup",  1, 0, 0 },
> > >   { "txq",1, 0, 0 },
> > > + { "txq-setup",  1, 0, 0 },
> > >   { "rxd",1, 0, 0 },
> > >   { "txd",1, 0, 0 },
> > >   { "burst",  1, 0, 0 },
> > > @@ -933,6 +939,15 @@ launch_args_parse(int argc, char** argv)
> > > " >= 0 && <= %u\n", n,
> > > get_allowed_max_nb_rxq(&pid));
> > >   }
> > > + if (!strcmp(lgopts[opt_idx].name, "rxq-setup")) {
> > > + n = atoi(optarg);
> > > + if (n >= 0 && check_nb_rxq((queueid_t)n) == 0)
> > > + nb_rxq_setup = (queueid_t) n;
> > > + else
> > > + rte_exit(EXIT_FAILURE, "rxq-setup %d 
> > > invalid - must
> > be"
> > > +   " >= 0 && <= %u\n", n,
> > > +   get_allowed_max_nb_rxq(&pid));
> > > + }
> > >   if (!strcmp(lgopts[opt_idx].name, "txq")) {
> > >   n = atoi(optarg);
> > >   if (n >= 0 && check_nb_txq((queueid_t)n) == 0) 
> > > @@
> > -942,6 +957,15
> > > @@ launch_args_parse(int argc, char** argv)
> > 

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Ferruh Yigit]

On 3/14/2018 9:36 PM, Bruce Richardson wrote:
> On Wed, Mar 14, 2018 at 09:02:47PM +, Ferruh Yigit wrote:
>> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
>>>
>>>
 -Original Message-
 From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
 Sent: Wednesday, March 14, 2018 5:52 PM
 To: Shreyansh Jain ; Horton, Remy 
 ; dev@dpdk.org
 Cc: Lu, Wenzhuo ; Wu, Jingjing 
 ; Zhang, Qi Z ; Xing, Beilei
 ; Thomas Monjalon 
 Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
 PMD-tuned Tx/Rx parameters

 On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
>> -Original Message-
>> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
>> Sent: Wednesday, March 14, 2018 10:13 PM
>> To: Remy Horton ; dev@dpdk.org
>> Cc: Wenzhuo Lu ; Jingjing Wu
>> ; Qi Zhang ; Beilei Xing
>> ; Shreyansh Jain ;
>> Thomas Monjalon 
>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
>> tuned Tx/Rx parameters
>>
>> On 3/14/2018 3:48 PM, Remy Horton wrote:
>>>
>>> On 14/03/2018 14:43, Ferruh Yigit wrote:
>>> [..]
>  lib/librte_ether/rte_ethdev.c | 18 ++
>  lib/librte_ether/rte_ethdev.h | 15 +++

 Can you please remove deprecation notice in this patch.
>>>
>>> Done.
>>>
> + /* Defaults for drivers that don't implement preferred
> +  * queue parameters.
>>> [..]
 Not sure about having these defaults here. It is OK to have defaults
>> in driver,
 in application or in config file, but I am not sure if putting them
>> into device
 abstraction layer hides them.

 What about not providing any default in ethdev layer, and get zero
>> as invalid
 when using them?
>>>
>>> This is something I have been thinking about, and I am going to
>> remove
>>> them for the V2. Original motive was to avoid breaking testpmd for
>> PMDs
>>> that don't give defaults (i.e. almost all of them). The alternative
>> is
>>> to put place-holders into all the PMDs themselves, but I am not sure
>> if
>>> this is appropriate.
>>
>> I think preferred values should be optional, PMD should have right to
>> not
>> provide any. Implementation in 4/4 forces preferred values, either in
>> all PMDs
>> or in ethdev layer.
>>
>> What about changing approach in application:
>>  is preferred value provided [1] ?
>>   yes => use it by sending value 0
>>   no => use application provided value, same as now, so control should
>> be in
>> application.
>>
>> I am aware this breaks the comfort of just providing 0 and PMD values
>> will be
>> used but covers the case there is no PMD values.
>>
>> [1]
>> it can be possible to check if preferred value provided by comparing 0,
>> but if 0
>> is a valid value that can be problem. It may not be problem with
>> current
>> variables but it may be when this struct extended, it may be good to
>> think about
>> alternative here.
>
> I don't think we should use the condition of "yes => use it by sending 
> value 0". That is non-intuitive. Ideally, the application should query
 and then if query responds with value as '0' (which can be valid for some 
 variables in future), it sends its own value to setup functions
 (whether '0' or something else, in case of 0 response, would depend on the 
 knob).

 Right, at that stage application already knows what is the preferred value 
 and
 can directly use it.


 Will it be too much to:

 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer PMD
 values. "prefer_device_values" ?
 Application can provide values as usual, but if that field is set, 
 abstraction
 layer overwrites the application values with PMD preferred ones. If there 
 is no
 PMD preferred values continue using application ones.


 2) Add a bitwise "is_set" field to new "preferred_size" struct, which may 
 show
 status of other fields in the struct, if PMD set a valid value for them or 
 not,
 so won't have to rely on the 0 check.
>>>
>>> That all seems like too much hassle for such small thing.
>>
>> Fair enough.
>>
>>> If we really want to allow PMD not to provide preferred values -
>>> then instead of adding rte_eth_dev_pref_info into dev_info we can simply
>>> introduce a new optional ethdev API call:
>>> rte_eth_get_pref_params() or so.
>>> If the PMD doesn’t want to provide preferred params to the user it simply
>>> wouldn't implement that function. 
>>
>> Same can be done with updated rte_eth_dev_info.
>> Only application needs to check and use PMD preferred values, so this will 
>> mean
>> dropping "pass 0 to get preferred values" feature in initial

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Ferruh Yigit]

On 3/15/2018 12:51 PM, Ananyev, Konstantin wrote:
> 
> 
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Wednesday, March 14, 2018 9:03 PM
>> To: Ananyev, Konstantin ; Shreyansh Jain 
>> ; Horton, Remy
>> ; dev@dpdk.org
>> Cc: Lu, Wenzhuo ; Wu, Jingjing 
>> ; Zhang, Qi Z ; Xing, Beilei
>> ; Thomas Monjalon 
>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned 
>> Tx/Rx parameters
>>
>> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
>>>
>>>
 -Original Message-
 From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
 Sent: Wednesday, March 14, 2018 5:52 PM
 To: Shreyansh Jain ; Horton, Remy 
 ; dev@dpdk.org
 Cc: Lu, Wenzhuo ; Wu, Jingjing 
 ; Zhang, Qi Z ; Xing, Beilei
 ; Thomas Monjalon 
 Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
 PMD-tuned Tx/Rx parameters

 On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
>> -Original Message-
>> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
>> Sent: Wednesday, March 14, 2018 10:13 PM
>> To: Remy Horton ; dev@dpdk.org
>> Cc: Wenzhuo Lu ; Jingjing Wu
>> ; Qi Zhang ; Beilei Xing
>> ; Shreyansh Jain ;
>> Thomas Monjalon 
>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
>> tuned Tx/Rx parameters
>>
>> On 3/14/2018 3:48 PM, Remy Horton wrote:
>>>
>>> On 14/03/2018 14:43, Ferruh Yigit wrote:
>>> [..]
>  lib/librte_ether/rte_ethdev.c | 18 ++
>  lib/librte_ether/rte_ethdev.h | 15 +++

 Can you please remove deprecation notice in this patch.
>>>
>>> Done.
>>>
> + /* Defaults for drivers that don't implement preferred
> +  * queue parameters.
>>> [..]
 Not sure about having these defaults here. It is OK to have defaults
>> in driver,
 in application or in config file, but I am not sure if putting them
>> into device
 abstraction layer hides them.

 What about not providing any default in ethdev layer, and get zero
>> as invalid
 when using them?
>>>
>>> This is something I have been thinking about, and I am going to
>> remove
>>> them for the V2. Original motive was to avoid breaking testpmd for
>> PMDs
>>> that don't give defaults (i.e. almost all of them). The alternative
>> is
>>> to put place-holders into all the PMDs themselves, but I am not sure
>> if
>>> this is appropriate.
>>
>> I think preferred values should be optional, PMD should have right to
>> not
>> provide any. Implementation in 4/4 forces preferred values, either in
>> all PMDs
>> or in ethdev layer.
>>
>> What about changing approach in application:
>>  is preferred value provided [1] ?
>>   yes => use it by sending value 0
>>   no => use application provided value, same as now, so control should
>> be in
>> application.
>>
>> I am aware this breaks the comfort of just providing 0 and PMD values
>> will be
>> used but covers the case there is no PMD values.
>>
>> [1]
>> it can be possible to check if preferred value provided by comparing 0,
>> but if 0
>> is a valid value that can be problem. It may not be problem with
>> current
>> variables but it may be when this struct extended, it may be good to
>> think about
>> alternative here.
>
> I don't think we should use the condition of "yes => use it by sending 
> value 0". That is non-intuitive. Ideally, the application should query
 and then if query responds with value as '0' (which can be valid for some 
 variables in future), it sends its own value to setup functions
 (whether '0' or something else, in case of 0 response, would depend on the 
 knob).

 Right, at that stage application already knows what is the preferred value 
 and
 can directly use it.


 Will it be too much to:

 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer PMD
 values. "prefer_device_values" ?
 Application can provide values as usual, but if that field is set, 
 abstraction
 layer overwrites the application values with PMD preferred ones. If there 
 is no
 PMD preferred values continue using application ones.


 2) Add a bitwise "is_set" field to new "preferred_size" struct, which may 
 show
 status of other fields in the struct, if PMD set a valid value for them or 
 not,
 so won't have to rely on the 0 check.
>>>
>>> That all seems like too much hassle for such small thing.
>>
>> Fair enough.
>>
>>> If we really want to allow PMD not to provide preferred values -
>>> then instead of adding rte_eth_dev_pref_info into dev_info we can simply
>>> introduce a new optional ethdev API call:
>>> rte_eth_get_pref_params() or so.
>>> I

Re: [dpdk-dev] [PATCH v2 00/41] Memory Hotplug for DPDK

[Shreyansh Jain]

Hello Anatoly,

On Tue, Mar 13, 2018 at 10:47 AM, Shreyansh Jain  wrote:
> Hello Anatoly,
>
> On Fri, Mar 9, 2018 at 4:12 PM, Burakov, Anatoly
>  wrote:
>> On 09-Mar-18 9:15 AM, Pavan Nikhilesh wrote:
>
> [...]
>
>>>
>>>
>>> I have taken a look at the github tree the issues with VFIO are gone,
>>> Although
>>> compilation issues with dpaa/dpaa2 are still present due to their
>>> dependency on
>>> `rte_eal_get_physmem_layout`.
>>
>>
>> I've fixed the dpaa compile issue and pushed it to github. I've tried to
>> keep the semantics the same as before, but i can't compile-test (let alone
>> test-test) them as i don't have access to a system with dpaa bus.
>
> Thanks. I will have a look at this.

Just a heads-up, DPAA2 is broken on top-of-tree (github:
784e041f6b520) as of now:

--->8---
root@ls2088ardb:~/shreyansh/07_dpdk_memory#
./arm64-dpaa2-linuxapp-gcc/app/testpmd -c 0xE -n 1 --log-level=eal,8
--log-level=mem,8 -- -i --portmask=0x3
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 0 on socket 0
EAL: Detected lcore 3 as core 1 on socket 0
EAL: Detected lcore 4 as core 0 on socket 0
EAL: Detected lcore 5 as core 1 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Support maximum 16 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: VFIO PCI modules not loaded
EAL: DPAA Bus not present. Skipping.
EAL: Container: dprc.2 has VFIO iommu group id = 4
EAL: fslmc: Bus scan completed
EAL: Module /sys/module/rte_kni not found! error 2 (No such file or directory)
EAL: Multi-process socket /var/run/.rte_unix
EAL: Probing VFIO support...
EAL:   IOMMU type 1 (Type 1) is supported
EAL:   IOMMU type 7 (sPAPR) is not supported
EAL:   IOMMU type 8 (No-IOMMU) is not supported
EAL: VFIO support initialized
EAL: Mem event callback 'vfio_mem_event_clb' registered
EAL: Ask a virtual area of 0x2e000 bytes
EAL: Virtual area found at 0x86cae000 (size = 0x2e000)
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x8873f000 (size = 0x1000)
EAL: Memseg list allocated: 0x10kB at socket 0
EAL: Ask a virtual area of 0x8 bytes
EAL: Virtual area found at 0xfff78000 (size = 0x8)
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x8873e000 (size = 0x1000)
EAL: Memseg list allocated: 0x10kB at socket 0
EAL: Ask a virtual area of 0x8 bytes
EAL: Virtual area found at 0xffef4000 (size = 0x8)
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x8873d000 (size = 0x1000)
EAL: Memseg list allocated: 0x10kB at socket 0
EAL: Ask a virtual area of 0x8 bytes
EAL: Virtual area found at 0xffe7 (size = 0x8)
EAL: Ask a virtual area of 0x1000 bytes
EAL: Virtual area found at 0x8873c000 (size = 0x1000)
EAL: Memseg list allocated: 0x10kB at socket 0
EAL: Ask a virtual area of 0x8 bytes
EAL: Virtual area found at 0xffdec000 (size = 0x8)
EAL: TSC frequency is ~25000 KHz
EAL: Master lcore 1 is ready (tid=88742110;cpuset=[1])
EAL: lcore 3 is ready (tid=85cab910;cpuset=[3])
EAL: lcore 2 is ready (tid=864ab910;cpuset=[2])
EAL: eal_memalloc_alloc_page_bulk(): couldn't find suitable memseg_list
error allocating rte services array
EAL: FATAL: rte_service_init() failed

EAL: rte_service_init() failed

PANIC in main():
Cannot init EAL
1: [./arm64-dpaa2-linuxapp-gcc/app/testpmd(rte_dump_stack+0x38) [0x4f37a8]]
Aborted
--->8--

Above is an initial output - still investigating. I will keep you posted.

>
>>
>> Also, you might want to know that dpaa bus driver references
>> RTE_LIBRTE_DPAA_MAX_CRYPTODEV which is only found in
>> config/common_armv8a_linuxapp but is not present in base config. Not sure if
>> that's an issue.

A recent patch from Hemant has fixed this (yet to be merged in master).

[...]

-
Shreyansh

Re: [dpdk-dev] [PATCH v3 1/2] Add RIB library

[Bruce Richardson]

On Thu, Feb 22, 2018 at 10:50:55PM +, Medvedkin Vladimir wrote:
> RIB is an alternative to current LPM library.
> It solves the following problems
>  - Increases the speed of control plane operations against lpm such as
>adding/deleting routes
>  - Adds abstraction from dataplane algorithms, so it is possible to add
>different ip route lookup algorythms such as DXR/poptrie/lpc-trie/etc
>in addition to current dir24_8
>  - It is possible to keep user defined application specific additional
>information in struct rte_rib_node which represents route entry.
>It can be next hop/set of next hops (i.e. active and feasible),
>pointers to link rte_rib_node based on some criteria (i.e. next_hop),
>plenty of additional control plane information.
>  - For dir24_8 implementation it is possible to remove
>rte_lpm_tbl_entry.depth field that helps to save 6 bits.
>  - Also new dir24_8 implementation supports different next_hop sizes
>(1/2/4/8 bytes per next hop)
>  - Removed RTE_LPM_LOOKUP_SUCCESS to save 1 bit and to eleminate
>ternary operator.
>Instead it returns special default value if there is no route.
> 
> Signed-off-by: Medvedkin Vladimir 

More comments inline below. Mostly for rte_rib.c file.

/Bruce

> ---
>  config/common_base |   6 +
>  doc/api/doxy-api.conf  |   1 +
>  lib/Makefile   |   2 +
>  lib/librte_rib/Makefile|  23 ++

Don't forget meson.build file too, to build with meson and ninja. [Strongly
recommend it for your day-to-day development work too, incremental builds
are much, much faster using ninja].

>  lib/librte_rib/rte_dir24_8.c   | 482 +
>  lib/librte_rib/rte_dir24_8.h   | 115 
>  lib/librte_rib/rte_rib.c   | 526 
> +
>  lib/librte_rib/rte_rib.h   | 322 +++
>  lib/librte_rib/rte_rib_version.map |  18 ++
>  mk/rte.app.mk  |   1 +
>  10 files changed, 1496 insertions(+)
>  create mode 100644 lib/librte_rib/Makefile
>  create mode 100644 lib/librte_rib/rte_dir24_8.c
>  create mode 100644 lib/librte_rib/rte_dir24_8.h
>  create mode 100644 lib/librte_rib/rte_rib.c
>  create mode 100644 lib/librte_rib/rte_rib.h
>  create mode 100644 lib/librte_rib/rte_rib_version.map
> 
> diff --git a/config/common_base b/config/common_base
> index ad03cf4..aceeff5 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -679,6 +679,12 @@ CONFIG_RTE_LIBRTE_LPM=y
>  CONFIG_RTE_LIBRTE_LPM_DEBUG=n
>  
>  #
> +# Compile librte_rib
> +#
> +CONFIG_RTE_LIBRTE_RIB=y
> +CONFIG_RTE_LIBRTE_RIB_DEBUG=n
> +
> +#
>  # Compile librte_acl
>  #
>  CONFIG_RTE_LIBRTE_ACL=y
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index cda52fd..8e4f969 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -60,6 +60,7 @@ INPUT   = doc/api/doxy-api-index.md \
>lib/librte_kvargs \
>lib/librte_latencystats \
>lib/librte_lpm \
> +  lib/librte_rib \
>lib/librte_mbuf \
>lib/librte_member \
>lib/librte_mempool \
> diff --git a/lib/Makefile b/lib/Makefile
> index ec965a6..e4faf10 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -43,6 +43,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_EFD) += librte_efd
>  DEPDIRS-librte_efd := librte_eal librte_ring librte_hash
>  DIRS-$(CONFIG_RTE_LIBRTE_LPM) += librte_lpm
>  DEPDIRS-librte_lpm := librte_eal
> +DIRS-$(CONFIG_RTE_LIBRTE_RIB) += librte_rib
> +DEPDIRS-librte_rib := librte_eal librte_mempool
>  DIRS-$(CONFIG_RTE_LIBRTE_ACL) += librte_acl
>  DEPDIRS-librte_acl := librte_eal
>  DIRS-$(CONFIG_RTE_LIBRTE_MEMBER) += librte_member
> diff --git a/lib/librte_rib/Makefile b/lib/librte_rib/Makefile
> new file mode 100644
> index 000..f6431b6
> --- /dev/null
> +++ b/lib/librte_rib/Makefile
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2018 Vladimir Medvedkin 
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +# library name
> +LIB = librte_rib.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
> +LDLIBS += -lrte_eal -lrte_mempool
> +
> +EXPORT_MAP := rte_rib_version.map
> +
> +LIBABIVER := 1
> +
> +# all source are stored in SRCS-y
> +SRCS-$(CONFIG_RTE_LIBRTE_RIB) := rte_rib.c rte_dir24_8.c
> +
> +# install this header file
> +SYMLINK-$(CONFIG_RTE_LIBRTE_RIB)-include := rte_rib.h rte_dir24_8.h
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_rib/rte_dir24_8.c b/lib/librte_rib/rte_dir24_8.c
> new file mode 100644
> index 000..2fc55fe
> --- /dev/null
> +++ b/lib/librte_rib/rte_dir24_8.c

For future patches, it would be good if you can split the dir24_8 code into
a separate patch from the main rib code. The more you can split it into
separate patch blocks, the easier it is to

Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 9:23 PM
> To: Zhang, Qi Z ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> setup
> 
> 
> 
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 3:22 AM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > setup
> >
> >
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Wednesday, March 14, 2018 8:36 PM
> > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo ; Zhang,
> > > Qi Z 
> > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > queue setup
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > > Sent: Friday, March 2, 2018 4:13 AM
> > > > To: tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > Jingjing ; Lu, Wenzhuo
> > > > ; Zhang,
> > > Qi
> > > > Z 
> > > > Subject: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > > > setup
> > > >
> > > > Expose the deferred queue configuration capability and enhance
> > > > i40e_dev_[rx|tx]_queue_[setup|release] to handle the situation
> > > > when device already started.
> > > >
> > > > Signed-off-by: Qi Zhang 
> > > > ---
> > > >  drivers/net/i40e/i40e_ethdev.c |  6 
> > > >  drivers/net/i40e/i40e_rxtx.c   | 62
> > > --
> > > >  2 files changed, 66 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > > b/drivers/net/i40e/i40e_ethdev.c index 06b0f03a1..843a0c42a 100644
> > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > @@ -3195,6 +3195,12 @@ i40e_dev_info_get(struct rte_eth_dev
> *dev,
> > > struct rte_eth_dev_info *dev_info)
> > > > DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > > > DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > > > DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> > > > +   dev_info->deferred_queue_config_capa =
> > > > +   DEV_DEFERRED_RX_QUEUE_SETUP |
> > > > +   DEV_DEFERRED_TX_QUEUE_SETUP |
> > > > +   DEV_DEFERRED_RX_QUEUE_RELEASE |
> > > > +   DEV_DEFERRED_TX_QUEUE_RELEASE;
> > > > +
> > > > dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
> > > > sizeof(uint32_t);
> > > > dev_info->reta_size = pf->hash_lut_size; diff --git
> > > > a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > > > index
> > > > 1217e5a61..e5f532cf7 100644
> > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > @@ -1712,6 +1712,7 @@ i40e_dev_rx_queue_setup(struct
> rte_eth_dev
> > > *dev,
> > > > uint16_t len, i;
> > > > uint16_t reg_idx, base, bsf, tc_mapping;
> > > > int q_offset, use_def_burst_func = 1;
> > > > +   int ret = 0;
> > > >
> > > > if (hw->mac.type == I40E_MAC_VF || hw->mac.type ==
> > > I40E_MAC_X722_VF) {
> > > > vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > > > @@ -1841,6 +1842,25 @@ i40e_dev_rx_queue_setup(struct
> rte_eth_dev
> > > *dev,
> > > > rxq->dcb_tc = i;
> > > > }
> > > >
> > > > +   if (dev->data->dev_started) {
> > > > +   ret = i40e_rx_queue_init(rxq);
> > > > +   if (ret != I40E_SUCCESS) {
> > > > +   PMD_DRV_LOG(ERR,
> > > > +   "Failed to do RX queue 
> > > > initialization");
> > > > +   return ret;
> > > > +   }
> > > > +   if (ad->rx_vec_allowed)
> > >
> > > Better to check what rx function is installed right now.
> > Yes, it should be fixed, need to return fail if any conflict
> > >
> > > > +   i40e_rxq_vec_setup(rxq);
> > > > +   if (!rxq->rx_deferred_start) {
> > > > +   ret = i40e_dev_rx_queue_start(dev, queue_idx);
> > >
> > > I don't think it is a good idea to start/stop queue inside
> > > queue_setup/queue_release.
> > > There is special API (queue_start/queue_stop) to do this.
> >
> > The idea is if dev already started, the queue is supposed to be started
> automatically after queue_setup.
> 
> Why is that?
Because device is already started, its like a running conveyor belt, anything 
you put or replace on it just moves automatically.

> Might be user doesn't want to start queue, might be he only wants to start
> it.
Use deferred_start_flag,  
> Might be he would need to call queue_setup() once again later before
> starting it - based on some logic?

[dpdk-dev] [PATCH] net/nfp: support new HW offloads API

[Alejandro Lucero]

In next 18.05 the old hw offload API will be removed. This patch adds
support for just the new hw offload API.

Signed-off-by: Alejandro Lucero 
---
 drivers/net/nfp/nfp_net.c | 294 ++
 drivers/net/nfp/nfp_net_pmd.h |   6 +-
 2 files changed, 217 insertions(+), 83 deletions(-)

diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index e5bfde6..dee6063 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -427,8 +427,6 @@ enum nfp_qcp_ptr {
struct rte_eth_conf *dev_conf;
struct rte_eth_rxmode *rxmode;
struct rte_eth_txmode *txmode;
-   uint32_t new_ctrl = 0;
-   uint32_t update = 0;
struct nfp_net_hw *hw;
 
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
@@ -454,96 +452,154 @@ enum nfp_qcp_ptr {
}
 
/* Checking RX mode */
-   if (rxmode->mq_mode & ETH_MQ_RX_RSS) {
-   if (hw->cap & NFP_NET_CFG_CTRL_RSS) {
-   update = NFP_NET_CFG_UPDATE_RSS;
-   new_ctrl = NFP_NET_CFG_CTRL_RSS;
-   } else {
-   PMD_INIT_LOG(INFO, "RSS not supported");
-   return -EINVAL;
-   }
+   if (rxmode->mq_mode & ETH_MQ_RX_RSS &&
+   !(hw->cap & NFP_NET_CFG_CTRL_RSS)) {
+   PMD_INIT_LOG(INFO, "RSS not supported");
+   return -EINVAL;
}
 
-   if (rxmode->split_hdr_size) {
+   /* Checking RX offloads */
+   if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT) {
PMD_INIT_LOG(INFO, "rxmode does not support split header");
return -EINVAL;
}
 
-   if (rxmode->hw_ip_checksum) {
-   if (hw->cap & NFP_NET_CFG_CTRL_RXCSUM) {
-   new_ctrl |= NFP_NET_CFG_CTRL_RXCSUM;
-   } else {
-   PMD_INIT_LOG(INFO, "RXCSUM not supported");
-   return -EINVAL;
-   }
-   }
+   if ((rxmode->offloads & DEV_RX_OFFLOAD_IPV4_CKSUM) &&
+   !(hw->cap & NFP_NET_CFG_CTRL_RXCSUM))
+   PMD_INIT_LOG(INFO, "RXCSUM not supported");
 
-   if (rxmode->hw_vlan_filter) {
+   if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_FILTER) {
PMD_INIT_LOG(INFO, "VLAN filter not supported");
return -EINVAL;
}
 
-   if (rxmode->hw_vlan_strip) {
-   if (hw->cap & NFP_NET_CFG_CTRL_RXVLAN) {
-   new_ctrl |= NFP_NET_CFG_CTRL_RXVLAN;
-   } else {
-   PMD_INIT_LOG(INFO, "hw vlan strip not supported");
-   return -EINVAL;
-   }
+   if ((rxmode->offloads & DEV_RX_OFFLOAD_VLAN_STRIP) &&
+   !(hw->cap & NFP_NET_CFG_CTRL_RXVLAN)) {
+   PMD_INIT_LOG(INFO, "hw vlan strip not supported");
+   return -EINVAL;
}
 
-   if (rxmode->hw_vlan_extend) {
+   if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND) {
PMD_INIT_LOG(INFO, "VLAN extended not supported");
return -EINVAL;
}
 
-   if (rxmode->jumbo_frame)
-   hw->mtu = rxmode->max_rx_pkt_len;
+   if (rxmode->offloads & DEV_RX_OFFLOAD_TCP_LRO) {
+   PMD_INIT_LOG(INFO, "LRO not supported");
+   return -EINVAL;
+   }
+
+   if (rxmode->offloads & DEV_RX_OFFLOAD_QINQ_STRIP) {
+   PMD_INIT_LOG(INFO, "QINQ STRIP not supported");
+   return -EINVAL;
+   }
+
+   if (rxmode->offloads & DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM) {
+   PMD_INIT_LOG(INFO, "Outer IP checksum not supported");
+   return -EINVAL;
+   }
 
-   if (!rxmode->hw_strip_crc)
-   PMD_INIT_LOG(INFO, "HW does strip CRC and it is not 
configurable");
+   if (rxmode->offloads & DEV_RX_OFFLOAD_MACSEC_STRIP) {
+   PMD_INIT_LOG(INFO, "MACSEC strip not supported");
+   return -EINVAL;
+   }
+
+   if (rxmode->offloads & DEV_RX_OFFLOAD_MACSEC_STRIP) {
+   PMD_INIT_LOG(INFO, "MACSEC strip not supported");
+   return -EINVAL;
+   }
 
-   if (rxmode->enable_scatter) {
+   if (!(rxmode->offloads & DEV_RX_OFFLOAD_CRC_STRIP))
+   PMD_INIT_LOG(INFO, "HW does strip CRC. No configurable!");
+
+   if ((rxmode->offloads & DEV_RX_OFFLOAD_SCATTER) &&
+   !(hw->cap & NFP_NET_CFG_CTRL_SCATTER)) {
PMD_INIT_LOG(INFO, "Scatter not supported");
return -EINVAL;
}
 
-   /* If next capabilities are supported, configure them by default */
+   if (rxmode->offloads & DEV_RX_OFFLOAD_TIMESTAMP) {
+   PMD_INIT_LOG(INFO, "timestamp offfload not supported");
+   return -EINVAL;
+   }
 
-   /* VLAN insertion */
-   if (hw->cap & NFP_NET_CFG_CTRL_TXVLAN)
-   new_ctrl |= NFP_NET_CFG_CTRL_TXVLAN;
+   if (rxmode->offloads 

Re: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for deferred queue setup

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 9:42 PM
> To: Zhang, Qi Z ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for
> deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 3:58 AM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for
> > deferred queue setup
> >
> >
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Thursday, March 15, 2018 1:39 AM
> > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo ; Zhang,
> > > Qi Z 
> > > Subject: RE: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters
> > > for deferred queue setup
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > > Sent: Friday, March 2, 2018 4:13 AM
> > > > To: tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > Jingjing ; Lu, Wenzhuo
> > > > ; Zhang,
> > > Qi
> > > > Z 
> > > > Subject: [dpdk-dev] [PATCH v2 2/4] app/testpmd: add parameters for
> > > > deferred queue setup
> > > >
> > > > Add two parameters:
> > > > rxq-setup: set the number of RX queues be setup before device
> > > > started
> > > > txq-setup: set the number of TX queues be setup before device started.
> > >
> > > Not sure we do need these new parameters at all - in next patch you
> > > introduce ability to do queue_setup from command-line.
> > > Plus we already have an ability to do queue_stop/queue_start from
> > > command-line.
> > > I think that would be enough for testing.
> > > Konstantin
> >
> > Without these parameters, we can only reconfigure a queue after dev_start,
> but not the case that deferred configure a fresh queue.
> 
> We do have:
> port stop
> port config all (rxq|txq) (value)
> port start
> 
> If we'll add a new command to specify which queues should be deferred at
> dev_start - wouldn't that be enough?
> 
OK, that's what I want. thanks.
> 
> >
> > >
> > >
> > > >
> > > > Signed-off-by: Qi Zhang 
> > > > ---
> > > >  app/test-pmd/parameters.c | 29
> > > +
> > > >  app/test-pmd/testpmd.c|  8 ++--
> > > >  app/test-pmd/testpmd.h|  2 ++
> > > >  doc/guides/testpmd_app_ug/run_app.rst | 12 
> > > >  4 files changed, 49 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> > > > index 97d22b860..497259ee7 100644
> > > > --- a/app/test-pmd/parameters.c
> > > > +++ b/app/test-pmd/parameters.c
> > > > @@ -146,8 +146,12 @@ usage(char* progname)
> > > > printf("  --rss-ip: set RSS functions to IPv4/IPv6 only .\n");
> > > > printf("  --rss-udp: set RSS functions to IPv4/IPv6 + UDP.\n");
> > > > printf("  --rxq=N: set the number of RX queues per port to
> > > > N.\n");
> > > > +   printf("  --rxq-setup=N: set the number of RX queues be setup
> before"
> > > > +  "device start to N.\n");
> > > > printf("  --rxd=N: set the number of descriptors in RX rings to
> N.\n");
> > > > printf("  --txq=N: set the number of TX queues per port to
> > > > N.\n");
> > > > +   printf("  --txq-setup=N: set the number of TX queues be setup
> before"
> > > > +  "device start to N.\n");
> > > > printf("  --txd=N: set the number of descriptors in TX rings to
> N.\n");
> > > > printf("  --burst=N: set the number of packets per burst to 
> > > > N.\n");
> > > > printf("  --mbcache=N: set the cache of mbuf memory pool to
> > > > N.\n"); @@ -596,7 +600,9 @@ launch_args_parse(int argc, char**
> argv)
> > > > { "rss-ip", 0, 0, 0 },
> > > > { "rss-udp",0, 0, 0 },
> > > > { "rxq",1, 0, 0 },
> > > > +   { "rxq-setup",  1, 0, 0 },
> > > > { "txq",1, 0, 0 },
> > > > +   { "txq-setup",  1, 0, 0 },
> > > > { "rxd",1, 0, 0 },
> > > > { "txd",1, 0, 0 },
> > > > { "burst",  1, 0, 0 },
> > > > @@ -933,6 +939,15 @@ launch_args_parse(int argc, char** argv)
> > > >   " >= 0 && <= %u\n", n,
> > > >   
> > > > get_allowed_max_nb_rxq(&pid));
> > > > }
> > > > +   if (!strcmp(lgopts[opt_idx].name, "rxq-setup")) 
> > > > {
> > > > +   n = ato

Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API

[Ferruh Yigit]

On 3/15/2018 6:16 AM, Shahaf Shuler wrote:
> Thursday, March 15, 2018 12:41 AM, Ferruh Yigit:
>> On 3/14/2018 5:49 AM, Shahaf Shuler wrote:
>>> Tuesday, March 13, 2018 1:57 PM, Ferruh Yigit:
>
> Again - the application should follow the API which currently
> dictates how
 to set port offload. It is not depends on the rx_queue_offloads
>> capabilities.
> For example, PMD which don't support queue offloads can still have
 verification for the API that each port offload is set also on the
 queue offloads.

 I am not agree with this part, why to dictate application to set
 queue offloads if it already knows device doesn't support queue specific
>> offloads?
>>>
>>> I agree we can make a small change in the API to not force the application
>> to set the port offloads in the queue configuration. It makes sense.
>>> The change will be:
>>> "port offloads should be set on the port configuration. Queue offloads
>> should be set on the queue configuration"
>>
>> I am OK to this one, this is more reasonable for devices that support only 
>> port
>> level offloads.
>>
>> This looks like same as option #2 mentioned in the previous mails.
>>
>>>

 In some of the existing PMD patches, to switch to new offloading API,
 PMD sets [rt]x_queue_offload_capa as same as [rt]x_offload_capa,
>>>
>>> Well this is just wrong. Unless those PMDs support all the offloads in a
>> queue level.
>>>
>>> The logic is "every queue offload can be counted as port offload", because
>> such offload can be set on each and every queue.
>>> The other way around is not correct, port offload cannot be counted as
>> queue offload.
>>>
>>> So if such PMDs has offloads which are supported only on the port level
>> they cannot be declared as queue offloads.
>>
>> Thanks for confirming, it would be great if you can help on the PMD new
>> offload API patch reviews, to catch these kind of issues.
> 
> Sure, have me Cc in the patches so It can pass through my mailbox filters. 
> 
>>
>>>
>>>
 in that case
 application can't know if queue specific offloads are supported or
 not and application may try to set queue offloads, this forces PMD to
>> verify them.

 You confirmed [rt]x_queue_offload_capa is the way for application to
 know if device supports queue specific offloads or not. If these
 values always set to [rt]x_offload_capa, application losts this capability.

 Instead:
 - PMD that doesn't support queue specific offloads should set
 [rt]x_queue_offload_capa to 0
 - When [rt]x_queue_offload_capa is 0, application should be free to
 set queue offloads whatever it wants
>>>
>>> I don't agree, when queue_offload_capa is 0 the expected behavior from
>> application is not to set any offload (if we do the change in the API that 
>> you
>> are pushing to).
>>> PMDs can verify it or not, but if capability is not set the application 
>>> should
>> not set the offload. This is how the API should be defined.
>>
>> OK for this one.
>>
>>>
 - When [rt]x_queue_offload_capa is 0, PMD should be free to verify
 queue offloads but most probably shouldn't verify them since we don't
 know what application will send.

 - When [rt]x_queue_offload_capa is != 0, applications should set
 queue offloads at least "[rt]x_queue_offload = [rt]x_offload"
>>>
>>> If we do the change you are pushing it is not needed.
>>> Application will set the port offload in the port configuration, and the
>> queue offload in the queue configuration.
>>> No need to make special treatment based on the offloads_capa.
>>
>> Right.
>>
>>>
 - When [rt]x_queue_offload_capa is != 0, PMD should verify the queue
 offloads

>>
>>
>> Back to initial question J, is tap supports queue level offloads?
>> If not it shouldn't be reporting or checking queue offloads.
>>
>>
>> Although it will be changed after above suggested change in API, I think
>> check in existing tap queue_setup, also same in mlx5, is wrong.
>>
>> tap_rxq_are_offloads_valid(struct rte_eth_dev *dev, uint64_t offloads) {
>>
>> uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads;
>> uint64_t queue_supp_offloads = tap_rx_offload_get_queue_capa();
>> uint64_t port_supp_offloads = tap_rx_offload_get_port_capa();
>>
>>
>> <...>
>> if ((port_offloads ^ offloads) & port_supp_offloads)
>>return false;
>> return true;
>>
>> }
>>
>>
>> take the example:
>> port_supp_offloads = 1
>> port_offloads = 111
>> queue_supp_offloads = 
>> offloads = 
>>
>> (port_offloads ^ offloads) & port_supp_offloads = 1000 Which will return
>> false.
>>
>> This only works if "port_offloads == offloads" which is practically only
>> supporting port level offloads.
> 
> For mlx5, the port_supp_offloads is internal function which returns **only** 
> the pure port offloads (the port offloads in dev_info are 
> rx_offload_get_queue_capa() | rx_offload_get_port_capa())
>

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Bruce Richardson]

On Thu, Mar 15, 2018 at 01:57:13PM +, Ferruh Yigit wrote:
> On 3/14/2018 9:36 PM, Bruce Richardson wrote:
> > On Wed, Mar 14, 2018 at 09:02:47PM +, Ferruh Yigit wrote:
> >> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
> >>>
> >>>
>  -Original Message-
>  From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
>  Sent: Wednesday, March 14, 2018 5:52 PM
>  To: Shreyansh Jain ; Horton, Remy 
>  ; dev@dpdk.org
>  Cc: Lu, Wenzhuo ; Wu, Jingjing 
>  ; Zhang, Qi Z ; Xing, Beilei
>  ; Thomas Monjalon 
>  Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
>  PMD-tuned Tx/Rx parameters
> 
>  On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
> >> -Original Message-
> >> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> >> Sent: Wednesday, March 14, 2018 10:13 PM
> >> To: Remy Horton ; dev@dpdk.org
> >> Cc: Wenzhuo Lu ; Jingjing Wu
> >> ; Qi Zhang ; Beilei Xing
> >> ; Shreyansh Jain ;
> >> Thomas Monjalon 
> >> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
> >> tuned Tx/Rx parameters
> >>
> >> On 3/14/2018 3:48 PM, Remy Horton wrote:
> >>>
> >>> On 14/03/2018 14:43, Ferruh Yigit wrote:
> >>> [..]
> >  lib/librte_ether/rte_ethdev.c | 18 ++
> >  lib/librte_ether/rte_ethdev.h | 15 +++
> 
>  Can you please remove deprecation notice in this patch.
> >>>
> >>> Done.
> >>>
> > +   /* Defaults for drivers that don't implement preferred
> > +* queue parameters.
> >>> [..]
>  Not sure about having these defaults here. It is OK to have defaults
> >> in driver,
>  in application or in config file, but I am not sure if putting them
> >> into device
>  abstraction layer hides them.
> 
>  What about not providing any default in ethdev layer, and get zero
> >> as invalid
>  when using them?
> >>>
> >>> This is something I have been thinking about, and I am going to
> >> remove
> >>> them for the V2. Original motive was to avoid breaking testpmd for
> >> PMDs
> >>> that don't give defaults (i.e. almost all of them). The alternative
> >> is
> >>> to put place-holders into all the PMDs themselves, but I am not sure
> >> if
> >>> this is appropriate.
> >>
> >> I think preferred values should be optional, PMD should have right to
> >> not
> >> provide any. Implementation in 4/4 forces preferred values, either in
> >> all PMDs
> >> or in ethdev layer.
> >>
> >> What about changing approach in application:
> >>  is preferred value provided [1] ?
> >>   yes => use it by sending value 0
> >>   no => use application provided value, same as now, so control should
> >> be in
> >> application.
> >>
> >> I am aware this breaks the comfort of just providing 0 and PMD values
> >> will be
> >> used but covers the case there is no PMD values.
> >>
> >> [1]
> >> it can be possible to check if preferred value provided by comparing 0,
> >> but if 0
> >> is a valid value that can be problem. It may not be problem with
> >> current
> >> variables but it may be when this struct extended, it may be good to
> >> think about
> >> alternative here.
> >
> > I don't think we should use the condition of "yes => use it by sending 
> > value 0". That is non-intuitive. Ideally, the application should query
>  and then if query responds with value as '0' (which can be valid for 
>  some variables in future), it sends its own value to setup functions
>  (whether '0' or something else, in case of 0 response, would depend on 
>  the knob).
> 
>  Right, at that stage application already knows what is the preferred 
>  value and
>  can directly use it.
> 
> 
>  Will it be too much to:
> 
>  1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer 
>  PMD
>  values. "prefer_device_values" ?
>  Application can provide values as usual, but if that field is set, 
>  abstraction
>  layer overwrites the application values with PMD preferred ones. If 
>  there is no
>  PMD preferred values continue using application ones.
> 
> 
>  2) Add a bitwise "is_set" field to new "preferred_size" struct, which 
>  may show
>  status of other fields in the struct, if PMD set a valid value for them 
>  or not,
>  so won't have to rely on the 0 check.
> >>>
> >>> That all seems like too much hassle for such small thing.
> >>
> >> Fair enough.
> >>
> >>> If we really want to allow PMD not to provide preferred values -
> >>> then instead of adding rte_eth_dev_pref_info into dev_info we can simply
> >>> introduce a new optional ethdev API call:
> >>> rte_eth_get_pref_params() or so.
> >>>

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Bruce Richardson]

On Thu, Mar 15, 2018 at 01:57:31PM +, Ferruh Yigit wrote:
> On 3/15/2018 12:51 PM, Ananyev, Konstantin wrote:
> > 
> > 
> >> -Original Message-
> >> From: Yigit, Ferruh
> >> Sent: Wednesday, March 14, 2018 9:03 PM
> >> To: Ananyev, Konstantin ; Shreyansh Jain 
> >> ; Horton, Remy
> >> ; dev@dpdk.org
> >> Cc: Lu, Wenzhuo ; Wu, Jingjing 
> >> ; Zhang, Qi Z ; Xing, Beilei
> >> ; Thomas Monjalon 
> >> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
> >> PMD-tuned Tx/Rx parameters
> >>
> >> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
> >>>
> >>>
>  -Original Message-
>  From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
>  Sent: Wednesday, March 14, 2018 5:52 PM
>  To: Shreyansh Jain ; Horton, Remy 
>  ; dev@dpdk.org
>  Cc: Lu, Wenzhuo ; Wu, Jingjing 
>  ; Zhang, Qi Z ; Xing, Beilei
>  ; Thomas Monjalon 
>  Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
>  PMD-tuned Tx/Rx parameters
> 
>  On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
> >> -Original Message-
> >> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> >> Sent: Wednesday, March 14, 2018 10:13 PM
> >> To: Remy Horton ; dev@dpdk.org
> >> Cc: Wenzhuo Lu ; Jingjing Wu
> >> ; Qi Zhang ; Beilei Xing
> >> ; Shreyansh Jain ;
> >> Thomas Monjalon 
> >> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
> >> tuned Tx/Rx parameters
> >>
> >> On 3/14/2018 3:48 PM, Remy Horton wrote:
> >>>
> >>> On 14/03/2018 14:43, Ferruh Yigit wrote:
> >>> [..]
> >  lib/librte_ether/rte_ethdev.c | 18 ++
> >  lib/librte_ether/rte_ethdev.h | 15 +++
> 
>  Can you please remove deprecation notice in this patch.
> >>>
> >>> Done.
> >>>
> > +   /* Defaults for drivers that don't implement preferred
> > +* queue parameters.
> >>> [..]
>  Not sure about having these defaults here. It is OK to have defaults
> >> in driver,
>  in application or in config file, but I am not sure if putting them
> >> into device
>  abstraction layer hides them.
> 
>  What about not providing any default in ethdev layer, and get zero
> >> as invalid
>  when using them?
> >>>
> >>> This is something I have been thinking about, and I am going to
> >> remove
> >>> them for the V2. Original motive was to avoid breaking testpmd for
> >> PMDs
> >>> that don't give defaults (i.e. almost all of them). The alternative
> >> is
> >>> to put place-holders into all the PMDs themselves, but I am not sure
> >> if
> >>> this is appropriate.
> >>
> >> I think preferred values should be optional, PMD should have right to
> >> not
> >> provide any. Implementation in 4/4 forces preferred values, either in
> >> all PMDs
> >> or in ethdev layer.
> >>
> >> What about changing approach in application:
> >>  is preferred value provided [1] ?
> >>   yes => use it by sending value 0
> >>   no => use application provided value, same as now, so control should
> >> be in
> >> application.
> >>
> >> I am aware this breaks the comfort of just providing 0 and PMD values
> >> will be
> >> used but covers the case there is no PMD values.
> >>
> >> [1]
> >> it can be possible to check if preferred value provided by comparing 0,
> >> but if 0
> >> is a valid value that can be problem. It may not be problem with
> >> current
> >> variables but it may be when this struct extended, it may be good to
> >> think about
> >> alternative here.
> >
> > I don't think we should use the condition of "yes => use it by sending 
> > value 0". That is non-intuitive. Ideally, the application should query
>  and then if query responds with value as '0' (which can be valid for 
>  some variables in future), it sends its own value to setup functions
>  (whether '0' or something else, in case of 0 response, would depend on 
>  the knob).
> 
>  Right, at that stage application already knows what is the preferred 
>  value and
>  can directly use it.
> 
> 
>  Will it be too much to:
> 
>  1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer 
>  PMD
>  values. "prefer_device_values" ?
>  Application can provide values as usual, but if that field is set, 
>  abstraction
>  layer overwrites the application values with PMD preferred ones. If 
>  there is no
>  PMD preferred values continue using application ones.
> 
> 
>  2) Add a bitwise "is_set" field to new "preferred_size" struct, which 
>  may show
>  status of other fields in the struct, if PMD set a valid value for them 
>  or not,
>  so won't have to rely on the 0 check

Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters

[Ferruh Yigit]

On 3/15/2018 2:39 PM, Bruce Richardson wrote:
> On Thu, Mar 15, 2018 at 01:57:13PM +, Ferruh Yigit wrote:
>> On 3/14/2018 9:36 PM, Bruce Richardson wrote:
>>> On Wed, Mar 14, 2018 at 09:02:47PM +, Ferruh Yigit wrote:
 On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Wednesday, March 14, 2018 5:52 PM
>> To: Shreyansh Jain ; Horton, Remy 
>> ; dev@dpdk.org
>> Cc: Lu, Wenzhuo ; Wu, Jingjing 
>> ; Zhang, Qi Z ; Xing, Beilei
>> ; Thomas Monjalon 
>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for 
>> PMD-tuned Tx/Rx parameters
>>
>> On 3/14/2018 5:23 PM, Shreyansh Jain wrote:
 -Original Message-
 From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
 Sent: Wednesday, March 14, 2018 10:13 PM
 To: Remy Horton ; dev@dpdk.org
 Cc: Wenzhuo Lu ; Jingjing Wu
 ; Qi Zhang ; Beilei Xing
 ; Shreyansh Jain ;
 Thomas Monjalon 
 Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-
 tuned Tx/Rx parameters

 On 3/14/2018 3:48 PM, Remy Horton wrote:
>
> On 14/03/2018 14:43, Ferruh Yigit wrote:
> [..]
>>>  lib/librte_ether/rte_ethdev.c | 18 ++
>>>  lib/librte_ether/rte_ethdev.h | 15 +++
>>
>> Can you please remove deprecation notice in this patch.
>
> Done.
>
>>> +   /* Defaults for drivers that don't implement preferred
>>> +* queue parameters.
> [..]
>> Not sure about having these defaults here. It is OK to have defaults
 in driver,
>> in application or in config file, but I am not sure if putting them
 into device
>> abstraction layer hides them.
>>
>> What about not providing any default in ethdev layer, and get zero
 as invalid
>> when using them?
>
> This is something I have been thinking about, and I am going to
 remove
> them for the V2. Original motive was to avoid breaking testpmd for
 PMDs
> that don't give defaults (i.e. almost all of them). The alternative
 is
> to put place-holders into all the PMDs themselves, but I am not sure
 if
> this is appropriate.

 I think preferred values should be optional, PMD should have right to
 not
 provide any. Implementation in 4/4 forces preferred values, either in
 all PMDs
 or in ethdev layer.

 What about changing approach in application:
  is preferred value provided [1] ?
   yes => use it by sending value 0
   no => use application provided value, same as now, so control should
 be in
 application.

 I am aware this breaks the comfort of just providing 0 and PMD values
 will be
 used but covers the case there is no PMD values.

 [1]
 it can be possible to check if preferred value provided by comparing 0,
 but if 0
 is a valid value that can be problem. It may not be problem with
 current
 variables but it may be when this struct extended, it may be good to
 think about
 alternative here.
>>>
>>> I don't think we should use the condition of "yes => use it by sending 
>>> value 0". That is non-intuitive. Ideally, the application should query
>> and then if query responds with value as '0' (which can be valid for 
>> some variables in future), it sends its own value to setup functions
>> (whether '0' or something else, in case of 0 response, would depend on 
>> the knob).
>>
>> Right, at that stage application already knows what is the preferred 
>> value and
>> can directly use it.
>>
>>
>> Will it be too much to:
>>
>> 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer 
>> PMD
>> values. "prefer_device_values" ?
>> Application can provide values as usual, but if that field is set, 
>> abstraction
>> layer overwrites the application values with PMD preferred ones. If 
>> there is no
>> PMD preferred values continue using application ones.
>>
>>
>> 2) Add a bitwise "is_set" field to new "preferred_size" struct, which 
>> may show
>> status of other fields in the struct, if PMD set a valid value for them 
>> or not,
>> so won't have to rely on the 0 check.
>
> That all seems like too much hassle for such small thing.

 Fair enough.

> If we really want to allow PMD not to provide preferred values -
> then instead of adding rte_eth_dev_pref_info into dev_info we can simply
> introduce a new optional ethdev API c

Re: [dpdk-dev] [PATCH v3 0/8] net/mrvl: add new features to PMD

[Ferruh Yigit]

On 3/15/2018 7:51 AM, Tomasz Duszynski wrote:
> This patch series comes along with a set of features,
> documentation updates and fixes.
> 
> Below one can find a short summary of introduced changes:
> 
> o Added support for selective Tx queue start and stop.
> o Added support for Rx flow control.
> o Added support for extended statistics counters.
> o Added support for ingress policer, egress scheduler and egress rate
>   limiter.
> o Added support for configuring hardware classifier via a flow API.
> o Documented new features and their usage.
> 
> Natalie Samsonov (1):
>   net/mrvl: fix crash when port is closed without starting
> 
> Tomasz Duszynski (7):
>   net/mrvl: add ingress policer support
>   net/mrvl: add egress scheduler/rate limiter support
>   net/mrvl: document policer/scheduler/rate limiter usage
>   net/mrvl: add classifier support
>   net/mrvl: add extended statistics
>   net/mrvl: add Rx flow control
>   net/mrvl: add Tx queue start/stop

Series applied to dpdk-next-net/master, thanks.

Re: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 9:17 PM
> To: Zhang, Qi Z ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> 
> Hi Qi,
> 
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 3:14 AM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > setup
> >
> > Hi Konstantin:
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Wednesday, March 14, 2018 8:32 PM
> > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo ; Zhang,
> > > Qi Z 
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > > setup
> > >
> > > Hi Qi,
> > >
> > > >
> > > > The patch let etherdev driver expose the capability flag through
> > > > rte_eth_dev_info_get when it support deferred queue configuraiton,
> > > > then base on the flag rte_eth_[rx|tx]_queue_setup could decide
> > > > continue to setup the queue or just return fail when device
> > > > already started.
> > > >
> > > > Signed-off-by: Qi Zhang 
> > > > ---
> > > >  doc/guides/nics/features.rst  |  8 
> > > > lib/librte_ether/rte_ethdev.c | 30 ++
> > > > lib/librte_ether/rte_ethdev.h | 11 +++
> > > >  3 files changed, 37 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/doc/guides/nics/features.rst
> > > > b/doc/guides/nics/features.rst index 1b4fb979f..36ad21a1f 100644
> > > > --- a/doc/guides/nics/features.rst
> > > > +++ b/doc/guides/nics/features.rst
> > > > @@ -892,7 +892,15 @@ Documentation describes performance
> values.
> > > >
> > > >  See ``dpdk.org/doc/perf/*``.
> > > >
> > > > +.. _nic_features_queue_deferred_setup_capabilities:
> > > >
> > > > +Queue deferred setup capabilities
> > > > +-
> > > > +
> > > > +Supports queue setup / release after device started.
> > > > +
> > > > +* **[provides] rte_eth_dev_info**:
> > > >
> > >
> ``deferred_queue_config_capa:DEV_DEFERRED_RX_QUEUE_SETUP,DEV_DEFE
> > > RRED_
> > > > TX_QUEUE_SETUP,DEV_DEFERRED_RX_QUEUE_RELE
> > > > ASE,DEV_DEFERRED_TX_QUEUE_RELEASE``.
> > > > +* **[related]  API**: ``rte_eth_dev_info_get()``.
> > > >
> > > >  .. _nic_features_other:
> > > >
> > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > b/lib/librte_ether/rte_ethdev.c index a6ce2a5ba..6c906c4df 100644
> > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > @@ -1425,12 +1425,6 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> > > uint16_t rx_queue_id,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > -   if (dev->data->dev_started) {
> > > > -   RTE_PMD_DEBUG_TRACE(
> > > > -   "port %d must be stopped to allow configuration\n",
> port_id);
> > > > -   return -EBUSY;
> > > > -   }
> > > > -
> > > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get,
> > > -ENOTSUP);
> > > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_setup,
> > > -ENOTSUP);
> > > >
> > > > @@ -1474,10 +1468,19 @@ rte_eth_rx_queue_setup(uint16_t
> port_id,
> > > uint16_t rx_queue_id,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > +   if (dev->data->dev_started &&
> > > > +   !(dev_info.deferred_queue_config_capa &
> > > > +   DEV_DEFERRED_RX_QUEUE_SETUP))
> > > > +   return -EINVAL;
> > > > +
> > >
> > > I think now you have to check here that the queue is stopped.
> > > Otherwise you might attempt to reconfigure running queue.
> >
> > I'm not sure if it's necessary to let application use different API sequence
> for a deferred configure and deferred re-configure.
> > Can we just call dev_ops->rx_queue_stop before rx_queue_release here
> 
> I don't follow you here.
> Let say now inside queue_start() we do check:
> 
> if (dev->data->rx_queue_state[rx_queue_id] !=
> RTE_ETH_QUEUE_STATE_STOPPED)
> 
> Right now it is not possible to call queue_setup() without dev_stop() before
> it - that's why we have check if (dev->data->dev_started) in queue_setup()
> right now.
> Though with your patch it not the case anymore - user is able to call
> queue_setup() without stopping the whole device.
> But he still has to stop the queue.

> 
> >
> > >
> > >
> > > > rxq = dev->data->rx_queues;
> > > > if (rxq[rx_queue_id]) {
> > > >
>   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_release,
> > > > -ENOTSUP);
> > >
> > > I don't think it is *that* straightforward.
> > > rx_queue_setup() parameters can imply different rx function (and
> > > related dev
> > > icesettings) that are already setuped by 

Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup

[Ananyev, Konstantin]

> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 15, 2018 2:30 PM
> To: Ananyev, Konstantin ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing 
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Thursday, March 15, 2018 9:23 PM
> > To: Zhang, Qi Z ; tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > setup
> >
> >
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Thursday, March 15, 2018 3:22 AM
> > > To: Ananyev, Konstantin ;
> > > tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo 
> > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > > setup
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ananyev, Konstantin
> > > > Sent: Wednesday, March 14, 2018 8:36 PM
> > > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > > ; Lu, Wenzhuo ; Zhang,
> > > > Qi Z 
> > > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > > queue setup
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > > > Sent: Friday, March 2, 2018 4:13 AM
> > > > > To: tho...@monjalon.net
> > > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > > Jingjing ; Lu, Wenzhuo
> > > > > ; Zhang,
> > > > Qi
> > > > > Z 
> > > > > Subject: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > > > > setup
> > > > >
> > > > > Expose the deferred queue configuration capability and enhance
> > > > > i40e_dev_[rx|tx]_queue_[setup|release] to handle the situation
> > > > > when device already started.
> > > > >
> > > > > Signed-off-by: Qi Zhang 
> > > > > ---
> > > > >  drivers/net/i40e/i40e_ethdev.c |  6 
> > > > >  drivers/net/i40e/i40e_rxtx.c   | 62
> > > > --
> > > > >  2 files changed, 66 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > > > b/drivers/net/i40e/i40e_ethdev.c index 06b0f03a1..843a0c42a 100644
> > > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > > @@ -3195,6 +3195,12 @@ i40e_dev_info_get(struct rte_eth_dev
> > *dev,
> > > > struct rte_eth_dev_info *dev_info)
> > > > >   DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > > > >   DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > > > >   DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> > > > > + dev_info->deferred_queue_config_capa =
> > > > > + DEV_DEFERRED_RX_QUEUE_SETUP |
> > > > > + DEV_DEFERRED_TX_QUEUE_SETUP |
> > > > > + DEV_DEFERRED_RX_QUEUE_RELEASE |
> > > > > + DEV_DEFERRED_TX_QUEUE_RELEASE;
> > > > > +
> > > > >   dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
> > > > >   sizeof(uint32_t);
> > > > >   dev_info->reta_size = pf->hash_lut_size; diff --git
> > > > > a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > > > > index
> > > > > 1217e5a61..e5f532cf7 100644
> > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > @@ -1712,6 +1712,7 @@ i40e_dev_rx_queue_setup(struct
> > rte_eth_dev
> > > > *dev,
> > > > >   uint16_t len, i;
> > > > >   uint16_t reg_idx, base, bsf, tc_mapping;
> > > > >   int q_offset, use_def_burst_func = 1;
> > > > > + int ret = 0;
> > > > >
> > > > >   if (hw->mac.type == I40E_MAC_VF || hw->mac.type ==
> > > > I40E_MAC_X722_VF) {
> > > > >   vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > > > > @@ -1841,6 +1842,25 @@ i40e_dev_rx_queue_setup(struct
> > rte_eth_dev
> > > > *dev,
> > > > >   rxq->dcb_tc = i;
> > > > >   }
> > > > >
> > > > > + if (dev->data->dev_started) {
> > > > > + ret = i40e_rx_queue_init(rxq);
> > > > > + if (ret != I40E_SUCCESS) {
> > > > > + PMD_DRV_LOG(ERR,
> > > > > + "Failed to do RX queue 
> > > > > initialization");
> > > > > + return ret;
> > > > > + }
> > > > > + if (ad->rx_vec_allowed)
> > > >
> > > > Better to check what rx function is installed right now.
> > > Yes, it should be fixed, need to return fail if any conflict
> > > >
> > > > > + i40e_rxq_vec_setup(rxq);
> > > > > + if (!rxq->rx_deferred_start) {
> > > > > + ret = i40e_dev_rx_queue_start(dev, queue_idx);
> > > >
> > > > I don't think it is a good idea to start/stop queue inside
> > > > queue_setup/queue_release.
> > > > There is special API (queue_start/queue_stop) to do this.
> > >
> > > Th

Re: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup

[Ananyev, Konstantin]

> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, March 15, 2018 3:09 PM
> To: Ananyev, Konstantin ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing 
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Thursday, March 15, 2018 9:17 PM
> > To: Zhang, Qi Z ; tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> >
> > Hi Qi,
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Thursday, March 15, 2018 3:14 AM
> > > To: Ananyev, Konstantin ;
> > > tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo 
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > > setup
> > >
> > > Hi Konstantin:
> > >
> > > > -Original Message-
> > > > From: Ananyev, Konstantin
> > > > Sent: Wednesday, March 14, 2018 8:32 PM
> > > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > > ; Lu, Wenzhuo ; Zhang,
> > > > Qi Z 
> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > > > setup
> > > >
> > > > Hi Qi,
> > > >
> > > > >
> > > > > The patch let etherdev driver expose the capability flag through
> > > > > rte_eth_dev_info_get when it support deferred queue configuraiton,
> > > > > then base on the flag rte_eth_[rx|tx]_queue_setup could decide
> > > > > continue to setup the queue or just return fail when device
> > > > > already started.
> > > > >
> > > > > Signed-off-by: Qi Zhang 
> > > > > ---
> > > > >  doc/guides/nics/features.rst  |  8 
> > > > > lib/librte_ether/rte_ethdev.c | 30 ++
> > > > > lib/librte_ether/rte_ethdev.h | 11 +++
> > > > >  3 files changed, 37 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/doc/guides/nics/features.rst
> > > > > b/doc/guides/nics/features.rst index 1b4fb979f..36ad21a1f 100644
> > > > > --- a/doc/guides/nics/features.rst
> > > > > +++ b/doc/guides/nics/features.rst
> > > > > @@ -892,7 +892,15 @@ Documentation describes performance
> > values.
> > > > >
> > > > >  See ``dpdk.org/doc/perf/*``.
> > > > >
> > > > > +.. _nic_features_queue_deferred_setup_capabilities:
> > > > >
> > > > > +Queue deferred setup capabilities
> > > > > +-
> > > > > +
> > > > > +Supports queue setup / release after device started.
> > > > > +
> > > > > +* **[provides] rte_eth_dev_info**:
> > > > >
> > > >
> > ``deferred_queue_config_capa:DEV_DEFERRED_RX_QUEUE_SETUP,DEV_DEFE
> > > > RRED_
> > > > > TX_QUEUE_SETUP,DEV_DEFERRED_RX_QUEUE_RELE
> > > > > ASE,DEV_DEFERRED_TX_QUEUE_RELEASE``.
> > > > > +* **[related]  API**: ``rte_eth_dev_info_get()``.
> > > > >
> > > > >  .. _nic_features_other:
> > > > >
> > > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > > b/lib/librte_ether/rte_ethdev.c index a6ce2a5ba..6c906c4df 100644
> > > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > > @@ -1425,12 +1425,6 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> > > > uint16_t rx_queue_id,
> > > > >   return -EINVAL;
> > > > >   }
> > > > >
> > > > > - if (dev->data->dev_started) {
> > > > > - RTE_PMD_DEBUG_TRACE(
> > > > > - "port %d must be stopped to allow configuration\n",
> > port_id);
> > > > > - return -EBUSY;
> > > > > - }
> > > > > -
> > > > >   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get,
> > > > -ENOTSUP);
> > > > >   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_setup,
> > > > -ENOTSUP);
> > > > >
> > > > > @@ -1474,10 +1468,19 @@ rte_eth_rx_queue_setup(uint16_t
> > port_id,
> > > > uint16_t rx_queue_id,
> > > > >   return -EINVAL;
> > > > >   }
> > > > >
> > > > > + if (dev->data->dev_started &&
> > > > > + !(dev_info.deferred_queue_config_capa &
> > > > > + DEV_DEFERRED_RX_QUEUE_SETUP))
> > > > > + return -EINVAL;
> > > > > +
> > > >
> > > > I think now you have to check here that the queue is stopped.
> > > > Otherwise you might attempt to reconfigure running queue.
> > >
> > > I'm not sure if it's necessary to let application use different API 
> > > sequence
> > for a deferred configure and deferred re-configure.
> > > Can we just call dev_ops->rx_queue_stop before rx_queue_release here
> >
> > I don't follow you here.
> > Let say now inside queue_start() we do check:
> >
> > if (dev->data->rx_queue_state[rx_queue_id] !=
> > RTE_ETH_QUEUE_STATE_STOPPED)
> >
> > Right now it is not possible to call queue_setup() without dev_stop() before
> > it - that's why we have check if (dev->data->dev_started) in queue_setup()
> > right now.
> > Though with your patch it not the case anymore - user is able to call
> > q

Re: [dpdk-dev] [PATCH 3/6] net/sfc: add support for per-port dynamic logging

[Ferruh Yigit]

On 1/25/2018 5:00 PM, Andrew Rybchenko wrote:
> From: Ivan Malov 
> 
> Signed-off-by: Ivan Malov 
> Signed-off-by: Andrew Rybchenko 
> Reviewed-by: Andy Moreton 

<...>

> +uint32_t
> +sfc_register_logtype(struct sfc_adapter *sa, const char *lt_prefix_str,
> +  uint32_t ll_default)
> +{
> + size_t lt_prefix_str_size = strlen(lt_prefix_str);
> + size_t lt_str_size_max;
> + char *lt_str = NULL;
> + int ret;
> +
> + if (SIZE_MAX - PCI_PRI_STR_SIZE - 1 > lt_prefix_str_size) {
> + ++lt_prefix_str_size; /* Reserve space for prefix separator */
> + lt_str_size_max = lt_prefix_str_size + PCI_PRI_STR_SIZE + 1;
> + } else {
> + return RTE_LOGTYPE_PMD;
> + }
> +
> + lt_str = rte_zmalloc("logtype_str", lt_str_size_max, 0);
> + if (lt_str == NULL)
> + return RTE_LOGTYPE_PMD;
> +
> + strncpy(lt_str, lt_prefix_str, lt_prefix_str_size);
> + lt_str[lt_prefix_str_size - 1] = '.';
> + rte_pci_device_name(&sa->pci_addr, lt_str + lt_prefix_str_size,
> + lt_str_size_max - lt_prefix_str_size);


Not able to find "rte_pci_device_name()" in shared library build [1].
Need to link with rte_pci library [2].

[1]
sfc.o: In function `sfc_register_logtype':
.../dpdk/drivers/net/sfc/sfc.c:(.text+0x1a52): undefined reference to
`rte_pci_device_name'
clang-4.0: error: linker command failed with exit code 1 (use -v to see 
invocation)

[2]
  --- a/drivers/net/sfc/Makefile
  +++ b/drivers/net/sfc/Makefile
  @@ -52,3 +52,3 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
   LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs
  -LDLIBS += -lrte_bus_pci
  +LDLIBS += -lrte_bus_pci -lrte_pci

<...>

Re: [dpdk-dev] [PATCH 1/4] vhost: move fdset functions from fd_man.c to fd_man.h

[Thomas Monjalon]

13/03/2018 10:50, Yang, Zhiyong:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > 13/03/2018 09:46, Yang, Zhiyong:
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > 05/03/2018 08:43, Yang, Zhiyong:
> > > > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > > > I don't see why it should be exported outside of DPDK, except for
> > PMDs.
> > > > > > I would tend to keep it internal but I understand that it would
> > > > > > mean duplicating some code, which is not ideal.
> > > > > > Please could you show what would be the content of the .h in EAL?
> > > > > >
> > > > >
> > > > > If needed to expose them in eal.h, I think that they should be the
> > > > > whole fdset mechanism as followings.
> > > > >
> > > > > typedef void (*fd_cb)(int fd, void *dat, int *remove);
> > > > >
> > > > > struct fdentry {
> > > > >   int fd; /* -1 indicates this entry is empty */
> > > > >   fd_cb rcb;  /* callback when this fd is readable. */
> > > > >   fd_cb wcb;  /* callback when this fd is writeable.*/
> > > > >   void *dat;  /* fd context */
> > > > >   int busy;   /* whether this entry is being used in cb. */
> > > > > };
> > > > >
> > > > > struct fdset {
> > > > >   struct pollfd rwfds[MAX_FDS];
> > > > >   struct fdentry fd[MAX_FDS];
> > > > >   pthread_mutex_t fd_mutex;
> > > > >   int num;/* current fd number of this fdset */
> > > > > };
> > > > >
> > > > > void fdset_init(struct fdset *pfdset);(not used in the patchset)
> > > > >
> > > > > int fdset_add(struct fdset *pfdset, int fd,
> > > > >   fd_cb rcb, fd_cb wcb, void *dat); (used in this patchset)
> > > > >
> > > > > void *fdset_del(struct fdset *pfdset, int fd); (not used in the
> > > > > patchset)
> > > > >
> > > > > void *fdset_event_dispatch(void *arg);   (used in this patchset)
> > > > >
> > > > > seems that we have 4 options.
> > > > > 1) expose them in librte_vhost
> > > > > 2) expose them in other existing or new libs. for example,  eal.
> > > > > 3) duplicate the code lines at PMD layer.
> > > > > 4) do it as the patch does that.
> > > >
> > > > It looks to be very close of the interrupt thread.
> > > > Can we have all merged in an unique event dispatcher thread?
> > >
> > > If I understand right, do you mean that we can merge them in lib eal ?  
> > > right?
> > 
> > Yes merge with interrupt thread in EAL.
> > I didn't look at the details, but it seems the right place for such thing.
> > 
> Ok,  we have to expose them as new APIs.  Expect that somebody as DPDK users 
> can use and like them as well. :)

I think you missed my initial question:
Is it possible to merge the vhost events needs in the EAL interrupt thread?

Re: [dpdk-dev] [PATCH 0/2] lib: move Netlink wrapper to lib

[Thomas Monjalon]

14/03/2018 16:17, Stephen Hemminger:
> On Wed, 14 Mar 2018 13:08:55 +0100
> Nélio Laranjeiro  wrote:
> > On Tue, Mar 13, 2018 at 02:20:31PM -0700, Stephen Hemminger wrote:
> > > On Tue, 13 Mar 2018 13:28:25 +0100
> > > Nelio Laranjeiro  wrote:
> > > >  drivers/net/tap/Makefile   |   3 +-
> > > >  drivers/net/tap/rte_eth_tap.c  |  16 +--
> > > >  drivers/net/tap/tap_flow.c | 118 
> > > > ++---
> > > >  drivers/net/tap/tap_netlink.h  |  42 
> > > >  drivers/net/tap/tap_tcmsgs.c   |  28 ++---
> > > >  drivers/net/tap/tap_tcmsgs.h   |   2 +-
> > > >  lib/Makefile   |   2 +
> > > >  lib/librte_netlink/Makefile|  26 +
> > > >  lib/librte_netlink/meson.build |  13 +++
> > > >  .../librte_netlink/rte_netlink.c   |  87 
> > > > +++
> > > >  lib/librte_netlink/rte_netlink.h   |  43 
> > > >  lib/librte_netlink/rte_netlink_version.map |  18 
> > > 
> > > I might have raised this before; but having yet another netlink library is
> > > not a great advantage. It would be much better to use a common external 
> > > library
> > > libmnl which is already available on every distribution.  
> > 
> > The question is more do we really want to have a dependency on a so
> > small wrapper for a socket interface?
> 
> Lots of drivers already have dependencies.
> And I trust libmnl rather than a reinvented library.

Are we sure it is commonly installed in distributions?

This is needed only for TAP and mlx drivers.
Do we really want to add this dependency as mandatory for everybody
to compile DPDK with default PMDs?

I see 4 options:
1/ keep duplicated few functions in PMDs
2/ use libmnl
3/ add the functions in a DPDK lib (this patch)
4/ add the functions in EAL

I would vote for the first option because mlx5 has very minimal
requirement regarding netlink.
The first option can give us some time to think about the right way
to use netlink in the next releases.

Re: [dpdk-dev] Request to create a repo under DPDK for Network Function Framework for Go

[Melik-Adamyan, Areg]

Hello.

Within Intel, we developed and open-sourced a DPDK based high-level library and 
runtime named Network Function Framework for Go (NFF-Go: 
https://github.com/intel-go/nff-go) which is intended to simplify packet 
processing applications, especially for cloud-native deployment. Based on DPDK 
NFF-Go provides higher-level packet processing functions in native Go alongside 
with simple, powerful runtime.
NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as that 
would result in poor performance due to the 300-1500 cycles that can be spent 
by a context switch. Instead, NFF-Go uses pointers from the DPDK initialization 
of the device mbuf structures. It permits copying of packet data between Go's 
safe and DPDK/C unsafe memory. NFF-Go works everywhere where DPDK works.
*Capabilities:* Library provides functions to create packet processing graph 
from user-defined or predefined functions. The graph can be arbitrary but will 
need to have a single entry point. The user can freely use both synchronous and 
asynchronous programming capabilities provided by Go language. Also, 
auto-scaling is automatically provided by the built-in scheduler using cores as 
needed, and freeing them after use. NFF-Go provides an alternative development 
environment for creating network functions using a smaller number of lines of 
code compared to DPDK/C without sacrificing performance. These capabilities 
make it possible to implement run-till-completion packet processing model.  The 
library includes a component called boundary node, which allows consuming 
packet data from all types of sources: Ethernet, file, memory buffer, remote 
procedure call and then applying the packets to the processing graph which will 
be transparently deployed through any cloud orchestration engine.
*Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for bringing 
packet processing to less experienced developers and push towards cloud-native 
usages. We strongly believe that NFF-Go is complementary to DPDK. Having a 
closer link between them should help both projects - it will ease pickup from 
one source/repo the needed set of features to be used, rather than us just 
providing a disjointed collection of software projects which are hosted in 
different places.

We expect the initial commit to include the following:

-  Low, Asm - low-level C and ASM code for gluing DPDK

-  Packet - a library that provides an abstraction for packet and tools 
to manipulate

-  Flow  - library to provide an abstraction for packet flows

-  Scheduler - runtime and a scheduler for auto-scaling and integration 
with RSS

-  Examples:

o   Forwarding - simple L3 forwarding

o   Firewall - an example of simple ACL based firewall

o   Tutorial - step based tutorial how to use NFF-Go

o   NAT - an example of production grade Network Address Translation

o   AntiDDOS - simple example of AntiDDOS on L3

-  Automation scripts - helping to build, deploy and test applications 
on a single host

Thanks,
Areg Melik-Adamyan
Engineering Manager
Developer Products Divison
Intel Corporation

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Stephen Hemminger]

On Thu, 15 Mar 2018 16:15:21 +
"Melik-Adamyan, Areg"  wrote:

> Hello.
> 
> Within Intel, we developed and open-sourced a DPDK based high-level library 
> and runtime named Network Function Framework for Go (NFF-Go: 
> https://github.com/intel-go/nff-go) which is intended to simplify packet 
> processing applications, especially for cloud-native deployment. Based on 
> DPDK NFF-Go provides higher-level packet processing functions in native Go 
> alongside with simple, powerful runtime.
> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as that 
> would result in poor performance due to the 300-1500 cycles that can be spent 
> by a context switch. Instead, NFF-Go uses pointers from the DPDK 
> initialization of the device mbuf structures. It permits copying of packet 
> data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere 
> where DPDK works.
> *Capabilities:* Library provides functions to create packet processing graph 
> from user-defined or predefined functions. The graph can be arbitrary but 
> will need to have a single entry point. The user can freely use both 
> synchronous and asynchronous programming capabilities provided by Go 
> language. Also, auto-scaling is automatically provided by the built-in 
> scheduler using cores as needed, and freeing them after use. NFF-Go provides 
> an alternative development environment for creating network functions using a 
> smaller number of lines of code compared to DPDK/C without sacrificing 
> performance. These capabilities make it possible to implement 
> run-till-completion packet processing model.  The library includes a 
> component called boundary node, which allows consuming packet data from all 
> types of sources: Ethernet, file, memory buffer, remote procedure call and 
> then applying the packets to the processing graph which will be transparently 
> deployed through any cloud orchestration engine.
> *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for 
> bringing packet processing to less experienced developers and push towards 
> cloud-native usages. We strongly believe that NFF-Go is complementary to 
> DPDK. Having a closer link between them should help both projects - it will 
> ease pickup from one source/repo the needed set of features to be used, 
> rather than us just providing a disjointed collection of software projects 
> which are hosted in different places.
> 
> We expect the initial commit to include the following:
> 
> -  Low, Asm - low-level C and ASM code for gluing DPDK
> 
> -  Packet - a library that provides an abstraction for packet and 
> tools to manipulate
> 
> -  Flow  - library to provide an abstraction for packet flows
> 
> -  Scheduler - runtime and a scheduler for auto-scaling and 
> integration with RSS
> 
> -  Examples:
> 
> o   Forwarding - simple L3 forwarding
> 
> o   Firewall - an example of simple ACL based firewall
> 
> o   Tutorial - step based tutorial how to use NFF-Go
> 
> o   NAT - an example of production grade Network Address Translation
> 
> o   AntiDDOS - simple example of AntiDDOS on L3
> 
> -  Automation scripts - helping to build, deploy and test 
> applications on a single host
> 
> Thanks,
> Areg Melik-Adamyan
> Engineering Manager
> Developer Products Divison
> Intel Corporation

I am ok with it being on DPDK, but might it make more sense on github or under 
FD.io?
Or is there some legal and/or political reason not to?

Re: [dpdk-dev] [PATCH 0/2] lib: move Netlink wrapper to lib

[Nélio Laranjeiro]

On Thu, Mar 15, 2018 at 04:39:46PM +0100, Thomas Monjalon wrote:
> 14/03/2018 16:17, Stephen Hemminger:
> > On Wed, 14 Mar 2018 13:08:55 +0100
> > Nélio Laranjeiro  wrote:
> > > On Tue, Mar 13, 2018 at 02:20:31PM -0700, Stephen Hemminger wrote:
> > > > On Tue, 13 Mar 2018 13:28:25 +0100
> > > > Nelio Laranjeiro  wrote:
> > > > >  drivers/net/tap/Makefile   |   3 +-
> > > > >  drivers/net/tap/rte_eth_tap.c  |  16 +--
> > > > >  drivers/net/tap/tap_flow.c | 118 
> > > > > ++---
> > > > >  drivers/net/tap/tap_netlink.h  |  42 
> > > > >  drivers/net/tap/tap_tcmsgs.c   |  28 ++---
> > > > >  drivers/net/tap/tap_tcmsgs.h   |   2 +-
> > > > >  lib/Makefile   |   2 +
> > > > >  lib/librte_netlink/Makefile|  26 +
> > > > >  lib/librte_netlink/meson.build |  13 +++
> > > > >  .../librte_netlink/rte_netlink.c   |  87 
> > > > > +++
> > > > >  lib/librte_netlink/rte_netlink.h   |  43 
> > > > >  lib/librte_netlink/rte_netlink_version.map |  18 
> > > > 
> > > > I might have raised this before; but having yet another netlink library 
> > > > is
> > > > not a great advantage. It would be much better to use a common external 
> > > > library
> > > > libmnl which is already available on every distribution.  
> > > 
> > > The question is more do we really want to have a dependency on a so
> > > small wrapper for a socket interface?
> > 
> > Lots of drivers already have dependencies.
> > And I trust libmnl rather than a reinvented library.
> 
> Are we sure it is commonly installed in distributions?
> 
> This is needed only for TAP and mlx drivers.
> Do we really want to add this dependency as mandatory for everybody
> to compile DPDK with default PMDs?
> 
> I see 4 options:
> 1/ keep duplicated few functions in PMDs
> 2/ use libmnl
> 3/ add the functions in a DPDK lib (this patch)
> 4/ add the functions in EAL
> 
> I would vote for the first option because mlx5 has very minimal
> requirement regarding netlink.
> The first option can give us some time to think about the right way
> to use netlink in the next releases.

I also vote for option 1 until those 4 and maybe more options are
discussed.

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-dev] [PATCH 0/2] lib: move Netlink wrapper to lib

[Stephen Hemminger]

On Thu, 15 Mar 2018 17:19:05 +0100
Nélio Laranjeiro  wrote:

> On Thu, Mar 15, 2018 at 04:39:46PM +0100, Thomas Monjalon wrote:
> > 14/03/2018 16:17, Stephen Hemminger:  
> > > On Wed, 14 Mar 2018 13:08:55 +0100
> > > Nélio Laranjeiro  wrote:  
> > > > On Tue, Mar 13, 2018 at 02:20:31PM -0700, Stephen Hemminger wrote:  
> > > > > On Tue, 13 Mar 2018 13:28:25 +0100
> > > > > Nelio Laranjeiro  wrote:  
> > > > > >  drivers/net/tap/Makefile   |   3 +-
> > > > > >  drivers/net/tap/rte_eth_tap.c  |  16 +--
> > > > > >  drivers/net/tap/tap_flow.c | 118 
> > > > > > ++---
> > > > > >  drivers/net/tap/tap_netlink.h  |  42 
> > > > > >  drivers/net/tap/tap_tcmsgs.c   |  28 ++---
> > > > > >  drivers/net/tap/tap_tcmsgs.h   |   2 +-
> > > > > >  lib/Makefile   |   2 +
> > > > > >  lib/librte_netlink/Makefile|  26 +
> > > > > >  lib/librte_netlink/meson.build |  13 +++
> > > > > >  .../librte_netlink/rte_netlink.c   |  87 
> > > > > > +++
> > > > > >  lib/librte_netlink/rte_netlink.h   |  43 
> > > > > >  lib/librte_netlink/rte_netlink_version.map |  18   
> > > > > 
> > > > > I might have raised this before; but having yet another netlink 
> > > > > library is
> > > > > not a great advantage. It would be much better to use a common 
> > > > > external library
> > > > > libmnl which is already available on every distribution.
> > > > 
> > > > The question is more do we really want to have a dependency on a so
> > > > small wrapper for a socket interface?  
> > > 
> > > Lots of drivers already have dependencies.
> > > And I trust libmnl rather than a reinvented library.  
> > 
> > Are we sure it is commonly installed in distributions?
> > 

iproute2 now mostly requires libmnl. It is used for several networking types
and extended error reporting.

Re: [dpdk-dev] [PATCH 1/3] eal/vfio: add support for multiple container

[Wang, Xiao W]

Hi Anatoly,

> -Original Message-
> From: Burakov, Anatoly
> Sent: Wednesday, March 14, 2018 8:08 PM
> To: Wang, Xiao W ; dev@dpdk.org
> Cc: Wang, Zhihong ;
> maxime.coque...@redhat.com; y...@fridaylinux.org; Liang, Cunming
> ; Xu, Rosen ; Chen, Junjie J
> ; Daly, Dan 
> Subject: Re: [dpdk-dev] [PATCH 1/3] eal/vfio: add support for multiple
> container
> 
> On 09-Mar-18 11:08 PM, Xiao Wang wrote:
> > From: Junjie Chen 
> >
> > Currently eal vfio framework binds vfio group fd to the default
> > container fd, while in some cases, e.g. vDPA (vhost data path
> > acceleration), we want to set vfio group to a new container and
> > program DMA mapping via this new container, so this patch adds
> > APIs to support multiple container.
> >
> > Signed-off-by: Junjie Chen 
> > Signed-off-by: Xiao Wang 
> > ---
> 
> I'm not going to get into virtual vs. real device debate, but i do have
> some issues with VFIO side of things.
> 
> I'm not completely convinced this change is needed in the first place.
> If the device driver manages its own groups anyway, it knows which VFIO
> groups belong to it, so it can add/remove them without putting them into
> separate containers. What is the purpose of keeping them in a separate
> container as opposed to just keeping track of group id's?

The device driver needs to have a separate container to program IOMMU
For the device, with the VM's addr translation table. So driver needs the
Devices be put into new containers, rather than the default one.

> 
> <...>
> 
> 
> > +   vfio_cfg->vfio_container_fd = vfio_get_container_fd();
> > +
> > +   if (vfio_cfg->vfio_container_fd < 0)
> > +   return -1;
> > +
> > +   return vfio_cfg->vfio_container_fd;
> > +}
> 
> Please correct me if i'm wrong, but this patch appears to be mistitled.
> You're not really creating multiple containers, you're just partitioning
> existing one. Do we really need to open/store/close container fd's
> separately, if all we have is a single container anyway?

This driver are creating new containers for devices, it needs each device
to have its own container, then we can dma_map/ummap for the device
via it's associated container.

BRs,
Xiao

> 
> The semantics of this are also weird in multiprocess. When secondary
> process requests a container, we always create a new one, send it over
> IPC and close it afterwards. It seems to be oblivious that you may have
> several container fd's, and does not know which one you are asking for.
> We know it's all the same container, but that's clearly not what the
> code appears to be doing.
> 
> --
> Thanks,
> Anatoly

Re: [dpdk-dev] [PATCH 0/3] add ifcvf driver

[Wang, Xiao W]

Hi Maxime,

> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> Sent: Sunday, March 11, 2018 2:24 AM
> To: Wang, Xiao W ; dev@dpdk.org
> Cc: Wang, Zhihong ; y...@fridaylinux.org; Liang,
> Cunming ; Xu, Rosen ; Chen,
> Junjie J ; Daly, Dan 
> Subject: Re: [PATCH 0/3] add ifcvf driver
> 
> Hi Xiao,
> 
> On 03/10/2018 12:08 AM, Xiao Wang wrote:
> > This patch set has dependency on
> http://dpdk.org/dev/patchwork/patch/35635/
> > (vhost: support selective datapath);
> >
> > ifc VF is compatible with virtio vring operations, this driver implements
> > vDPA driver ops which configures ifc VF to be a vhost data path accelerator.
> >
> > ifcvf driver uses vdev as a control domain to manage ifc VFs that belong
> > to it. It registers vDPA device ops to vhost lib to enable these VFs to be
> > used as vhost data path accelerator.
> >
> > Live migration feature is supported by ifc VF and this driver enables
> > it based on vhost lib.
> >
> > vDPA needs to create different containers for different devices, thus this
> > patch set adds APIs in eal/vfio to support multiple container.
> Thanks for this! That will avoind having to duplicate these functions
> for every new offload driver.
> 
> 
> >
> > Junjie Chen (1):
> >eal/vfio: add support for multiple container
> >
> > Xiao Wang (2):
> >bus/pci: expose sysfs parsing API
> 
> Still, I'm not convinced the offload device should be a virtual device.
> It is a real PCI device, why not having a new device type for offload
> devices, and let the device to be probed automatically by the existing
> device model?

IFC VFs are generated from SRIOV, with the PF driven by kernel driver.
In DPDK we need to have something to represent PF, to register itself as
a vDPA engine, so a virtual device is used for this purpose.

The VFs are used for vhost net offload, and we could implement exception traffic
Rx/Tx function on the VFs in future via port-representor mechanism. So this 
patch
keeps the device type as net.

BRs,
Xiao

> 
> Thanks,
> Maxime
> 
> 
> >net/ifcvf: add ifcvf driver
> >
> >   config/common_base   |6 +
> >   config/common_linuxapp   |1 +
> >   drivers/bus/pci/linux/pci.c  |9 +-
> >   drivers/bus/pci/linux/pci_init.h |8 +
> >   drivers/bus/pci/rte_bus_pci_version.map  |8 +
> >   drivers/net/Makefile |1 +
> >   drivers/net/ifcvf/Makefile   |   40 +
> >   drivers/net/ifcvf/base/ifcvf.c   |  329 
> >   drivers/net/ifcvf/base/ifcvf.h   |  156 
> >   drivers/net/ifcvf/base/ifcvf_osdep.h |   52 ++
> >   drivers/net/ifcvf/ifcvf_ethdev.c | 1241
> ++
> >   drivers/net/ifcvf/rte_ifcvf_version.map  |4 +
> >   lib/librte_eal/bsdapp/eal/eal.c  |   51 +-
> >   lib/librte_eal/common/include/rte_vfio.h |  117 ++-
> >   lib/librte_eal/linuxapp/eal/eal_vfio.c   |  553 ++---
> >   lib/librte_eal/linuxapp/eal/eal_vfio.h   |2 +
> >   lib/librte_eal/rte_eal_version.map   |7 +
> >   mk/rte.app.mk|1 +
> >   18 files changed, 2480 insertions(+), 106 deletions(-)
> >   create mode 100644 drivers/net/ifcvf/Makefile
> >   create mode 100644 drivers/net/ifcvf/base/ifcvf.c
> >   create mode 100644 drivers/net/ifcvf/base/ifcvf.h
> >   create mode 100644 drivers/net/ifcvf/base/ifcvf_osdep.h
> >   create mode 100644 drivers/net/ifcvf/ifcvf_ethdev.c
> >   create mode 100644 drivers/net/ifcvf/rte_ifcvf_version.map
> >

[dpdk-dev] [PATCH] Adding SUSE logo

[mvarlese]

From: Marco Varlese 

SUSE is among the companies packaging and distributing DPDK in
its open and enterprise distributions.

Signed-off-by: Marco Varlese 
---
 about/ecosystem.html |   1 +
 logos/suse.png   | Bin 0 -> 10824 bytes
 2 files changed, 1 insertion(+)
 create mode 100644 logos/suse.png

diff --git a/about/ecosystem.html b/about/ecosystem.html
index a95d3fc..9154cb2 100644
--- a/about/ecosystem.html
+++ b/about/ecosystem.html
@@ -53,6 +53,7 @@



+   

 
Open Source Projects Leveraging DPDK
diff --git a/logos/suse.png b/logos/suse.png
new file mode 100644
index 
..8e41d9888a51b4178ce7d5d6d784a0a687c81ff6
GIT binary patch
literal 10824
zcmbVyRZtub>?ZEo#ogT(UEJN>-JylzZpGc5;!vF8Qgm^5x23qd6uIC3;bv~`-tHmE
zOkVPkFUgllqSaJn(NTy{prD}8<>jO_{yV&BreHclM?x-SU}`T=gp$@>G4}8>eqUbl
zKKG@nYl|YO^A4dO#fB>mKKe~ECdFZdLY3t5V-vV#ywmH;H8^RNFlj}HHk)o*UVWu5N
z_+PWz-$tQ}AI?eYH#S9m$YWU1Lz=3(au*f9Y7)WCJ$ZWMYSln`2W9XE7QQOiOHrXj
zoC9<{okb);iKJX&&?B?06aBt_1^6#1E8w6u(rJk)yzt$;?M#^oLAnd#Tta
z@CU((==SXzg|<0zqoZWcpPA)DKw=Z^1~bn3E;3jXsjz_KN7L55@8%LuY#z};F-=Qe$ba1s}_
zuMpC19wk&jFRateoa^{T6eXq`iu_|0u%lv&WuU^v>bTST9`m06^H&P0Tkjz_XrVGD
z_6^)iLsu*Jd-is`$4!AaeMSxkh(h8Oaol{x&Z>Y(mZxOYh59?-DyxNiIVvC6r!Z~D
zA=O!Dj*mFqcYb3UWg9!G6j(9+I^5deNtku30)5x|aXsTGlZ*P%0p
z%r4V;hs&-kfPFgWgf=&jvC)ySAlk6oJ!JMH!Wb4Z&$s#-Kn@)AbV8rVtIjSx36n7h
zI2Goy)D_@54BX*p!v?UTfb%H933HguXJn&GK_hZ2Tn4zJ_SYPFkuHJtDV$!sS6ksoW7|EI^-02sjb*qm`83tDLf=NfC0&N%lLp;#^6d={
z;YGYuax)5ULrW5^mfnDyT-`hh%*yxl+Hl;&L$pFBb@10t=h|v$h-RI6eOUXeM_Y2^
zBl&uUl6;G@vt#2{sCQsV@Gm1`iUPA@Q?Mp~I&*5C$Ua{Vjvbd|7K&Ts8tM3FgRlk5
z{eU-+;K1XZg|0FG(rHy*;%!nvS)kJHk!lu)iACy5`1ucfp_Kw@QtytXktm7J>N9=I=%(
z78ucu#6#~f^Yg!RIj?E_Adpg(Yc%4Ia!m@Vh$QEZ4z*!F_(`l(=Z$hcW)%**8fyiI
z??lrWCJ!rn9m6JHsCymqfwENgH1h$Ji{M5B{!qzIYdU=q&Bkftl6raq;k^weW!?Cv
zc%A{}BC%CcgI47ND1j&8qcMBU7!mke2^@zJgFGFFfR1^mT;GJ@C4BL&CSgOiwC72@
zlh^gYCa);(9b&ITR?TS*Tn`b1pMeE0MjvpB8f`fr^_}<|b>91ggzy6vNOzd25tS&l
z;_C9rxLzoS7UvkOmX{NC8T*Sb-;Ws&io!5GhnDIoKkRMFF|SmwdIn`q&Mh~7qs2EH
zHZ*($6!s&sUrnf7d>KB!00DF@(DBhxxN|6fd^d?74!6j5oDm{A`1!_9uo2I?ys>!S
zp=cC8#L}-cq{&9F><2~q!J_N`t~mq*FY_=X0uF@jE?&CL`THY%mC<-}C<{RiIPBlu
z0TY7OO<}WV@)oKe)PIf;3-VWQCBM?CR0T!CP7!lBx+5!4REAojdg{ccl~#W4gmJW>d($8-$1WM5oW}h#G}oYo=~Om)3b
zVyPL*ffn>8Sr%W#1pgh<#TeCZ3pS>yB
zj9OfNwV@XxSMOJ9K4{)03`sv!gt1W%qeW+@2eIVwLj`UD(e<^zr?-vPjs1}0K&z-bDuHJ$o{vdIM=nv|5F^Z4!az%fwE5`OwDHI<|88Ex
z4cwEllEOh6$Kv?)n*e`{9X*;bQeN*|*gAQ#UZ-N_jmOHD1`AQc+8VKb5PHXX)n0)2
zl!xw)u>b+lTahKY+|coLdfhE1mFjc~a}*12uLZ+z@lg6**5gD9g_dilThBHG_2yc{2#Ke}+qZEQr#?T0U`O=ogIiLWePAwBZ
z_MvMsahoOwKeR}4mcalaK1)B^=mJjHCS26xMg$=EG2k_yGUD3)5MA1np$vZ6Vra5~
zEB=Ax?3RjZG7H2z_jvig_}e#eo^bfIc=+-
zTc~6&Az`PCwCd
z^>ord2+<%Q6(!zpE&mh*ac>iz;v2h673G$?l5{rm=0*EqZH9^$=h)Yvv;|i2$oMr9
zHg3_#Z~Uti_IxF_GHT{5XefifygVy#aaBiRe}p}cX?}>q
zJRSLCVdrB~Z#8Lhkz4oi2CFnSa~&Q|j<;UYjr8JKcUE^B3N$;^*(kF
zjSM~m;T_x{(IrihSfO!w-*6=1zsaTx;#g8$II{?*DEd3I(|0n4mUsOpz{?I_HO;{z@|EW%eXY2Q5T
zSesnQ7t3M#6Hb!Hmu7hAz3pOo#reY}JO+U8VU`dGw@mPLsO!I0@jNCO0)^HOQ>8_d
ztNc}%SR5hC2*)7X1mpYa=Zl~;ZWq0TpeE#&KW+fM)wpq$lyXtJJBgB_l{A~>eTh#*
zjo`qK^%=Gd6^DIVyHCptA+!tPs*`$nOFWYr2J=A}swt*k*t))F`8B!ajy4>uBrc6X
z>*gsUvpeE{7tNsrl3404(nOg2AUcavC6*upGvsS-ytRotWns4;z2S`;5((u-WP@Gk
z0q}2J|Its(MLEQU-e(`Q$$W&i1ZlJ7*|eJi^PrD@ox9YiZw=*rmpTc(_f#qwN
z4)f`GL_-ywroIdV-NpWPo<}b)-W<819H8}9!S_@$wjaV5a7DN&Vm=SFh?FI{?ieH^
z^Lr(h#){POmg2ep9)kiz0zWqE=Qct=nhZ*uTJk?U&$iy@1iQex4EzraUF4ZC7Qe)0
zn#9`4AG$Tj4fkE{-5XN}A}a0m!ebwc#FbiJcUN@RL0A*Dz_g#J)@3SZd)d<)?Bcc5
zQI+(ASPyJS@1@Wv(i0w3PLu#w{AU`(6tPt#di7?`od4t%p`9m%PI961`;0>
zJq~<=hf1PD>=m|IuBP7V^_kYxM?CpTL32emThO8fD$cAOvejjx&(J68`5hhph7@LSH=bvCkhIzbkon=QU@%hJ#ld<>`=L!c
zAPv$7N0*UED&@9c2ypN@F&U;WN#n%C}2cp
z-8eVy9le^)?!Etj7+9m{R@t9h2XW{cNmQpjTAzv3x`e+AYtBsBE2eu`7GgtDV|TNA
z4s`8Wx5=z0U2T&0h`DARFf*g*{@WtC$*j2Br`yiWJg%r9^L8aG5JX06To=Z
zEexc@j4_6XH`40*5;ZdbQ8-=&$+Aw)U0>EcN2nIW-9?D*8mb0W4j&->veO_0RnO}F
z4l*;Ghi8YUizGVyJ|fm8&%3~C5_{>pn?$)VN&84%LCUi6096bJ@D{`&@fgwmMrWxs
zjNMIpdhks3mqB*35*5Ndgx#QtDzlsZ*n2bHDJWh+vs*Rt!$$;ZT28#+Y`}~kWNqzL
zvzLHaMbgq1^XRiYv_Os~OT&T1G>R7>8AnMdVTFCTY#wgeOeI39xL8d|B+8k$-epNV
zXU^I6Hn$zLjptS1tGZFcxutMUOAb4PWtxTkSS~hRhz20mUNP+<&sUP
z*?WAt!GJAbA1b$MAglf)(WgeeCW8;N`eK+^3(!OqukoRm`;8=iZeoOybCN4S>*yU6
zsdFd1OpE}0{xU+p3A#(UDcz;g&f}Ck?Zf7?FJ%)Xo1~DVaXoP(*MLX=kN(2pQHqEU
z_ma&I(#RDfhFN??OKOx<%BUZ(wfp&~yv=ks&#SZ_i?vg^;n?${TIO;lUV_k{)&Hhe
ztmC#&I@Onqzsp?R)K@wp51mrm21pnT8{+_8ugmE5e9vh!l;~u#ZQ~JZQPtO5=+eVg$b{yQtn1E^Z$*#8uz$`8$
z9Q5U68k*jp!p+tBAo$9N4g6s%u5h>s^JA#@(jY_Wvd|?X6tlyyFtgNC&c12nE9Y)Ne99}c9H*hni9@4?|UcovwvaCNc-3LZj2}2R5F0o1HbZ9
zynTl9@tF<@_YiInzMr&pp|u}n*Rowx9Z7Lt;d*gT(y-;~V}I|uiN`U4S5oFt?KG`F
zo}n2EC1xf$+H+5`ckZG>=_^G_^B76?FPDQjwTA(ODGevsKQ!6)s+wok3JUycukT;p
zecfhZbFk85kR^XG02$gXhiUU2@NhM93`71?j#EnmqC@rP_L6H-G|bTGBA
z_Tdw|q#x=+J6e7b4t~bgCf$W%!?VBc9T+OOC3`Z?*Wu?6rX{IC*6oopo~%Mz&Ky1h
zKfmIlq>0BX(N~oQL_z-zvQYeDm>SOCz?95T_IGqRF)@#&IZ8(ml0bP%{76LY^(!{aa^`itE#AtGhiZ
z=#{>3kf(?#5*lu&ryS^!uM5x21Cn6O9#kN-EyUi#5Vk98{8BlembKB$$jGXPb=uCL
zl}t|~#6~Egl63UTW89M9MRTC6svr{Zc=%%WU

[dpdk-dev] [PATCH v2] Adding SUSE logo

[mvarlese]

From: Marco Varlese 

SUSE is among the companies packaging and distributing DPDK in
its open and enterprise distributions.

Signed-off-by: Marco Varlese 
---
 about/ecosystem.html |   1 +
 logos/suse.png   | Bin 0 -> 10824 bytes
 2 files changed, 1 insertion(+)
 create mode 100644 logos/suse.png

diff --git a/about/ecosystem.html b/about/ecosystem.html
index a95d3fc..ddacc53 100644
--- a/about/ecosystem.html
+++ b/about/ecosystem.html
@@ -53,6 +53,7 @@



+   

 
Open Source Projects Leveraging DPDK
diff --git a/logos/suse.png b/logos/suse.png
new file mode 100644
index 
..8e41d9888a51b4178ce7d5d6d784a0a687c81ff6
GIT binary patch
literal 10824
zcmbVyRZtub>?ZEo#ogT(UEJN>-JylzZpGc5;!vF8Qgm^5x23qd6uIC3;bv~`-tHmE
zOkVPkFUgllqSaJn(NTy{prD}8<>jO_{yV&BreHclM?x-SU}`T=gp$@>G4}8>eqUbl
zKKG@nYl|YO^A4dO#fB>mKKe~ECdFZdLY3t5V-vV#ywmH;H8^RNFlj}HHk)o*UVWu5N
z_+PWz-$tQ}AI?eYH#S9m$YWU1Lz=3(au*f9Y7)WCJ$ZWMYSln`2W9XE7QQOiOHrXj
zoC9<{okb);iKJX&&?B?06aBt_1^6#1E8w6u(rJk)yzt$;?M#^oLAnd#Tta
z@CU((==SXzg|<0zqoZWcpPA)DKw=Z^1~bn3E;3jXsjz_KN7L55@8%LuY#z};F-=Qe$ba1s}_
zuMpC19wk&jFRateoa^{T6eXq`iu_|0u%lv&WuU^v>bTST9`m06^H&P0Tkjz_XrVGD
z_6^)iLsu*Jd-is`$4!AaeMSxkh(h8Oaol{x&Z>Y(mZxOYh59?-DyxNiIVvC6r!Z~D
zA=O!Dj*mFqcYb3UWg9!G6j(9+I^5deNtku30)5x|aXsTGlZ*P%0p
z%r4V;hs&-kfPFgWgf=&jvC)ySAlk6oJ!JMH!Wb4Z&$s#-Kn@)AbV8rVtIjSx36n7h
zI2Goy)D_@54BX*p!v?UTfb%H933HguXJn&GK_hZ2Tn4zJ_SYPFkuHJtDV$!sS6ksoW7|EI^-02sjb*qm`83tDLf=NfC0&N%lLp;#^6d={
z;YGYuax)5ULrW5^mfnDyT-`hh%*yxl+Hl;&L$pFBb@10t=h|v$h-RI6eOUXeM_Y2^
zBl&uUl6;G@vt#2{sCQsV@Gm1`iUPA@Q?Mp~I&*5C$Ua{Vjvbd|7K&Ts8tM3FgRlk5
z{eU-+;K1XZg|0FG(rHy*;%!nvS)kJHk!lu)iACy5`1ucfp_Kw@QtytXktm7J>N9=I=%(
z78ucu#6#~f^Yg!RIj?E_Adpg(Yc%4Ia!m@Vh$QEZ4z*!F_(`l(=Z$hcW)%**8fyiI
z??lrWCJ!rn9m6JHsCymqfwENgH1h$Ji{M5B{!qzIYdU=q&Bkftl6raq;k^weW!?Cv
zc%A{}BC%CcgI47ND1j&8qcMBU7!mke2^@zJgFGFFfR1^mT;GJ@C4BL&CSgOiwC72@
zlh^gYCa);(9b&ITR?TS*Tn`b1pMeE0MjvpB8f`fr^_}<|b>91ggzy6vNOzd25tS&l
z;_C9rxLzoS7UvkOmX{NC8T*Sb-;Ws&io!5GhnDIoKkRMFF|SmwdIn`q&Mh~7qs2EH
zHZ*($6!s&sUrnf7d>KB!00DF@(DBhxxN|6fd^d?74!6j5oDm{A`1!_9uo2I?ys>!S
zp=cC8#L}-cq{&9F><2~q!J_N`t~mq*FY_=X0uF@jE?&CL`THY%mC<-}C<{RiIPBlu
z0TY7OO<}WV@)oKe)PIf;3-VWQCBM?CR0T!CP7!lBx+5!4REAojdg{ccl~#W4gmJW>d($8-$1WM5oW}h#G}oYo=~Om)3b
zVyPL*ffn>8Sr%W#1pgh<#TeCZ3pS>yB
zj9OfNwV@XxSMOJ9K4{)03`sv!gt1W%qeW+@2eIVwLj`UD(e<^zr?-vPjs1}0K&z-bDuHJ$o{vdIM=nv|5F^Z4!az%fwE5`OwDHI<|88Ex
z4cwEllEOh6$Kv?)n*e`{9X*;bQeN*|*gAQ#UZ-N_jmOHD1`AQc+8VKb5PHXX)n0)2
zl!xw)u>b+lTahKY+|coLdfhE1mFjc~a}*12uLZ+z@lg6**5gD9g_dilThBHG_2yc{2#Ke}+qZEQr#?T0U`O=ogIiLWePAwBZ
z_MvMsahoOwKeR}4mcalaK1)B^=mJjHCS26xMg$=EG2k_yGUD3)5MA1np$vZ6Vra5~
zEB=Ax?3RjZG7H2z_jvig_}e#eo^bfIc=+-
zTc~6&Az`PCwCd
z^>ord2+<%Q6(!zpE&mh*ac>iz;v2h673G$?l5{rm=0*EqZH9^$=h)Yvv;|i2$oMr9
zHg3_#Z~Uti_IxF_GHT{5XefifygVy#aaBiRe}p}cX?}>q
zJRSLCVdrB~Z#8Lhkz4oi2CFnSa~&Q|j<;UYjr8JKcUE^B3N$;^*(kF
zjSM~m;T_x{(IrihSfO!w-*6=1zsaTx;#g8$II{?*DEd3I(|0n4mUsOpz{?I_HO;{z@|EW%eXY2Q5T
zSesnQ7t3M#6Hb!Hmu7hAz3pOo#reY}JO+U8VU`dGw@mPLsO!I0@jNCO0)^HOQ>8_d
ztNc}%SR5hC2*)7X1mpYa=Zl~;ZWq0TpeE#&KW+fM)wpq$lyXtJJBgB_l{A~>eTh#*
zjo`qK^%=Gd6^DIVyHCptA+!tPs*`$nOFWYr2J=A}swt*k*t))F`8B!ajy4>uBrc6X
z>*gsUvpeE{7tNsrl3404(nOg2AUcavC6*upGvsS-ytRotWns4;z2S`;5((u-WP@Gk
z0q}2J|Its(MLEQU-e(`Q$$W&i1ZlJ7*|eJi^PrD@ox9YiZw=*rmpTc(_f#qwN
z4)f`GL_-ywroIdV-NpWPo<}b)-W<819H8}9!S_@$wjaV5a7DN&Vm=SFh?FI{?ieH^
z^Lr(h#){POmg2ep9)kiz0zWqE=Qct=nhZ*uTJk?U&$iy@1iQex4EzraUF4ZC7Qe)0
zn#9`4AG$Tj4fkE{-5XN}A}a0m!ebwc#FbiJcUN@RL0A*Dz_g#J)@3SZd)d<)?Bcc5
zQI+(ASPyJS@1@Wv(i0w3PLu#w{AU`(6tPt#di7?`od4t%p`9m%PI961`;0>
zJq~<=hf1PD>=m|IuBP7V^_kYxM?CpTL32emThO8fD$cAOvejjx&(J68`5hhph7@LSH=bvCkhIzbkon=QU@%hJ#ld<>`=L!c
zAPv$7N0*UED&@9c2ypN@F&U;WN#n%C}2cp
z-8eVy9le^)?!Etj7+9m{R@t9h2XW{cNmQpjTAzv3x`e+AYtBsBE2eu`7GgtDV|TNA
z4s`8Wx5=z0U2T&0h`DARFf*g*{@WtC$*j2Br`yiWJg%r9^L8aG5JX06To=Z
zEexc@j4_6XH`40*5;ZdbQ8-=&$+Aw)U0>EcN2nIW-9?D*8mb0W4j&->veO_0RnO}F
z4l*;Ghi8YUizGVyJ|fm8&%3~C5_{>pn?$)VN&84%LCUi6096bJ@D{`&@fgwmMrWxs
zjNMIpdhks3mqB*35*5Ndgx#QtDzlsZ*n2bHDJWh+vs*Rt!$$;ZT28#+Y`}~kWNqzL
zvzLHaMbgq1^XRiYv_Os~OT&T1G>R7>8AnMdVTFCTY#wgeOeI39xL8d|B+8k$-epNV
zXU^I6Hn$zLjptS1tGZFcxutMUOAb4PWtxTkSS~hRhz20mUNP+<&sUP
z*?WAt!GJAbA1b$MAglf)(WgeeCW8;N`eK+^3(!OqukoRm`;8=iZeoOybCN4S>*yU6
zsdFd1OpE}0{xU+p3A#(UDcz;g&f}Ck?Zf7?FJ%)Xo1~DVaXoP(*MLX=kN(2pQHqEU
z_ma&I(#RDfhFN??OKOx<%BUZ(wfp&~yv=ks&#SZ_i?vg^;n?${TIO;lUV_k{)&Hhe
ztmC#&I@Onqzsp?R)K@wp51mrm21pnT8{+_8ugmE5e9vh!l;~u#ZQ~JZQPtO5=+eVg$b{yQtn1E^Z$*#8uz$`8$
z9Q5U68k*jp!p+tBAo$9N4g6s%u5h>s^JA#@(jY_Wvd|?X6tlyyFtgNC&c12nE9Y)Ne99}c9H*hni9@4?|UcovwvaCNc-3LZj2}2R5F0o1HbZ9
zynTl9@tF<@_YiInzMr&pp|u}n*Rowx9Z7Lt;d*gT(y-;~V}I|uiN`U4S5oFt?KG`F
zo}n2EC1xf$+H+5`ckZG>=_^G_^B76?FPDQjwTA(ODGevsKQ!6)s+wok3JUycukT;p
zecfhZbFk85kR^XG02$gXhiUU2@NhM93`71?j#EnmqC@rP_L6H-G|bTGBA
z_Tdw|q#x=+J6e7b4t~bgCf$W%!?VBc9T+OOC3`Z?*Wu?6rX{IC*6oopo~%Mz&Ky1h
zKfmIlq>0BX(N~oQL_z-zvQYeDm>SOCz?95T_IGqRF)@#&IZ8(ml0bP%{76LY^(!{aa^`itE#AtGhiZ
z=#{>3kf(?#5*lu&ryS^!uM5x21Cn6O9#kN-EyUi#5Vk98{8BlembKB$$jGXPb=uCL
zl}t|~#6~Egl63UTW89M9MRTC6svr{Zc=%%WU

[dpdk-dev] [PATCH] pci: remove duplicated symbol from map file

[Ferruh Yigit]

Remove duplicated symbol rte_pci_device_name from .map file.

Also sort the map file to be able to detect any possible duplication
easier in the future.

Fixes: 0e3ef055bee5 ("pci: fix namespace prefix of new functions")
Cc: sta...@dpdk.org

Cc: gaetan.ri...@6wind.com
Signed-off-by: Ferruh Yigit 
---
 lib/librte_pci/rte_pci_version.map | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/librte_pci/rte_pci_version.map 
b/lib/librte_pci/rte_pci_version.map
index 15d93d95c..c0280277b 100644
--- a/lib/librte_pci/rte_pci_version.map
+++ b/lib/librte_pci/rte_pci_version.map
@@ -3,12 +3,11 @@ DPDK_17.11 {
 
eal_parse_pci_BDF;
eal_parse_pci_DomBDF;
-   rte_pci_addr_cmp;
-   rte_pci_addr_parse;
-   rte_pci_device_name;
pci_map_resource;
pci_unmap_resource;
rte_eal_compare_pci_addr;
+   rte_pci_addr_cmp;
+   rte_pci_addr_parse;
rte_pci_device_name;
 
local: *;
-- 
2.13.6

Re: [dpdk-dev] [PATCH 2/3] bus/pci: expose sysfs parsing API

[Wang, Xiao W]

Hi Rivet,

> -Original Message-
> From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com]
> Sent: Wednesday, March 14, 2018 9:31 PM
> To: Burakov, Anatoly 
> Cc: Wang, Xiao W ; dev@dpdk.org; Wang, Zhihong
> ; maxime.coque...@redhat.com;
> y...@fridaylinux.org; Liang, Cunming ; Xu, Rosen
> ; Chen, Junjie J ; Daly, Dan
> 
> Subject: Re: [dpdk-dev] [PATCH 2/3] bus/pci: expose sysfs parsing API
> 
> Hi,
> 
> On Wed, Mar 14, 2018 at 11:19:31AM +, Burakov, Anatoly wrote:
> > On 09-Mar-18 11:08 PM, Xiao Wang wrote:
> > > Some existing sysfs parsing functions are helpful for the later vDPA
> > > driver, this patch make them global and expose them to shared lib.
> > >
> > > Signed-off-by: Xiao Wang 
> > > ---
> > >   drivers/bus/pci/linux/pci.c | 9 -
> > >   drivers/bus/pci/linux/pci_init.h| 8 
> > >   drivers/bus/pci/rte_bus_pci_version.map | 8 
> > >   3 files changed, 20 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
> > > index abde64119..81e5e5650 100644
> > > --- a/drivers/bus/pci/linux/pci.c
> > > +++ b/drivers/bus/pci/linux/pci.c
> > > @@ -32,7 +32,7 @@
> > >   extern struct rte_pci_bus rte_pci_bus;
> > > -static int
> > > +int
> > >   pci_get_kernel_driver_by_path(const char *filename, char *dri_name)
> >
> > Here and in other places - shouldn't this too be prefixed with rte_?
> >
> 
> A public PCI function should be prefixed by rte_pci_ yes.

OK, will add this prefix.

> 
> Additionally, if this function was to be exposed, then there should be a
> BSD implementation as well (shared map file).
> 
> I don't know how BSD works, I'm not sure parsing the filesystem is the
> way to get a PCI driver name. If so, maybe the function should be called
> another, generic, way, that would work for both linux and BSD (and
> ideally, having a real BSD implementation).

BSD is not parsing the filesystem, it uses PCIOCGETCONF ioctl to retrieve
PCI device information.
This function is quite linux, especially for the API name. I'm afraid we can
only return err on BSD for this API.

BRs,
Xiao

> 
> >
> > --
> > Thanks,
> > Anatoly
> 
> --
> Gaëtan Rivet
> 6WIND

Re: [dpdk-dev] [PATCH v3 00/10] meson build support for dpaaX

[Bruce Richardson]

On Wed, Mar 14, 2018 at 01:25:56PM +0530, Hemant Agrawal wrote:
> Earlier dpaaX was only compiled for armv8 target. This patch series first 
> prepares the dpaaX drivers to be compiled for non-ARM platform as well.
> 
> 
> Note: This patch changes all of the dpaa drivers/modules - So it shall be 
> applied to master tree instead of meson build tree.
> 
> v3:
>   - improved cross files and a function issue in dpaa2 bus.
> 
> v2: 
>   - handle review comments from Bruce
>   - move the dpaaX compilation to linuxapp
> 
> Hemant Agrawal (10):
>   event/dpaa: fix include header
>   bus/dpaa: fix the BE compilation issue
>   dpaa: prepare for 32 bit compilation
>   dpaa2: prepare for 32 bit compilation
>   bus/fslmc: add 32 bit functional support for ARM
>   bus/dpaa: enabling dpaa compilation for other platforms
>   bus/fslmc: enabling dpaa2 compilation for other platforms
>   config: add dpaaX build support in common linuxapp
>   build: add meson support for dpaaX platforms
>   build: add meson cross compile config for dpaaX
> 
Patches applied to dpdk-next-build.

Pull-request to master to follow shortly.

/Bruce

Re: [dpdk-dev] [PATCH 2/3] bus/pci: expose sysfs parsing API

[Gaëtan Rivet]

On Thu, Mar 15, 2018 at 04:49:41PM +, Wang, Xiao W wrote:
> Hi Rivet,
> 
> > -Original Message-
> > From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com]
> > Sent: Wednesday, March 14, 2018 9:31 PM
> > To: Burakov, Anatoly 
> > Cc: Wang, Xiao W ; dev@dpdk.org; Wang, Zhihong
> > ; maxime.coque...@redhat.com;
> > y...@fridaylinux.org; Liang, Cunming ; Xu, Rosen
> > ; Chen, Junjie J ; Daly, Dan
> > 
> > Subject: Re: [dpdk-dev] [PATCH 2/3] bus/pci: expose sysfs parsing API
> > 
> > Hi,
> > 
> > On Wed, Mar 14, 2018 at 11:19:31AM +, Burakov, Anatoly wrote:
> > > On 09-Mar-18 11:08 PM, Xiao Wang wrote:
> > > > Some existing sysfs parsing functions are helpful for the later vDPA
> > > > driver, this patch make them global and expose them to shared lib.
> > > >
> > > > Signed-off-by: Xiao Wang 
> > > > ---
> > > >   drivers/bus/pci/linux/pci.c | 9 -
> > > >   drivers/bus/pci/linux/pci_init.h| 8 
> > > >   drivers/bus/pci/rte_bus_pci_version.map | 8 
> > > >   3 files changed, 20 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
> > > > index abde64119..81e5e5650 100644
> > > > --- a/drivers/bus/pci/linux/pci.c
> > > > +++ b/drivers/bus/pci/linux/pci.c
> > > > @@ -32,7 +32,7 @@
> > > >   extern struct rte_pci_bus rte_pci_bus;
> > > > -static int
> > > > +int
> > > >   pci_get_kernel_driver_by_path(const char *filename, char *dri_name)
> > >
> > > Here and in other places - shouldn't this too be prefixed with rte_?
> > >
> > 
> > A public PCI function should be prefixed by rte_pci_ yes.
> 
> OK, will add this prefix.
> 
> > 
> > Additionally, if this function was to be exposed, then there should be a
> > BSD implementation as well (shared map file).
> > 
> > I don't know how BSD works, I'm not sure parsing the filesystem is the
> > way to get a PCI driver name. If so, maybe the function should be called
> > another, generic, way, that would work for both linux and BSD (and
> > ideally, having a real BSD implementation).
> 
> BSD is not parsing the filesystem, it uses PCIOCGETCONF ioctl to retrieve
> PCI device information.
> This function is quite linux, especially for the API name. I'm afraid we can
> only return err on BSD for this API.

How about renaming the function to something like
rte_pci_device_kdriver_name();

and allowing for a sensible BSD implementation to happen if someone
needs it?

-- 
Gaëtan Rivet
6WIND

[dpdk-dev] Pull request for dpdk-next-build

[Bruce Richardson]

The following changes since commit c06ddf9698e0c2a9653cfa971f9ddc205065662c:

  meter: add configuration profile (2018-02-19 22:28:05 +0100)

are available in the Git repository at:

  http://dpdk.org/git/draft/dpdk-next-build

for you to fetch changes up to a4ffb69205a55ed6acae00b324165aecbbc67dfb:

  build: add meson cross compile config for dpaaX (2018-03-15 17:01:01 +)


Bruce Richardson (6):
  examples: fix building examples with meson
  app: generalize building of apps using meson
  app/proc_info: rename folder to remove underscore
  app: add all remaining apps to meson build
  net/virtio: add driver to meson build
  net/pcap: simplify dependency checking using meson

Hemant Agrawal (10):
  event/dpaa: fix include header
  bus/dpaa: fix the BE compilation issue
  dpaa: prepare for 32 bit compilation
  dpaa2: prepare for 32 bit compilation
  bus/fslmc: add 32 bit functional support for ARM
  bus/dpaa: enabling dpaa compilation for other platforms
  bus/fslmc: enabling dpaa2 compilation for other platforms
  config: add dpaaX build support in common linuxapp
  build: add meson support for dpaaX platforms
  build: add meson cross compile config for dpaaX

 app/Makefile|   2 +-
 app/meson.build |  56 ++-
 app/pdump/meson.build   |   6 ++
 app/{proc_info => proc-info}/Makefile   |   0
 app/{proc_info => proc-info}/main.c |   0
 app/proc-info/meson.build   |   6 ++
 app/test-bbdev/meson.build  |   9 +++
 app/test-crypto-perf/meson.build|  14 
 app/test-eventdev/meson.build   |  18 +
 app/test-pmd/meson.build|  23 ++-
 config/arm/arm64_dpaa2_linuxapp_gcc |  15 +
 config/arm/arm64_dpaa_linuxapp_gcc  |  15 +
 config/arm/meson.build  |  13 
 config/common_armv8a_linuxapp   |  58 
 config/common_base  |   4 ++
 config/common_linuxapp  |  14 
 config/rte_config.h |  12 +++-
 drivers/bus/dpaa/base/fman/fman.c   |   2 +-
 drivers/bus/dpaa/base/qbman/bman_driver.c   |   2 +-
 drivers/bus/dpaa/base/qbman/qman.c  |   5 +-
 drivers/bus/dpaa/base/qbman/qman_driver.c   |   5 +-
 drivers/bus/dpaa/dpaa_bus.c |   3 +-
 drivers/bus/dpaa/include/compat.h   |  30 -
 drivers/bus/dpaa/meson.build|  29 
 drivers/bus/fslmc/fslmc_vfio.c  |  10 +--
 drivers/bus/fslmc/mc/fsl_mc_cmd.h   |   2 +-
 drivers/bus/fslmc/meson.build   |  27 
 drivers/bus/fslmc/portal/dpaa2_hw_dpio.c|  22 +++---
 drivers/bus/fslmc/portal/dpaa2_hw_pvt.h |  37 +-
 drivers/bus/fslmc/qbman/qbman_portal.c  |  14 ++--
 drivers/bus/fslmc/qbman/qbman_sys.h |  30 -
 drivers/bus/fslmc/qbman/qbman_sys_decl.h|  23 +++
 drivers/bus/meson.build |   2 +-
 drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 101 ++--
 drivers/crypto/dpaa2_sec/meson.build|  14 
 drivers/crypto/dpaa_sec/dpaa_sec.c  |  30 -
 drivers/crypto/dpaa_sec/meson.build |  13 
 drivers/crypto/meson.build  |   4 +-
 drivers/event/dpaa/dpaa_eventdev.c  |   2 +-
 drivers/event/dpaa/meson.build  |  10 +++
 drivers/event/dpaa2/dpaa2_eventdev.c|  10 +--
 drivers/event/dpaa2/meson.build |  11 +++
 drivers/event/meson.build   |   2 +-
 drivers/mempool/dpaa/dpaa_mempool.c |  10 +--
 drivers/mempool/dpaa/dpaa_mempool.h |   2 +-
 drivers/mempool/dpaa/meson.build|   9 +++
 drivers/mempool/dpaa2/dpaa2_hw_mempool.c|   8 +--
 drivers/mempool/dpaa2/meson.build   |   9 +++
 drivers/mempool/meson.build |   2 +-
 drivers/net/dpaa/dpaa_rxtx.c|  19 +++---
 drivers/net/dpaa/meson.build|  14 
 drivers/net/dpaa2/Makefile  |   1 -
 drivers/net/dpaa2/base/dpaa2_hw_dpni.c  |   2 +-
 drivers/net/dpaa2/dpaa2_ethdev.c|   6 +-
 drivers/net/dpaa2/dpaa2_rxtx.c  |  63 +
 drivers/net/dpaa2/meson.build   |  15 +
 drivers/net/meson.build |   4 +-
 drivers/net/pcap/meson.build|  20 ++
 drivers/net/virtio/meson.build  |  27 
 examples/ip_pipeline/meson.build|   1 +
 examples/qos_meter/meson.build  |   1 +
 61 files changed, 616 insertions(+), 302 deletions(-)
 create mode 100644 app/pdump/meson.build
 rename app/{proc_info => proc-info}/Makefile (100%)
 rename app/{proc_info => proc-info}/main.c (100%)
 create mode 100644 app/proc-i

Re: [dpdk-dev] [PATCH] pci: remove duplicated symbol from map file

[Gaëtan Rivet]

Hi Ferruh,

On Thu, Mar 15, 2018 at 04:48:54PM +, Ferruh Yigit wrote:
> Remove duplicated symbol rte_pci_device_name from .map file.
> 
> Also sort the map file to be able to detect any possible duplication
> easier in the future.
> 
> Fixes: 0e3ef055bee5 ("pci: fix namespace prefix of new functions")
> Cc: sta...@dpdk.org
> 

Acked-by: Gaetan Rivet 

> Signed-off-by: Ferruh Yigit 
> ---
>  lib/librte_pci/rte_pci_version.map | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_pci/rte_pci_version.map 
> b/lib/librte_pci/rte_pci_version.map
> index 15d93d95c..c0280277b 100644
> --- a/lib/librte_pci/rte_pci_version.map
> +++ b/lib/librte_pci/rte_pci_version.map
> @@ -3,12 +3,11 @@ DPDK_17.11 {
>  
>   eal_parse_pci_BDF;
>   eal_parse_pci_DomBDF;
> - rte_pci_addr_cmp;
> - rte_pci_addr_parse;
> - rte_pci_device_name;
>   pci_map_resource;
>   pci_unmap_resource;
>   rte_eal_compare_pci_addr;
> + rte_pci_addr_cmp;
> + rte_pci_addr_parse;
>   rte_pci_device_name;
>  
>   local: *;
> -- 
> 2.13.6
> 

-- 
Gaëtan Rivet
6WIND

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Wiles, Keith]

> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger  
> wrote:
> 
> On Thu, 15 Mar 2018 16:15:21 +
> "Melik-Adamyan, Areg"  wrote:
> 
>> Hello.
>> 
>> Within Intel, we developed and open-sourced a DPDK based high-level library 
>> and runtime named Network Function Framework for Go (NFF-Go: 
>> https://github.com/intel-go/nff-go) which is intended to simplify packet 
>> processing applications, especially for cloud-native deployment. Based on 
>> DPDK NFF-Go provides higher-level packet processing functions in native Go 
>> alongside with simple, powerful runtime.
>> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as 
>> that would result in poor performance due to the 300-1500 cycles that can be 
>> spent by a context switch. Instead, NFF-Go uses pointers from the DPDK 
>> initialization of the device mbuf structures. It permits copying of packet 
>> data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere 
>> where DPDK works.
>> *Capabilities:* Library provides functions to create packet processing graph 
>> from user-defined or predefined functions. The graph can be arbitrary but 
>> will need to have a single entry point. The user can freely use both 
>> synchronous and asynchronous programming capabilities provided by Go 
>> language. Also, auto-scaling is automatically provided by the built-in 
>> scheduler using cores as needed, and freeing them after use. NFF-Go provides 
>> an alternative development environment for creating network functions using 
>> a smaller number of lines of code compared to DPDK/C without sacrificing 
>> performance. These capabilities make it possible to implement 
>> run-till-completion packet processing model.  The library includes a 
>> component called boundary node, which allows consuming packet data from all 
>> types of sources: Ethernet, file, memory buffer, remote procedure call and 
>> then applying the packets to the processing graph which will be 
>> transparently deployed through any cloud orchestration engine.
>> *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for 
>> bringing packet processing to less experienced developers and push towards 
>> cloud-native usages. We strongly believe that NFF-Go is complementary to 
>> DPDK. Having a closer link between them should help both projects - it will 
>> ease pickup from one source/repo the needed set of features to be used, 
>> rather than us just providing a disjointed collection of software projects 
>> which are hosted in different places.
>> 
>> We expect the initial commit to include the following:
>> 
>> -  Low, Asm - low-level C and ASM code for gluing DPDK
>> 
>> -  Packet - a library that provides an abstraction for packet and 
>> tools to manipulate
>> 
>> -  Flow  - library to provide an abstraction for packet flows
>> 
>> -  Scheduler - runtime and a scheduler for auto-scaling and 
>> integration with RSS
>> 
>> -  Examples:
>> 
>> o   Forwarding - simple L3 forwarding
>> 
>> o   Firewall - an example of simple ACL based firewall
>> 
>> o   Tutorial - step based tutorial how to use NFF-Go
>> 
>> o   NAT - an example of production grade Network Address Translation
>> 
>> o   AntiDDOS - simple example of AntiDDOS on L3
>> 
>> -  Automation scripts - helping to build, deploy and test 
>> applications on a single host
>> 
>> Thanks,
>> Areg Melik-Adamyan
>> Engineering Manager
>> Developer Products Divison
>> Intel Corporation
> 
> I am ok with it being on DPDK, but might it make more sense on github or 
> under FD.io?
> Or is there some legal and/or political reason not to?

There is no legal or political reason is my guess and only because it is 
closely connected to DPDK is the reason.

I know that DPDK TAC and others are not wanting to have a lot of repos in 
DPDK.org for maintains reason and I agree.

I would like to see us use a single GitHub account to house these different 
projects as then we would have a much cleaner one stop shopping for DPDK 
related projects. We have the mirror for DPDK on GitHub https://github.com/DPDK 
and we could easily add all of these projects in this organization account as 
Thomas seems to be the only person attached to the account. We could then allow 
people to move projects to this account with the correct permission or 
restrictions as we see fit and allow other (TAC member?) to help manage the 
account.

It may cost some money at some point, but I have not looked into it more then a 
year.



Regards,
Keith

Re: [dpdk-dev] [PATCH v8 00/15] common linkstatus functions

[Ferruh Yigit]

On 1/26/2018 2:01 AM, Stephen Hemminger wrote:
> While writing hyper-v driver, noticed a lot of unnecessary
> duplication of code in drivers for handling the eth_dev link status
> information. While consolidating this, it also became obvious that
> some drivers behave differently for no good reason.
> 
> It also was a good chance to introduce atomic exchange primitives
> in EAL because there are other places using cmpset where not
> necessary (such as bonding).
> 
> Mostly only compile tested only, don't have all of the hardware
> available (except ixgbe and virtio) to test.
> 
> v8
>   - fix typo in 32bit exchange
>   - fix build of dpaa2
>   - go back to same return value as original code
>   - reduce number of lines changed
> 
> v7
>   - add exchange functions for PPC64
>   - move linkstatus helpers to rte_ethdev_driver
>   - rebase to 18.02
> 
> Stephen Hemminger (15):
>   eal: introduce atomic exchange operation
>   ethdev: add linkstatus get/set helper functions
>   net/virtio: use eth_linkstatus_set
>   net/vmxnet3: use rte_eth_linkstatus_set
>   net/dpaa2: use rte_eth_linkstatus_set
>   net/nfp: use rte_eth_linkstatus functions
>   net/e1000: use rte_eth_linkstatus helpers
>   net/ixgbe: use rte_eth_linkstatus functions
>   net/sfc: use new rte_eth_linkstatus functions
>   net/i40e: use rte_eth_linkstatus functions
>   net/liquidio: use rte_eth_linkstatus_set
>   net/thunderx: use rte_eth_linkstatus_set
>   net/szedata: use _rte_eth_linkstatus_set
>   net/octeontx: use rte_eth_linkstatus_set
>   net/enic: use rte_eth_linkstatus_set

For series
Reviewed-by: Ferruh Yigit 

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Wiles, Keith]

> On Mar 15, 2018, at 12:29 PM, Wiles, Keith  wrote:
> 
> 
> 
>> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger  
>> wrote:
>> 
>> On Thu, 15 Mar 2018 16:15:21 +
>> "Melik-Adamyan, Areg"  wrote:
>> 
>>> Hello.
>>> 
>>> Within Intel, we developed and open-sourced a DPDK based high-level library 
>>> and runtime named Network Function Framework for Go (NFF-Go: 
>>> https://github.com/intel-go/nff-go) which is intended to simplify packet 
>>> processing applications, especially for cloud-native deployment. Based on 
>>> DPDK NFF-Go provides higher-level packet processing functions in native Go 
>>> alongside with simple, powerful runtime.
>>> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as 
>>> that would result in poor performance due to the 300-1500 cycles that can 
>>> be spent by a context switch. Instead, NFF-Go uses pointers from the DPDK 
>>> initialization of the device mbuf structures. It permits copying of packet 
>>> data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere 
>>> where DPDK works.
>>> *Capabilities:* Library provides functions to create packet processing 
>>> graph from user-defined or predefined functions. The graph can be arbitrary 
>>> but will need to have a single entry point. The user can freely use both 
>>> synchronous and asynchronous programming capabilities provided by Go 
>>> language. Also, auto-scaling is automatically provided by the built-in 
>>> scheduler using cores as needed, and freeing them after use. NFF-Go 
>>> provides an alternative development environment for creating network 
>>> functions using a smaller number of lines of code compared to DPDK/C 
>>> without sacrificing performance. These capabilities make it possible to 
>>> implement run-till-completion packet processing model.  The library 
>>> includes a component called boundary node, which allows consuming packet 
>>> data from all types of sources: Ethernet, file, memory buffer, remote 
>>> procedure call and then applying the packets to the processing graph which 
>>> will be transparently deployed through any cloud orchestration engine.
>>> *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for 
>>> bringing packet processing to less experienced developers and push towards 
>>> cloud-native usages. We strongly believe that NFF-Go is complementary to 
>>> DPDK. Having a closer link between them should help both projects - it will 
>>> ease pickup from one source/repo the needed set of features to be used, 
>>> rather than us just providing a disjointed collection of software projects 
>>> which are hosted in different places.
>>> 
>>> We expect the initial commit to include the following:
>>> 
>>> -  Low, Asm - low-level C and ASM code for gluing DPDK
>>> 
>>> -  Packet - a library that provides an abstraction for packet and 
>>> tools to manipulate
>>> 
>>> -  Flow  - library to provide an abstraction for packet flows
>>> 
>>> -  Scheduler - runtime and a scheduler for auto-scaling and 
>>> integration with RSS
>>> 
>>> -  Examples:
>>> 
>>> o   Forwarding - simple L3 forwarding
>>> 
>>> o   Firewall - an example of simple ACL based firewall
>>> 
>>> o   Tutorial - step based tutorial how to use NFF-Go
>>> 
>>> o   NAT - an example of production grade Network Address Translation
>>> 
>>> o   AntiDDOS - simple example of AntiDDOS on L3
>>> 
>>> -  Automation scripts - helping to build, deploy and test 
>>> applications on a single host
>>> 
>>> Thanks,
>>> Areg Melik-Adamyan
>>> Engineering Manager
>>> Developer Products Divison
>>> Intel Corporation
>> 
>> I am ok with it being on DPDK, but might it make more sense on github or 
>> under FD.io?
>> Or is there some legal and/or political reason not to?
> 
> There is no legal or political reason is my guess and only because it is 
> closely connected to DPDK is the reason.
> 
> I know that DPDK TAC and others are not wanting to have a lot of repos in 
> DPDK.org for maintains reason and I agree.
> 
> I would like to see us use a single GitHub account to house these different 
> projects as then we would have a much cleaner one stop shopping for DPDK 
> related projects. We have the mirror for DPDK on GitHub 
> https://github.com/DPDK and we could easily add all of these projects in this 
> organization account as Thomas seems to be the only person attached to the 
> account. We could then allow people to move projects to this account with the 
> correct permission or restrictions as we see fit and allow other (TAC 
> member?) to help manage the account.
> 
> It may cost some money at some point, but I have not looked into it more then 
> a year.

Here is the different models for pricing: https://github.com/pricing

I would suggest Team account as it seems the cheapest as long as you have 
public repos and not a lot of private repos is how I read it.

https://github.com/pricing/team

> 
> 
> 
> Regards,
> Keith
> 

Regards,
Keith

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Stephen Hemminger]

On Thu, 15 Mar 2018 17:29:44 +
"Wiles, Keith"  wrote:

> > On Mar 15, 2018, at 11:19 AM, Stephen Hemminger 
> >  wrote:
> > 
> > On Thu, 15 Mar 2018 16:15:21 +
> > "Melik-Adamyan, Areg"  wrote:
> >   
> >> Hello.
> >> 
> >> Within Intel, we developed and open-sourced a DPDK based high-level 
> >> library and runtime named Network Function Framework for Go (NFF-Go: 
> >> https://github.com/intel-go/nff-go) which is intended to simplify packet 
> >> processing applications, especially for cloud-native deployment. Based on 
> >> DPDK NFF-Go provides higher-level packet processing functions in native Go 
> >> alongside with simple, powerful runtime.
> >> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as 
> >> that would result in poor performance due to the 300-1500 cycles that can 
> >> be spent by a context switch. Instead, NFF-Go uses pointers from the DPDK 
> >> initialization of the device mbuf structures. It permits copying of packet 
> >> data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere 
> >> where DPDK works.
> >> *Capabilities:* Library provides functions to create packet processing 
> >> graph from user-defined or predefined functions. The graph can be 
> >> arbitrary but will need to have a single entry point. The user can freely 
> >> use both synchronous and asynchronous programming capabilities provided by 
> >> Go language. Also, auto-scaling is automatically provided by the built-in 
> >> scheduler using cores as needed, and freeing them after use. NFF-Go 
> >> provides an alternative development environment for creating network 
> >> functions using a smaller number of lines of code compared to DPDK/C 
> >> without sacrificing performance. These capabilities make it possible to 
> >> implement run-till-completion packet processing model.  The library 
> >> includes a component called boundary node, which allows consuming packet 
> >> data from all types of sources: Ethernet, file, memory buffer, remote 
> >> procedure call and then applying the packets to the processing graph which 
> >> will be transparently deployed through any cloud orchestration engine
 .
> >> *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for 
> >> bringing packet processing to less experienced developers and push towards 
> >> cloud-native usages. We strongly believe that NFF-Go is complementary to 
> >> DPDK. Having a closer link between them should help both projects - it 
> >> will ease pickup from one source/repo the needed set of features to be 
> >> used, rather than us just providing a disjointed collection of software 
> >> projects which are hosted in different places.
> >> 
> >> We expect the initial commit to include the following:
> >> 
> >> -  Low, Asm - low-level C and ASM code for gluing DPDK
> >> 
> >> -  Packet - a library that provides an abstraction for packet and 
> >> tools to manipulate
> >> 
> >> -  Flow  - library to provide an abstraction for packet flows
> >> 
> >> -  Scheduler - runtime and a scheduler for auto-scaling and 
> >> integration with RSS
> >> 
> >> -  Examples:
> >> 
> >> o   Forwarding - simple L3 forwarding
> >> 
> >> o   Firewall - an example of simple ACL based firewall
> >> 
> >> o   Tutorial - step based tutorial how to use NFF-Go
> >> 
> >> o   NAT - an example of production grade Network Address Translation
> >> 
> >> o   AntiDDOS - simple example of AntiDDOS on L3
> >> 
> >> -  Automation scripts - helping to build, deploy and test 
> >> applications on a single host
> >> 
> >> Thanks,
> >> Areg Melik-Adamyan
> >> Engineering Manager
> >> Developer Products Divison
> >> Intel Corporation  
> > 
> > I am ok with it being on DPDK, but might it make more sense on github or 
> > under FD.io?
> > Or is there some legal and/or political reason not to?  
> 
> There is no legal or political reason is my guess and only because it is 
> closely connected to DPDK is the reason.
> 
> I know that DPDK TAC and others are not wanting to have a lot of repos in 
> DPDK.org for maintains reason and I agree.
> 
> I would like to see us use a single GitHub account to house these different 
> projects as then we would have a much cleaner one stop shopping for DPDK 
> related projects. We have the mirror for DPDK on GitHub 
> https://github.com/DPDK and we could easily add all of these projects in this 
> organization account as Thomas seems to be the only person attached to the 
> account. We could then allow people to move projects to this account with the 
> correct permission or restrictions as we see fit and allow other (TAC 
> member?) to help manage the account.
> 
> It may cost some money at some point, but I have not looked into it more then 
> a year.
> 
> 
> 
> Regards,
> Keith
> 

I was thinking more that projects on DPDK should use similar software process.
If you go to another location, you would use their Pull Request and review 
model.
If the project is under

[dpdk-dev] [PATCH v1 00/18] Device querying

[Gaetan Rivet]

This patchset introduces a new EAL API for querying devices,
filtered by arbitrary properties.

The following elements are introduced to this end:

 * A new object, "rte_class", is used to describe
   the device class abstraction layer (eth, crypto, ...).

 * Both rte_bus and rte_class now offer a way to
   list their devices and filter the result
   using locally defined properties.

 * The rte_dev API now has an rte_dev_iterator, which
   is the way for the user to define the device filter
   and iterate upon the resulting set.

As an example, the "eth" device class is implemented.

Additionally, the device filters for

  + rte_bus_pci
  + rte_bus_vdev
  + rte_class_eth

are implemented and can be used with some
properties each, to show how to extend those.

Some example of filters:

  "bus=pci/class=eth"
  "bus=pci"
  "class=eth"
  "class=eth,name=net_ring0"
  "bus=pci,id=00:00.0"
  "bus=vdev,driver=net_ring"

Gaetan Rivet (18):
  eal: introduce dtor macros
  eal: introduce device class abstraction
  eal/class: register destructor
  eal: add lightweight kvarg parsing utility
  eal/dev: add device iterator interface
  eal/dev: implement device iteration initialization
  eal/class: add device iteration
  eal/bus: add device iteration
  eal/dev: implement device iteration
  ethdev: register ether layer as a class
  ethdev: add device matching field name
  bus/pci: fix find device implementation
  bus/pci: implement device iteration and comparison
  bus/pci: add device matching field id
  bus/vdev: fix find device implementation
  bus/vdev: implement device iteration
  bus/vdev: add device matching field driver
  app/testpmd: add show device command

 app/test-pmd/cmdline.c |  52 +
 drivers/bus/pci/Makefile   |   2 +-
 drivers/bus/pci/pci_common.c   |  97 ++--
 drivers/bus/pci/rte_bus_pci.h  |   3 +
 drivers/bus/vdev/Makefile  |   2 +-
 drivers/bus/vdev/rte_bus_vdev.h|   3 +
 drivers/bus/vdev/vdev.c|  86 +-
 lib/Makefile   |   2 +-
 lib/librte_eal/bsdapp/eal/Makefile |   1 +
 lib/librte_eal/common/Makefile |   2 +-
 lib/librte_eal/common/eal_common_class.c   |  62 ++
 lib/librte_eal/common/eal_common_dev.c | 177 +
 lib/librte_eal/common/eal_private.h|  34 ++
 lib/librte_eal/common/include/rte_bus.h|   1 +
 lib/librte_eal/common/include/rte_class.h  | 127 +
 lib/librte_eal/common/include/rte_common.h |  23 
 lib/librte_eal/common/include/rte_dev.h|  84 ++
 lib/librte_eal/linuxapp/eal/Makefile   |   1 +
 lib/librte_eal/rte_eal_version.map |   4 +
 lib/librte_ether/Makefile  |   3 +-
 lib/librte_ether/rte_class_eth.c   | 100 
 21 files changed, 847 insertions(+), 19 deletions(-)
 create mode 100644 lib/librte_eal/common/eal_common_class.c
 create mode 100644 lib/librte_eal/common/include/rte_class.h
 create mode 100644 lib/librte_ether/rte_class_eth.c

-- 
2.11.0

[dpdk-dev] [PATCH v1 01/18] eal: introduce dtor macros

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/include/rte_common.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_common.h 
b/lib/librte_eal/common/include/rte_common.h
index c7803e41c..500fc3adb 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -105,6 +105,29 @@ static void __attribute__((constructor, used)) func(void)
 static void __attribute__((constructor(prio), used)) func(void)
 
 /**
+ * Run after main() with high priority.
+ *
+ * The destructor will be run *before* prioritized destructors.
+ *
+ * @param func
+ *   Destructor function name.
+ */
+#define RTE_FINI(func) \
+static void __attribute__((destructor, used)) func(void)
+
+/**
+ * Run after main() with low priority.
+ *
+ * @param func
+ *   Destructor function name.
+ * @param prio
+ *   Priority number must be above 100.
+ *   Lowest number is the last to run.
+ */
+#define RTE_FINI_PRIO(func, prio) \
+static void __attribute__((destructor(prio), used)) func(void)
+
+/**
  * Force a function to be inlined
  */
 #define __rte_always_inline inline __attribute__((always_inline))
-- 
2.11.0

[dpdk-dev] [PATCH v1 02/18] eal: introduce device class abstraction

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/bsdapp/eal/Makefile|   1 +
 lib/librte_eal/common/Makefile|   2 +-
 lib/librte_eal/common/eal_common_class.c  |  62 +++
 lib/librte_eal/common/include/rte_class.h | 121 ++
 lib/librte_eal/linuxapp/eal/Makefile  |   1 +
 lib/librte_eal/rte_eal_version.map|   2 +
 6 files changed, 188 insertions(+), 1 deletion(-)
 create mode 100644 lib/librte_eal/common/eal_common_class.c
 create mode 100644 lib/librte_eal/common/include/rte_class.h

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index dd455e671..17ff1ac45 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -48,6 +48,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_hypervisor.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_string_fns.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_hexdump.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_devargs.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_class.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_bus.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_dev.c
 SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_common_options.c
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index ea824a3a8..211b21b4b 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -11,7 +11,7 @@ INC += rte_per_lcore.h rte_random.h
 INC += rte_tailq.h rte_interrupts.h rte_alarm.h
 INC += rte_string_fns.h rte_version.h
 INC += rte_eal_memconfig.h rte_malloc_heap.h
-INC += rte_hexdump.h rte_devargs.h rte_bus.h rte_dev.h
+INC += rte_hexdump.h rte_devargs.h rte_bus.h rte_dev.h rte_class.h
 INC += rte_pci_dev_feature_defs.h rte_pci_dev_features.h
 INC += rte_malloc.h rte_keepalive.h rte_time.h
 INC += rte_service.h rte_service_component.h
diff --git a/lib/librte_eal/common/eal_common_class.c 
b/lib/librte_eal/common/eal_common_class.c
new file mode 100644
index 0..aed4dd8fb
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_class.c
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 Gaëtan Rivet
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct rte_class_list rte_class_list =
+   TAILQ_HEAD_INITIALIZER(rte_class_list);
+
+__rte_experimental void
+rte_class_register(struct rte_class *class)
+{
+   RTE_VERIFY(class);
+   RTE_VERIFY(class->name && strlen(class->name));
+
+   TAILQ_INSERT_TAIL(&rte_class_list, class, next);
+   RTE_LOG(DEBUG, EAL, "Registered [%s] device class.\n", class->name);
+}
+
+__rte_experimental void
+rte_class_unregister(struct rte_class *class)
+{
+   TAILQ_REMOVE(&rte_class_list, class, next);
+   RTE_LOG(DEBUG, EAL, "Unregistered [%s] device class.\n", class->name);
+}
+
+struct rte_class *
+rte_class_find(const struct rte_class *start, rte_class_cmp_t cmp,
+  const void *data)
+{
+   struct rte_class *cls;
+
+   if (start != NULL)
+   cls = TAILQ_NEXT(start, next);
+   else
+   cls = TAILQ_FIRST(&rte_class_list);
+   while (cls != NULL) {
+   if (cmp(cls, data) == 0)
+   break;
+   cls = TAILQ_NEXT(cls, next);
+   }
+   return cls;
+}
+
+static int
+cmp_class_name(const struct rte_class *class, const void *_name)
+{
+   const char *name = _name;
+
+   return strcmp(class->name, name);
+}
+
+struct rte_class *
+rte_class_find_by_name(const char *name)
+{
+   return rte_class_find(NULL, cmp_class_name, (const void *)name);
+}
diff --git a/lib/librte_eal/common/include/rte_class.h 
b/lib/librte_eal/common/include/rte_class.h
new file mode 100644
index 0..beb0ba86c
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_class.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 Gaëtan Rivet
+ */
+
+#ifndef _RTE_CLASS_H_
+#define _RTE_CLASS_H_
+
+/**
+ * @file
+ *
+ * DPDK device class interface.
+ *
+ * This file exposes API and interfaces of device classes.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+#include 
+
+/** Double linked list of classes */
+TAILQ_HEAD(rte_class_list, rte_class);
+
+/**
+ * A structure describing a generic device class.
+ */
+struct rte_class {
+   TAILQ_ENTRY(rte_class) next; /**< Next device class in linked list */
+   const char *name; /**< Name of the class */
+};
+
+/**
+ * Class comparison function.
+ *
+ * @param cls
+ * Class under test.
+ *
+ * @param data
+ * Data to compare against.
+ *
+ * @return
+ * 0 if the class matches the data.
+ * !0 if the class does not match.
+ * <0 if ordering is possible and the class is lower than the data.
+ * >0 if ordering is possible and the class is greater than the data.
+ */
+typedef int (*rte_class_cmp_t)(const struct rte_class *cls, const void *data);
+
+/**
+ * Class iterator to find a parti

[dpdk-dev] [PATCH v1 03/18] eal/class: register destructor

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/include/rte_class.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_class.h 
b/lib/librte_eal/common/include/rte_class.h
index beb0ba86c..a2e5f5551 100644
--- a/lib/librte_eal/common/include/rte_class.h
+++ b/lib/librte_eal/common/include/rte_class.h
@@ -112,6 +112,11 @@ static void classinitfn_ ##nm(void) \
 {\
(cls).name = RTE_STR(nm);\
rte_class_register(&cls); \
+} \
+RTE_FINI_PRIO(classfinifn_ ##nm, 120); \
+static void classfinifn_ ##nm(void) \
+{ \
+   rte_class_unregister(&cls); \
 }
 
 #ifdef __cplusplus
-- 
2.11.0

[dpdk-dev] [PATCH v1 05/18] eal/dev: add device iterator interface

[Gaetan Rivet]

A device iterator allows iterating over a set of devices.
This set is defined by the two descriptions offered,

  * rte_bus
  * rte_class

Only one description can be provided, or both. It is not allowed to
provide no description at all.

Each layer of abstraction them performs a filter based on the
description provided. This filtering allows iterating on their internal
set of devices, stopping when a match is valid and storing the current
iteration context.

This context allows starting the next iteration from the same point and
going forward.

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/include/rte_dev.h | 36 +
 1 file changed, 36 insertions(+)

diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index b688f1efd..d272d7191 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -263,6 +263,42 @@ __attribute__((used)) = str
 static const char DRV_EXP_TAG(name, kmod_dep_export)[] \
 __attribute__((used)) = str
 
+/**
+ * Iteration context.
+ *
+ * This context carries over the current iteration state.
+ */
+struct rte_dev_iterator {
+   const char *devstr; /**< device string. */
+   /* Bus context. */
+   struct rte_bus *bus; /**< bus handle. */
+   const char *busstr; /**< bus-related part of device string. */
+   struct rte_device *device; /**< current position. */
+   /* Class context. */
+   struct rte_class *cls; /**< class handle. */
+   const char *clsstr; /**< class-related part of device string. */
+   void *class_device; /**< additional specialized context. */
+};
+
+/**
+ * Device iteration function.
+ *
+ * Iterate over a set of devices, defined in comprehension by
+ * the given iterator.
+ *
+ * This function must update the internal rte_dev_iterator ``device``
+ * field. The ``context`` field can be used as an additional generic context
+ * when the current ``rte_device`` is insufficient.
+ *
+ * @param it
+ *   Device iterator.
+ *
+ * @return
+ *   The address of the current element when the stopping
+ *   condition became valid.
+ */
+typedef struct rte_device *(*rte_dev_iterate_t)(struct rte_dev_iterator *it);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.11.0

[dpdk-dev] [PATCH v1 06/18] eal/dev: implement device iteration initialization

[Gaetan Rivet]

Parse a device description.

Split this description in their relevant part for both abstraction
layer.

No dynamic allocation is performed.

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/eal_common_dev.c  | 58 +
 lib/librte_eal/common/include/rte_dev.h | 23 +
 lib/librte_eal/rte_eal_version.map  |  1 +
 3 files changed, 82 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index 4032f1bd8..bdab1423a 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -245,3 +246,60 @@ rte_eal_hotplug_remove(const char *busname, const char 
*devname)
rte_eal_devargs_remove(busname, devname);
return ret;
 }
+
+int __rte_experimental
+rte_dev_iterator_init(struct rte_dev_iterator *it, const char *str)
+{
+   struct rte_bus *bus = NULL;
+   struct rte_class *cls = NULL;
+   struct rte_kvarg kv;
+
+   /* Having both busstr and clsstr NULL is illegal,
+* marking this iterator as invalid unless
+* everything goes well.
+*/
+   it->busstr = NULL;
+   it->clsstr = NULL;
+   /* Safety checks and prep-work */
+   if (rte_parse_kv(str, &kv)) {
+   RTE_LOG(ERR, EAL, "Could not parse: %s\n", str);
+   return -1;
+   }
+   it->device = NULL;
+   it->class_device = NULL;
+   if (strcmp(kv.key, "bus") == 0) {
+   char *slash;
+
+   bus = rte_bus_find_by_name(kv.value);
+   it->busstr = str;
+   slash = strchr(str, '/');
+   if (slash != NULL) {
+   if (rte_parse_kv(slash + 1, &kv))
+   return -1;
+   cls = rte_class_find_by_name(kv.value);
+   it->clsstr = slash + 1;
+   }
+   } else if (strcmp(kv.key, "class") == 0) {
+   cls = rte_class_find_by_name(kv.value);
+   it->clsstr = str;
+   } else {
+   rte_errno = EINVAL;
+   return -rte_errno;
+   }
+   /* The string should have at least
+* one layer specified.
+*/
+   if (bus == NULL && cls == NULL) {
+   rte_errno = EINVAL;
+   return -rte_errno;
+   }
+   if ((bus != NULL && bus->dev_iterate == NULL) ||
+   (cls != NULL && cls->dev_iterate == NULL)) {
+   rte_errno = ENOTSUP;
+   return -rte_errno;
+   }
+   it->devstr = str;
+   it->bus = bus;
+   it->cls = cls;
+   return 0;
+}
diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index d272d7191..9b53f0ad3 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -299,6 +299,29 @@ struct rte_dev_iterator {
  */
 typedef struct rte_device *(*rte_dev_iterate_t)(struct rte_dev_iterator *it);
 
+/**
+ * Initializes a device iterator.
+ *
+ * This iterator allows accessing a list of devices matching a criteria.
+ * The device matching is made among all buses and classes currently 
registered,
+ * filtered by the device description given as parameter.
+ *
+ * This function will not allocate any memory. It is safe to stop the
+ * iteration at any moment and let the iterator go out of context.
+ *
+ * @param it
+ *   Device iterator handle.
+ *
+ * @param str
+ *   Device description string.
+ *
+ * @return
+ *   0 on successful initialization.
+ *   <0 on error.
+ */
+int __rte_experimental
+rte_dev_iterator_init(struct rte_dev_iterator *it, const char *str);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/rte_eal_version.map 
b/lib/librte_eal/rte_eal_version.map
index 910cb23c9..921da3075 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -228,6 +228,7 @@ EXPERIMENTAL {
rte_mp_sendmsg;
rte_mp_request;
rte_mp_reply;
+   rte_dev_iterator_init;
rte_service_attr_get;
rte_service_attr_reset_all;
rte_service_component_register;
-- 
2.11.0

[dpdk-dev] [PATCH v1 04/18] eal: add lightweight kvarg parsing utility

[Gaetan Rivet]

This library offers a quick way to parse parameters passed with a
key=value syntax.

A single function is needed and finds the relevant element within the
text. No dynamic allocation is performed. It is possible to chain the
parsing of each pairs for quickly scanning a list.

This utility is private to the EAL and should allow avoiding having to
move around the more complete librte_kvargs.

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/eal_common_dev.c | 38 ++
 lib/librte_eal/common/eal_private.h| 34 ++
 2 files changed, 72 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index cd071442f..4032f1bd8 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -13,10 +13,48 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "eal_private.h"
 
+/* EAL-private function. */
+int
+rte_parse_kv(const char *str, struct rte_kvarg *kv)
+{
+   const char *equal;
+   const char *end;
+
+   if (str == NULL || str[0] == '\0')
+   return 1;
+   equal = strchr(str, '=');
+   if (equal == NULL) {
+   rte_errno = EINVAL;
+   return -1;
+   }
+   end = strchr(equal + 1, ',');
+   end = end ? end : strchr(equal + 1, '/');
+   end = end ? end : strchr(equal + 1, '\0');
+   if (end == NULL) {
+   rte_errno = ENODEV;
+   return -1;
+   }
+   if (kv == NULL)
+   return 0;
+   snprintf(kv->data, sizeof(kv->data), "%s", str);
+   kv->key = &kv->data[0];
+   strchr(kv->data, end[0])[0] = '\0';
+   if (strchr(kv->data, '=')) {
+   kv->value = strchr(kv->data, '=') + 1;
+   strchr(kv->data, '=')[0] = '\0';
+   }
+   if (end[0] == '\0')
+   kv->next = NULL;
+   else
+   kv->next = end + 1;
+   return 0;
+}
+
 static int cmp_detached_dev_name(const struct rte_device *dev,
const void *_name)
 {
diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 0b2877000..d2774a3ad 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -205,4 +205,38 @@ struct rte_bus *rte_bus_find_by_device_name(const char 
*str);
 
 int rte_mp_channel_init(void);
 
+/*
+ * Lightweight kvarg parsing library.
+ */
+
+#define RTE_MAX_KVARG_LEN 64
+
+/**
+ * Kvarg representation.
+ */
+struct rte_kvarg {
+   char *key; /**< points the key in the data. */
+   char *value; /**< points the value in the data. */
+   const char *next; /**< next token to parse, if any. */
+   char data[RTE_MAX_KVARG_LEN + 1]; /**< local copy of key and value. */
+};
+
+/**
+ * Parse one kvarg.
+ *
+ * The key-value pair must be shorter than the rte_kvarg data size.
+ *
+ * @param[in] str
+ *   text to parse.
+ *
+ * @param[out] kv
+ *   kvarg structure to fill.
+ *
+ * @return
+ *   0 if parsing succeeded.
+ *   >0 if there was nothing to parse.
+ *   <0 on error, rte_errno is set.
+ */
+int rte_parse_kv(const char *str, struct rte_kvarg *kv);
+
 #endif /* _EAL_PRIVATE_H_ */
-- 
2.11.0

[dpdk-dev] [PATCH v1 08/18] eal/bus: add device iteration

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/include/rte_bus.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/common/include/rte_bus.h 
b/lib/librte_eal/common/include/rte_bus.h
index 6fb08341a..46911afa7 100644
--- a/lib/librte_eal/common/include/rte_bus.h
+++ b/lib/librte_eal/common/include/rte_bus.h
@@ -211,6 +211,7 @@ struct rte_bus {
rte_bus_parse_t parse;   /**< Parse a device name */
struct rte_bus_conf conf;/**< Bus configuration */
rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
+   rte_dev_iterate_t dev_iterate; /**< Device iterator. */
 };
 
 /**
-- 
2.11.0

[dpdk-dev] [PATCH v1 09/18] eal/dev: implement device iteration

[Gaetan Rivet]

Use the iteration hooks in the abstraction layers to perform the
requested filtering on the internal device lists.

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/eal_common_dev.c  | 81 +
 lib/librte_eal/common/include/rte_dev.h | 25 ++
 lib/librte_eal/rte_eal_version.map  |  1 +
 3 files changed, 107 insertions(+)

diff --git a/lib/librte_eal/common/eal_common_dev.c 
b/lib/librte_eal/common/eal_common_dev.c
index bdab1423a..159fdcf73 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -303,3 +303,84 @@ rte_dev_iterator_init(struct rte_dev_iterator *it, const 
char *str)
it->cls = cls;
return 0;
 }
+
+static int
+class_next_dev_cmp(const struct rte_class *cls,
+  const void *_it)
+{
+   const struct rte_dev_iterator *cit = _it;
+   struct rte_dev_iterator *it;
+
+   if (cls->dev_iterate == NULL)
+   return 1;
+   /* We need a mutable iterator. */
+   it = (void *)(intptr_t)cit;
+   /* it->clsstr != NULL means a class
+* was specified in the devstr.
+*/
+   if (it->clsstr != NULL && cls != it->cls)
+   return 1;
+   return cls->dev_iterate(it) == NULL;
+}
+
+static int
+bus_next_dev_cmp(const struct rte_bus *bus,
+const void *_it)
+{
+   const struct rte_dev_iterator *cit = _it;
+   struct rte_class *cls = NULL;
+   struct rte_dev_iterator *it;
+
+   if (bus->dev_iterate == NULL)
+   return 1;
+   /* We need a mutable iterator. */
+   it = (void *)(intptr_t)cit;
+   /* it->busstr != NULL means a bus
+* was specified in the devstr.
+*/
+   if (it->busstr != NULL && bus != it->bus)
+   return 1;
+   if (it->clsstr == NULL)
+   return bus->dev_iterate(it) == NULL;
+   /* clsstr != NULL */
+   if (it->device == NULL)
+next_dev_on_bus:
+   bus->dev_iterate(it);
+   if (it->device == NULL)
+   return 1;
+   if (it->cls != NULL)
+   cls = TAILQ_PREV(it->cls, rte_class_list, next);
+   cls = rte_class_find(cls, class_next_dev_cmp, it);
+   if (cls != NULL) {
+   it->cls = cls;
+   return 0;
+   }
+   goto next_dev_on_bus;
+}
+__rte_experimental struct rte_device *
+rte_dev_iterator_next(struct rte_dev_iterator *it)
+{
+   struct rte_bus *bus = NULL;
+   int old_errno = rte_errno;
+
+   rte_errno = 0;
+   if (it->busstr == NULL && it->clsstr == NULL) {
+   /* Invalid iterator. */
+   rte_errno = EINVAL;
+   return NULL;
+   }
+   if (it->bus != NULL)
+   bus = TAILQ_PREV(it->bus, rte_bus_list, next);
+   while ((bus = rte_bus_find(bus, bus_next_dev_cmp, it))) {
+   if (it->device != NULL) {
+   it->bus = bus;
+   return it->device;
+   }
+   if (it->busstr != NULL ||
+   rte_errno != 0)
+   break;
+   }
+   if (rte_errno == 0)
+   rte_errno = old_errno;
+   return NULL;
+}
diff --git a/lib/librte_eal/common/include/rte_dev.h 
b/lib/librte_eal/common/include/rte_dev.h
index 9b53f0ad3..11a6d786c 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -322,6 +322,31 @@ typedef struct rte_device *(*rte_dev_iterate_t)(struct 
rte_dev_iterator *it);
 int __rte_experimental
 rte_dev_iterator_init(struct rte_dev_iterator *it, const char *str);
 
+/**
+ * Iterates on a device iterator.
+ *
+ * Generates a new rte_device handle corresponding to the next element
+ * in the list described in comprehension by the iterator.
+ *
+ * The next object is returned, and the iterator is updated.
+ *
+ * @param it
+ *   Device iterator handle.
+ *
+ * @return
+ *   An rte_device handle if found.
+ *   NULL if an error occurred (rte_errno is set).
+ *   NULL if no device could be found (rte_errno is not set).
+ */
+struct rte_device * __rte_experimental
+rte_dev_iterator_next(struct rte_dev_iterator *it);
+
+#define RTE_DEV_FOREACH(dev, devstr, it) \
+   for (rte_dev_iterator_init(it, devstr), \
+dev = rte_dev_iterator_next(it); \
+dev != NULL; \
+dev = rte_dev_iterator_next(it))
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/rte_eal_version.map 
b/lib/librte_eal/rte_eal_version.map
index 921da3075..925efcb6d 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -229,6 +229,7 @@ EXPERIMENTAL {
rte_mp_request;
rte_mp_reply;
rte_dev_iterator_init;
+   rte_dev_iterator_next;
rte_service_attr_get;
rte_service_attr_reset_all;
rte_service_component_register;
-- 
2.11.0

[dpdk-dev] [PATCH v1 07/18] eal/class: add device iteration

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/librte_eal/common/include/rte_class.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_eal/common/include/rte_class.h 
b/lib/librte_eal/common/include/rte_class.h
index a2e5f5551..47ebaba31 100644
--- a/lib/librte_eal/common/include/rte_class.h
+++ b/lib/librte_eal/common/include/rte_class.h
@@ -30,6 +30,7 @@ TAILQ_HEAD(rte_class_list, rte_class);
 struct rte_class {
TAILQ_ENTRY(rte_class) next; /**< Next device class in linked list */
const char *name; /**< Name of the class */
+   rte_dev_iterate_t dev_iterate; /**< Device iterator. */
 };
 
 /**
-- 
2.11.0

[dpdk-dev] [PATCH v1 10/18] ethdev: register ether layer as a class

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 lib/Makefile |  2 +-
 lib/librte_ether/Makefile|  3 +-
 lib/librte_ether/rte_class_eth.c | 86 
 3 files changed, 89 insertions(+), 2 deletions(-)
 create mode 100644 lib/librte_ether/rte_class_eth.c

diff --git a/lib/Makefile b/lib/Makefile
index ec965a606..6bb6a8bed 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -20,7 +20,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += librte_cmdline
 DEPDIRS-librte_cmdline := librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_ETHER) += librte_ether
 DEPDIRS-librte_ether := librte_net librte_eal librte_mempool librte_ring
-DEPDIRS-librte_ether += librte_mbuf
+DEPDIRS-librte_ether += librte_mbuf librte_kvargs
 DIRS-$(CONFIG_RTE_LIBRTE_BBDEV) += librte_bbdev
 DEPDIRS-librte_bbdev := librte_eal librte_mempool librte_mbuf
 DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += librte_cryptodev
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 3ca5782bb..a1a0393de 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -12,13 +12,14 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS)
 LDLIBS += -lrte_net -lrte_eal -lrte_mempool -lrte_ring
-LDLIBS += -lrte_mbuf
+LDLIBS += -lrte_mbuf -lrte_kvargs
 
 EXPORT_MAP := rte_ethdev_version.map
 
 LIBABIVER := 8
 
 SRCS-y += rte_ethdev.c
+SRCS-y += rte_class_eth.c
 SRCS-y += rte_flow.c
 SRCS-y += rte_tm.c
 SRCS-y += rte_mtr.c
diff --git a/lib/librte_ether/rte_class_eth.c b/lib/librte_ether/rte_class_eth.c
new file mode 100644
index 0..bfa821d09
--- /dev/null
+++ b/lib/librte_ether/rte_class_eth.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Gaëtan Rivet
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rte_ethdev.h"
+#include "rte_ethdev_core.h"
+
+static int
+eth_dev_match(struct rte_eth_dev *edev,
+ struct rte_kvargs *kvlist)
+{
+   (void) kvlist;
+   (void) edev;
+   return 0;
+}
+
+static struct rte_device *
+eth_dev_iterate(struct rte_dev_iterator *it)
+{
+   struct rte_eth_dev *start = it->class_device;
+   struct rte_kvargs *kvargs = NULL;
+   struct rte_eth_dev *edev = NULL;
+   struct rte_device *dev = NULL;
+   char *str = NULL;
+   uint16_t p = 0;
+
+   if (it->clsstr != NULL) {
+   char *slash;
+
+   str = strdup(it->clsstr);
+   if (str == NULL) {
+   RTE_LOG(ERR, EAL, "cannot allocate string copy\n");
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+   slash = strchr(str, '/');
+   slash = slash ? slash : strchr(str, '\0');
+   if (slash == NULL) {
+   RTE_LOG(ERR, EAL, "malformed string\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   slash[0] = '\0';
+   kvargs = rte_kvargs_parse(str, NULL);
+   if (kvargs == NULL) {
+   RTE_LOG(ERR, EAL, "cannot parse argument list\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   }
+   if (start)
+   p = start->data->port_id + 1;
+   dev = it->device;
+   for (p = rte_eth_find_next(p);
+p < RTE_MAX_ETHPORTS;
+p = rte_eth_find_next(p + 1)) {
+   edev = &rte_eth_devices[p];
+   if (dev != edev->device)
+   continue;
+   if (eth_dev_match(edev, kvargs) == 0) {
+   it->class_device = edev;
+   goto free_str;
+   }
+   }
+   dev = NULL;
+free_str:
+   if (it->clsstr != NULL) {
+   rte_kvargs_free(kvargs);
+   free(str);
+   }
+   return dev;
+}
+
+struct rte_class rte_class_eth = {
+   .dev_iterate = eth_dev_iterate,
+};
+
+RTE_REGISTER_CLASS(eth, rte_class_eth);
-- 
2.11.0

[dpdk-dev] [PATCH v1 13/18] bus/pci: implement device iteration and comparison

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/pci/Makefile |  2 +-
 drivers/bus/pci/pci_common.c | 54 
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/pci/Makefile b/drivers/bus/pci/Makefile
index f3df1c4ce..73498dc77 100644
--- a/drivers/bus/pci/Makefile
+++ b/drivers/bus/pci/Makefile
@@ -50,7 +50,7 @@ CFLAGS += -I$(RTE_SDK)/lib/librte_eal/common
 CFLAGS += -I$(RTE_SDK)/lib/librte_eal/$(SYSTEM)app/eal
 
 LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
-LDLIBS += -lrte_ethdev -lrte_pci
+LDLIBS += -lrte_ethdev -lrte_pci -lrte_kvargs
 
 include $(RTE_SDK)/drivers/bus/pci/$(SYSTEM)/Makefile
 SRCS-$(CONFIG_RTE_LIBRTE_PCI_BUS) := $(addprefix $(SYSTEM)/,$(SRCS))
diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 2c45f8151..482c96df2 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -497,6 +498,58 @@ pci_unplug(struct rte_device *dev)
return ret;
 }
 
+static int
+pci_dev_match(const struct rte_device *dev,
+ const void *_kvlist)
+{
+   const struct rte_kvargs *kvlist = _kvlist;
+
+   (void) dev;
+   (void) kvlist;
+   return 0;
+}
+
+static struct rte_device *
+pci_dev_iterate(struct rte_dev_iterator *it)
+{
+   struct rte_device *dev = it->device;
+   struct rte_kvargs *kvargs = NULL;
+   char *str = NULL;
+
+   if (it->busstr != NULL) {
+   char *slash;
+
+   str = strdup(it->busstr);
+   if (str == NULL) {
+   RTE_LOG(ERR, EAL, "could not allocate string copy\n");
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+   slash = strchr(str, '/');
+   slash = slash ? slash : strchr(str, '\0');
+   if (slash == NULL) {
+   RTE_LOG(ERR, EAL, "malformed string\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   slash[0] = '\0';
+   kvargs = rte_kvargs_parse(str, NULL);
+   if (kvargs == NULL) {
+   RTE_LOG(ERR, EAL, "cannot parse argument list\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   }
+   dev = pci_find_device(dev, pci_dev_match, kvargs);
+   it->device = dev;
+free_str:
+   if (it->busstr != NULL) {
+   free(str);
+   rte_kvargs_free(kvargs);
+   }
+   return dev;
+}
+
 struct rte_pci_bus rte_pci_bus = {
.bus = {
.scan = rte_pci_scan,
@@ -506,6 +559,7 @@ struct rte_pci_bus rte_pci_bus = {
.unplug = pci_unplug,
.parse = pci_parse,
.get_iommu_class = rte_pci_get_iommu_class,
+   .dev_iterate = pci_dev_iterate,
},
.device_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.device_list),
.driver_list = TAILQ_HEAD_INITIALIZER(rte_pci_bus.driver_list),
-- 
2.11.0

[dpdk-dev] [PATCH v1 11/18] ethdev: add device matching field name

[Gaetan Rivet]

The eth device class can now parse a field name,
matching the eth_dev name with one passed as

   "class=eth,name=xx"

Signed-off-by: Gaetan Rivet 
---
 lib/librte_ether/rte_class_eth.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/lib/librte_ether/rte_class_eth.c b/lib/librte_ether/rte_class_eth.c
index bfa821d09..2f362ebcc 100644
--- a/lib/librte_ether/rte_class_eth.c
+++ b/lib/librte_ether/rte_class_eth.c
@@ -14,11 +14,25 @@
 #include "rte_ethdev_core.h"
 
 static int
+eth_dev_str_cmp(const char *key __rte_unused,
+   const char *value,
+   void *_str)
+{
+   const char *str = _str;
+
+   return strcmp(str, value);
+}
+
+static int
 eth_dev_match(struct rte_eth_dev *edev,
  struct rte_kvargs *kvlist)
 {
-   (void) kvlist;
-   (void) edev;
+   struct rte_eth_dev_data *data;
+
+   data = edev->data;
+   if (rte_kvargs_process(kvlist, "name",
+   ð_dev_str_cmp, data->name))
+   return 1;
return 0;
 }
 
-- 
2.11.0

[dpdk-dev] [PATCH v1 12/18] bus/pci: fix find device implementation

[Gaetan Rivet]

If start is set, and a device before it matches the data
passed for comparison, then this first device is returned.

This produces potentially infinite loops.

Fixes: c7fe1eea8a74 ("bus: simplify finding starting point")
Cc: sta...@dpdk.org

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/pci/pci_common.c  | 21 -
 drivers/bus/pci/rte_bus_pci.h |  3 +++
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 2a00f365a..2c45f8151 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -459,17 +459,20 @@ static struct rte_device *
 pci_find_device(const struct rte_device *start, rte_dev_cmp_t cmp,
const void *data)
 {
-   struct rte_pci_device *dev;
+   const struct rte_pci_device *pstart;
+   struct rte_pci_device *pdev;
 
-   FOREACH_DEVICE_ON_PCIBUS(dev) {
-   if (start && &dev->device == start) {
-   start = NULL; /* starting point found */
-   continue;
-   }
-   if (cmp(&dev->device, data) == 0)
-   return &dev->device;
+   if (start != NULL) {
+   pstart = RTE_DEV_TO_PCI_CONST(start);
+   pdev = TAILQ_NEXT(pstart, next);
+   } else {
+   pdev = TAILQ_FIRST(&rte_pci_bus.device_list);
+   }
+   while (pdev != NULL) {
+   if (cmp(&pdev->device, data) == 0)
+   return &pdev->device;
+   pdev = TAILQ_NEXT(pdev, next);
}
-
return NULL;
 }
 
diff --git a/drivers/bus/pci/rte_bus_pci.h b/drivers/bus/pci/rte_bus_pci.h
index 357afb912..458e6d076 100644
--- a/drivers/bus/pci/rte_bus_pci.h
+++ b/drivers/bus/pci/rte_bus_pci.h
@@ -74,6 +74,9 @@ struct rte_pci_device {
  */
 #define RTE_DEV_TO_PCI(ptr) container_of(ptr, struct rte_pci_device, device)
 
+#define RTE_DEV_TO_PCI_CONST(ptr) \
+   container_of(ptr, const struct rte_pci_device, device)
+
 #define RTE_ETH_DEV_TO_PCI(eth_dev)RTE_DEV_TO_PCI((eth_dev)->device)
 
 /** Any PCI device identifier (vendor, device, ...) */
-- 
2.11.0

[dpdk-dev] [PATCH v1 16/18] bus/vdev: implement device iteration

[Gaetan Rivet]

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/vdev/Makefile |  2 +-
 drivers/bus/vdev/vdev.c   | 54 +++
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/vdev/Makefile b/drivers/bus/vdev/Makefile
index 24d424a38..52728833c 100644
--- a/drivers/bus/vdev/Makefile
+++ b/drivers/bus/vdev/Makefile
@@ -19,7 +19,7 @@ LIBABIVER := 1
 
 SRCS-y += vdev.c
 
-LDLIBS += -lrte_eal
+LDLIBS += -lrte_eal -lrte_kvargs
 
 #
 # Export include files
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index 68306f4eb..d695bdf24 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -415,6 +416,58 @@ vdev_unplug(struct rte_device *dev)
return rte_vdev_uninit(dev->name);
 }
 
+static int
+vdev_dev_match(const struct rte_device *dev,
+  const void *_kvlist)
+{
+   const struct rte_kvargs *kvlist = _kvlist;
+
+   (void) kvlist;
+   (void) dev;
+   return 0;
+}
+
+static struct rte_device *
+vdev_dev_iterate(struct rte_dev_iterator *it)
+{
+   struct rte_device *dev = it->device;
+   struct rte_kvargs *kvargs = NULL;
+   char *str = NULL;
+
+   if (it->busstr != NULL) {
+   char *slash;
+
+   str = strdup(it->busstr);
+   if (str == NULL) {
+   VDEV_LOG(ERR, "could not allocate string copy\n");
+   rte_errno = ENOMEM;
+   return NULL;
+   }
+   slash = strchr(str, '/');
+   slash = slash ? slash : strchr(str, '\0');
+   if (slash == NULL) {
+   VDEV_LOG(ERR, "malformed string\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   slash[0] = '\0';
+   kvargs = rte_kvargs_parse(str, NULL);
+   if (kvargs == NULL) {
+   VDEV_LOG(ERR, "cannot parse argument list\n");
+   rte_errno = EINVAL;
+   goto free_str;
+   }
+   }
+   dev = vdev_find_device(dev, vdev_dev_match, kvargs);
+   it->device = dev;
+free_str:
+   if (it->busstr != NULL) {
+   free(str);
+   rte_kvargs_free(kvargs);
+   }
+   return dev;
+}
+
 static struct rte_bus rte_vdev_bus = {
.scan = vdev_scan,
.probe = vdev_probe,
@@ -422,6 +475,7 @@ static struct rte_bus rte_vdev_bus = {
.plug = vdev_plug,
.unplug = vdev_unplug,
.parse = vdev_parse,
+   .dev_iterate = vdev_dev_iterate,
 };
 
 RTE_REGISTER_BUS(vdev, rte_vdev_bus);
-- 
2.11.0

[dpdk-dev] [PATCH v1 14/18] bus/pci: add device matching field id

[Gaetan Rivet]

The PCI bus can now parse a matching field "id" as follows:

   "bus=pci,id=:00:00.0"

   or

   "bus=pci,id=00:00.0"

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/pci/pci_common.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c
index 482c96df2..6cf1279c3 100644
--- a/drivers/bus/pci/pci_common.c
+++ b/drivers/bus/pci/pci_common.c
@@ -499,13 +499,35 @@ pci_unplug(struct rte_device *dev)
 }
 
 static int
+pci_addr_kv_cmp(const char *key __rte_unused,
+   const char *value,
+   void *_addr2)
+{
+   struct rte_pci_addr _addr1;
+   struct rte_pci_addr *addr1 = &_addr1;
+   struct rte_pci_addr *addr2 = _addr2;
+
+   if (rte_pci_addr_parse(value, addr1))
+   return -1;
+   return rte_pci_addr_cmp(addr1, addr2);
+}
+
+static int
 pci_dev_match(const struct rte_device *dev,
  const void *_kvlist)
 {
const struct rte_kvargs *kvlist = _kvlist;
+   const struct rte_pci_device *pdev;
 
-   (void) dev;
-   (void) kvlist;
+   if (kvlist == NULL)
+   /* Empty string matches everything. */
+   return 0;
+   pdev = RTE_DEV_TO_PCI_CONST(dev);
+   /* if any field does not match. */
+   if (rte_kvargs_process(kvlist, "id",
+  &pci_addr_kv_cmp,
+  (void *)(intptr_t)&pdev->addr))
+   return 1;
return 0;
 }
 
-- 
2.11.0

[dpdk-dev] [PATCH v1 17/18] bus/vdev: add device matching field driver

[Gaetan Rivet]

The vdev bus parses a field "driver", matching
a vdev driver name with one passed as follows:

   "bus=vdev,driver="

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/vdev/vdev.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index d695bdf24..154d5e4bb 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -417,13 +417,31 @@ vdev_unplug(struct rte_device *dev)
 }
 
 static int
+vdev_str_kv_cmp(const char *key __rte_unused,
+const char *value,
+void *_str)
+{
+   const  char *str = _str;
+
+   return strcmp(str, value);
+}
+
+static int
 vdev_dev_match(const struct rte_device *dev,
   const void *_kvlist)
 {
const struct rte_kvargs *kvlist = _kvlist;
+   const struct rte_vdev_device *vdev;
 
-   (void) kvlist;
-   (void) dev;
+   if (kvlist == NULL)
+   /* Empty string matches everything. */
+   return 0;
+   vdev = RTE_DEV_TO_VDEV_CONST(dev);
+   /* if any field does not match. */
+   if (rte_kvargs_process(kvlist, "driver",
+   &vdev_str_kv_cmp,
+   (void *)(intptr_t)vdev->device.driver->name))
+   return 1;
return 0;
 }
 
-- 
2.11.0

[dpdk-dev] [PATCH v1 18/18] app/testpmd: add show device command

[Gaetan Rivet]

A new interactive command is offered:

   show device 

This commands lists all rte_device element matching the device
description. e.g.:

   show device bus=pci
   show device bus=vdev
   show device bus=vdev,class=eth
   show device bus=vdev,class=eth,name=net_ring0

These devices may not be otherwise useful, some buses will spawn devices
to keep track of their assets without having a driver to use them.

Signed-off-by: Gaetan Rivet 
---
 app/test-pmd/cmdline.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 40b31ad7e..8ac5fb3ca 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6701,6 +6701,57 @@ cmdline_parse_inst_t cmd_showportall = {
},
 };
 
+/* *** SHOW DEVICE INFO *** */
+struct cmd_showdevice_result {
+   cmdline_fixed_string_t show;
+   cmdline_fixed_string_t device;
+   cmdline_fixed_string_t filter;
+};
+
+static void
+cmd_showdevice_dump_device(const struct rte_device *dev)
+{
+   const struct rte_driver *drv = dev->driver;
+
+   printf("0x%p: %s:%s\n", (const void *)dev, dev->name,
+   drv ? drv->name : "");
+}
+
+static void cmd_showdevice_parsed(void *parsed_result,
+   __attribute__((unused)) struct cmdline *cl,
+   __attribute__((unused)) void *data)
+{
+   struct cmd_showdevice_result *res = parsed_result;
+   struct rte_dev_iterator it;
+   const struct rte_device *dev;
+
+   RTE_DEV_FOREACH(dev, res->filter, &it)
+   cmd_showdevice_dump_device(dev);
+}
+
+cmdline_parse_token_string_t cmd_showdevice_show =
+   TOKEN_STRING_INITIALIZER(struct cmd_showdevice_result,
+   show, "show");
+cmdline_parse_token_string_t cmd_showdevice_device =
+   TOKEN_STRING_INITIALIZER(struct cmd_showdevice_result,
+   device, "device");
+cmdline_parse_token_string_t cmd_showdevice_filter =
+   TOKEN_STRING_INITIALIZER(struct cmd_showdevice_result,
+   filter, NULL);
+
+cmdline_parse_inst_t cmd_showdevice = {
+   .f = cmd_showdevice_parsed,
+   .data = NULL,
+   .help_str = "show device "
+   "",
+   .tokens = {
+   (void *)&cmd_showdevice_show,
+   (void *)&cmd_showdevice_device,
+   (void *)&cmd_showdevice_filter,
+   NULL,
+   },
+};
+
 /* *** SHOW PORT INFO *** */
 struct cmd_showport_result {
cmdline_fixed_string_t show;
@@ -16038,6 +16089,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_parse_inst_t *)&cmd_help_long,
(cmdline_parse_inst_t *)&cmd_quit,
(cmdline_parse_inst_t *)&cmd_load_from_file,
+   (cmdline_parse_inst_t *)&cmd_showdevice,
(cmdline_parse_inst_t *)&cmd_showport,
(cmdline_parse_inst_t *)&cmd_showqueue,
(cmdline_parse_inst_t *)&cmd_showportall,
-- 
2.11.0

[dpdk-dev] [PATCH v1 15/18] bus/vdev: fix find device implementation

[Gaetan Rivet]

If start is set and a device before it matches the data,
this device is returned.

This produces induces potentially infinite loops.

Fixes: c7fe1eea8a74 ("bus: simplify finding starting point")
Cc: sta...@dpdk.org

Signed-off-by: Gaetan Rivet 
---
 drivers/bus/vdev/rte_bus_vdev.h |  3 +++
 drivers/bus/vdev/vdev.c | 14 +-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h
index f9d8a2383..4da9967c6 100644
--- a/drivers/bus/vdev/rte_bus_vdev.h
+++ b/drivers/bus/vdev/rte_bus_vdev.h
@@ -53,6 +53,9 @@ struct rte_vdev_device {
 #define RTE_DEV_TO_VDEV(ptr) \
container_of(ptr, struct rte_vdev_device, device)
 
+#define RTE_DEV_TO_VDEV_CONST(ptr) \
+   container_of(ptr, const struct rte_vdev_device, device)
+
 static inline const char *
 rte_vdev_device_name(const struct rte_vdev_device *dev)
 {
diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c
index e4bc72463..68306f4eb 100644
--- a/drivers/bus/vdev/vdev.c
+++ b/drivers/bus/vdev/vdev.c
@@ -386,15 +386,19 @@ static struct rte_device *
 vdev_find_device(const struct rte_device *start, rte_dev_cmp_t cmp,
 const void *data)
 {
+   const struct rte_vdev_device *vstart;
struct rte_vdev_device *dev;
 
-   TAILQ_FOREACH(dev, &vdev_device_list, next) {
-   if (start && &dev->device == start) {
-   start = NULL;
-   continue;
-   }
+   if (start != NULL) {
+   vstart = RTE_DEV_TO_VDEV_CONST(start);
+   dev = TAILQ_NEXT(vstart, next);
+   } else {
+   dev = TAILQ_FIRST(&vdev_device_list);
+   }
+   while (dev != NULL) {
if (cmp(&dev->device, data) == 0)
return &dev->device;
+   dev = TAILQ_NEXT(dev, next);
}
return NULL;
 }
-- 
2.11.0

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Wiles, Keith]

Sorry, did not mean to highjack this thread, I will start a new one.

> On Mar 15, 2018, at 12:48 PM, Stephen Hemminger  
> wrote:
> 
> On Thu, 15 Mar 2018 17:29:44 +
> "Wiles, Keith"  wrote:
> 
>>> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger 
>>>  wrote:
>>> 
>>> On Thu, 15 Mar 2018 16:15:21 +
>>> "Melik-Adamyan, Areg"  wrote:
>>> 
 Hello.
 
 Within Intel, we developed and open-sourced a DPDK based high-level 
 library and runtime named Network Function Framework for Go (NFF-Go: 
 https://github.com/intel-go/nff-go) which is intended to simplify packet 
 processing applications, especially for cloud-native deployment. Based on 
 DPDK NFF-Go provides higher-level packet processing functions in native Go 
 alongside with simple, powerful runtime.
 NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK as 
 that would result in poor performance due to the 300-1500 cycles that can 
 be spent by a context switch. Instead, NFF-Go uses pointers from the DPDK 
 initialization of the device mbuf structures. It permits copying of packet 
 data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere 
 where DPDK works.
 *Capabilities:* Library provides functions to create packet processing 
 graph from user-defined or predefined functions. The graph can be 
 arbitrary but will need to have a single entry point. The user can freely 
 use both synchronous and asynchronous programming capabilities provided by 
 Go language. Also, auto-scaling is automatically provided by the built-in 
 scheduler using cores as needed, and freeing them after use. NFF-Go 
 provides an alternative development environment for creating network 
 functions using a smaller number of lines of code compared to DPDK/C 
 without sacrificing performance. These capabilities make it possible to 
 implement run-till-completion packet processing model.  The library 
 includes a component called boundary node, which allows consuming packet 
 data from all types of sources: Ethernet, file, memory buffer, remote 
 procedure call and then applying the packets to the processing graph which 
 will be transparently deployed through any cloud orchestration engine.
 *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for 
 bringing packet processing to less experienced developers and push towards 
 cloud-native usages. We strongly believe that NFF-Go is complementary to 
 DPDK. Having a closer link between them should help both projects - it 
 will ease pickup from one source/repo the needed set of features to be 
 used, rather than us just providing a disjointed collection of software 
 projects which are hosted in different places.
 
 We expect the initial commit to include the following:
 
 -  Low, Asm - low-level C and ASM code for gluing DPDK
 
 -  Packet - a library that provides an abstraction for packet and 
 tools to manipulate
 
 -  Flow  - library to provide an abstraction for packet flows
 
 -  Scheduler - runtime and a scheduler for auto-scaling and 
 integration with RSS
 
 -  Examples:
 
 o   Forwarding - simple L3 forwarding
 
 o   Firewall - an example of simple ACL based firewall
 
 o   Tutorial - step based tutorial how to use NFF-Go
 
 o   NAT - an example of production grade Network Address Translation
 
 o   AntiDDOS - simple example of AntiDDOS on L3
 
 -  Automation scripts - helping to build, deploy and test 
 applications on a single host
 
 Thanks,
 Areg Melik-Adamyan
 Engineering Manager
 Developer Products Divison
 Intel Corporation  
>>> 
>>> I am ok with it being on DPDK, but might it make more sense on github or 
>>> under FD.io?
>>> Or is there some legal and/or political reason not to?  
>> 
>> There is no legal or political reason is my guess and only because it is 
>> closely connected to DPDK is the reason.
>> 
>> I know that DPDK TAC and others are not wanting to have a lot of repos in 
>> DPDK.org for maintains reason and I agree.
>> 
>> I would like to see us use a single GitHub account to house these different 
>> projects as then we would have a much cleaner one stop shopping for DPDK 
>> related projects. We have the mirror for DPDK on GitHub 
>> https://github.com/DPDK and we could easily add all of these projects in 
>> this organization account as Thomas seems to be the only person attached to 
>> the account. We could then allow people to move projects to this account 
>> with the correct permission or restrictions as we see fit and allow other 
>> (TAC member?) to help manage the account.
>> 
>> It may cost some money at some point, but I have not looked into it more 
>> then a year.
>> 
>> 
>> 
>> Regards,
>> Keith
>> 
> 
> I was thinking more t

[dpdk-dev] GitHub repos for DPDK projects in one place.

[Wiles, Keith]

On Mar 15, 2018, at 12:43 PM, Wiles, Keith  wrote:
> 
> 
> 
>> On Mar 15, 2018, at 12:29 PM, Wiles, Keith  wrote:
>> 
>> I know that DPDK TAC and others are not wanting to have a lot of repos in 
>> DPDK.org for maintains reason and I agree.
>> 
>> I would like to see us use a single GitHub account to house these different 
>> projects as then we would have a much cleaner one stop shopping for DPDK 
>> related projects. We have the mirror for DPDK on GitHub 
>> https://github.com/DPDK and we could easily add all of these projects in 
>> this organization account as Thomas seems to be the only person attached to 
>> the account. We could then allow people to move projects to this account 
>> with the correct permission or restrictions as we see fit and allow other 
>> (TAC member?) to help manage the account.
>> 
>> It may cost some money at some point, but I have not looked into it more 
>> then a year.
> 
> Here is the different models for pricing: https://github.com/pricing
> 
> I would suggest Team account as it seems the cheapest as long as you have 
> public repos and not a lot of private repos is how I read it.
> 
> https://github.com/pricing/team
> 

Regards,
Keith

Re: [dpdk-dev] [PATCH v2 2/3] net/mlx5: fix link status behavior

[Yongseok Koh]

> On Mar 12, 2018, at 6:43 AM, Nelio Laranjeiro  
> wrote:
> 
> This behavior is mixed between what should be handled by the application
> and what is under PMD responsibility.
> 
> According to DPDK API:
> - link_update() should only query the link status [1]
> - link_set_{up,down}() should only set the link to the according status [1]
> - dev_{start,stop}() should enable/disable traffic reception/emission [2]
> 
> On this PMD, the link status is retrieved from the net device associated
> owned by the Linux Kernel, it does not means that even when this interface
> is down, the PMD cannot send/receive traffic from the NIC those two
> information are unrelated, until the physical port is active and has a
> link, the PMD can receive/send traffic on the wire.
> 
> According to DPDK API, calling the rte_eth_dev_start() even when the Linux
> interface link is down is then possible and allowed, as the traffic will
> flow between the DPDK application and the Physical port.
> 
> This also means that a synchronisation between the Linux interface and the
> DPDK application remains under the DPDK application responsibility.
> 
> To handle such synchronisation the application should behave as the
> following scheme, to start:
> 
> rte_eth_get_link(port_id, &link);
> if (link.link_status == ETH_DOWN)
>   rte_eth_dev_set_link_up(port_id);
> rte_eth_dev_start(port_id);
> 
> Taking in account the possible returned values fro each function.
> 
> and to stop:
> 
> rte_eth_dev_stop(port_id);
> rte_eth_dev_set_link_down(port_id);
> 
> The application should also set the LSC interrupt callbacks to catch and
> behave accordingly when the administrator set the Linux device down/up.
> The same callbacks are called when the link on the medium falls/raise.
> 
> Fixes: c7bf62255edf ("net/mlx5: fix handling link status event")
> Fixes: e313ef4c2fe8 ("net/mlx5: fix link state on device start")
> Cc: ys...@mellanox.com
> Cc: shah...@mellanox.com
> Cc: sta...@dpdk.org
> 
> [1] 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk%2Ftree%2Flib%2Flibrte_ether%2Frte_ethdev_core.h&data=02%7C01%7Cyskoh%40mellanox.com%7Cf3d27421af9541c0d74608d5881f67af%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636564590830553144&sdata=dn%2BQOq9IG2O4eYC7aSAMjvQ%2BT9rkVW%2BRo7t9RxLODTk%3D&reserved=0
> [2] 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk%2Ftree%2Flib%2Flibrte_ether%2Frte_ethdev.h%23n1677&data=02%7C01%7Cyskoh%40mellanox.com%7Cf3d27421af9541c0d74608d5881f67af%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636564590830553144&sdata=2zY%2F9gpIRcjz1mo4442u9uHTJPj5GVRftxHW8oVi6Ug%3D&reserved=0
> 
> Signed-off-by: Nelio Laranjeiro 
> Acked-by: Adrien Mazarguil 
> ---
Acked-by: Yongseok Koh 
 
Thanks

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Melik-Adamyan, Areg]

>It may cost some money at some point, but I have not looked into it more than 
>a year.
Our org can pay for the team account if needed, but free org account on Github 
has the same capabilities except for team permissions. 

Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

[Melik-Adamyan, Areg]

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Thursday, March 15, 2018 12:49 PM
To: Wiles, Keith 
Cc: Melik-Adamyan, Areg ; dev@dpdk.org; 
techbo...@dpdk.org; Yigit, Ferruh ; Richardson, Bruce 
; Ananyev, Konstantin 
; O'Driscoll, Tim 
Subject: Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK 
for Network Function Framework for Go

>I was thinking more that projects on DPDK should use similar software process.
>If you go to another location, you would use their Pull Request and review 
>model.
If there is a need then you can use both models: patch and PRs as several other 
projects do, e.g. Go itself, they use both Gerrit on googlesource.com and 
accept PRs on Github. 

Re: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 11:39 PM
> To: Zhang, Qi Z ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue setup
> 
> 
> 
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 3:09 PM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > setup
> >
> >
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Thursday, March 15, 2018 9:17 PM
> > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo 
> > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred queue
> > > setup
> > >
> > > Hi Qi,
> > >
> > > > -Original Message-
> > > > From: Zhang, Qi Z
> > > > Sent: Thursday, March 15, 2018 3:14 AM
> > > > To: Ananyev, Konstantin ;
> > > > tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > Jingjing ; Lu, Wenzhuo
> > > > 
> > > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred
> > > > queue setup
> > > >
> > > > Hi Konstantin:
> > > >
> > > > > -Original Message-
> > > > > From: Ananyev, Konstantin
> > > > > Sent: Wednesday, March 14, 2018 8:32 PM
> > > > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > > Jingjing ; Lu, Wenzhuo
> > > > > ; Zhang, Qi Z 
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 1/4] ether: support deferred
> > > > > queue setup
> > > > >
> > > > > Hi Qi,
> > > > >
> > > > > >
> > > > > > The patch let etherdev driver expose the capability flag
> > > > > > through rte_eth_dev_info_get when it support deferred queue
> > > > > > configuraiton, then base on the flag
> > > > > > rte_eth_[rx|tx]_queue_setup could decide continue to setup the
> > > > > > queue or just return fail when device already started.
> > > > > >
> > > > > > Signed-off-by: Qi Zhang 
> > > > > > ---
> > > > > >  doc/guides/nics/features.rst  |  8 
> > > > > > lib/librte_ether/rte_ethdev.c | 30
> > > > > > ++ lib/librte_ether/rte_ethdev.h |
> > > > > > 11 +++
> > > > > >  3 files changed, 37 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/doc/guides/nics/features.rst
> > > > > > b/doc/guides/nics/features.rst index 1b4fb979f..36ad21a1f
> > > > > > 100644
> > > > > > --- a/doc/guides/nics/features.rst
> > > > > > +++ b/doc/guides/nics/features.rst
> > > > > > @@ -892,7 +892,15 @@ Documentation describes performance
> > > values.
> > > > > >
> > > > > >  See ``dpdk.org/doc/perf/*``.
> > > > > >
> > > > > > +.. _nic_features_queue_deferred_setup_capabilities:
> > > > > >
> > > > > > +Queue deferred setup capabilities
> > > > > > +-
> > > > > > +
> > > > > > +Supports queue setup / release after device started.
> > > > > > +
> > > > > > +* **[provides] rte_eth_dev_info**:
> > > > > >
> > > > >
> > >
> ``deferred_queue_config_capa:DEV_DEFERRED_RX_QUEUE_SETUP,DEV_DEFE
> > > > > RRED_
> > > > > > TX_QUEUE_SETUP,DEV_DEFERRED_RX_QUEUE_RELE
> > > > > > ASE,DEV_DEFERRED_TX_QUEUE_RELEASE``.
> > > > > > +* **[related]  API**: ``rte_eth_dev_info_get()``.
> > > > > >
> > > > > >  .. _nic_features_other:
> > > > > >
> > > > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > > > b/lib/librte_ether/rte_ethdev.c index a6ce2a5ba..6c906c4df
> > > > > > 100644
> > > > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > > > @@ -1425,12 +1425,6 @@ rte_eth_rx_queue_setup(uint16_t
> > > > > > port_id,
> > > > > uint16_t rx_queue_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > -   if (dev->data->dev_started) {
> > > > > > -   RTE_PMD_DEBUG_TRACE(
> > > > > > -   "port %d must be stopped to allow configuration\n",
> > > port_id);
> > > > > > -   return -EBUSY;
> > > > > > -   }
> > > > > > -
> > > > > > RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get,
> > > > > -ENOTSUP);
> > > > > >
>   RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_setup,
> > > > > -ENOTSUP);
> > > > > >
> > > > > > @@ -1474,10 +1468,19 @@ rte_eth_rx_queue_setup(uint16_t
> > > port_id,
> > > > > uint16_t rx_queue_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > > >
> > > > > > +   if (dev->data->dev_started &&
> > > > > > +   !(dev_info.deferred_queue_config_capa &
> > > > > > +   DEV_DEFERRED_RX_QUEUE_SETUP))
> > > > > > +   return -EINVAL;
> > > > > > +
> > > > >
> > > > > I think now you have to check here that the queue is stopped.
> > > > > Otherwise you might attempt to reconfigure running queue.
> > > >
> > > > I'm not sure if it's necessary to let application use different
> >

Re: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue setup

[Zhang, Qi Z]

> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 11:22 PM
> To: Zhang, Qi Z ; tho...@monjalon.net
> Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> ; Lu, Wenzhuo 
> Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> setup
> 
> 
> 
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Thursday, March 15, 2018 2:30 PM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > ; Lu, Wenzhuo 
> > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred queue
> > setup
> >
> >
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Thursday, March 15, 2018 9:23 PM
> > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Xing, Beilei ; Wu, Jingjing
> > > ; Lu, Wenzhuo 
> > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > queue setup
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Zhang, Qi Z
> > > > Sent: Thursday, March 15, 2018 3:22 AM
> > > > To: Ananyev, Konstantin ;
> > > > tho...@monjalon.net
> > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > Jingjing ; Lu, Wenzhuo
> > > > 
> > > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > > queue setup
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Ananyev, Konstantin
> > > > > Sent: Wednesday, March 14, 2018 8:36 PM
> > > > > To: Zhang, Qi Z ; tho...@monjalon.net
> > > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > > Jingjing ; Lu, Wenzhuo
> > > > > ; Zhang, Qi Z 
> > > > > Subject: RE: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > > > queue setup
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> > > > > > Sent: Friday, March 2, 2018 4:13 AM
> > > > > > To: tho...@monjalon.net
> > > > > > Cc: dev@dpdk.org; Xing, Beilei ; Wu,
> > > > > > Jingjing ; Lu, Wenzhuo
> > > > > > ; Zhang,
> > > > > Qi
> > > > > > Z 
> > > > > > Subject: [dpdk-dev] [PATCH v2 4/4] net/i40e: enable deferred
> > > > > > queue setup
> > > > > >
> > > > > > Expose the deferred queue configuration capability and enhance
> > > > > > i40e_dev_[rx|tx]_queue_[setup|release] to handle the situation
> > > > > > when device already started.
> > > > > >
> > > > > > Signed-off-by: Qi Zhang 
> > > > > > ---
> > > > > >  drivers/net/i40e/i40e_ethdev.c |  6 
> > > > > >  drivers/net/i40e/i40e_rxtx.c   | 62
> > > > > --
> > > > > >  2 files changed, 66 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > > > > b/drivers/net/i40e/i40e_ethdev.c index 06b0f03a1..843a0c42a
> > > > > > 100644
> > > > > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > > > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > > > > @@ -3195,6 +3195,12 @@ i40e_dev_info_get(struct rte_eth_dev
> > > *dev,
> > > > > struct rte_eth_dev_info *dev_info)
> > > > > > DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > > > > > DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > > > > > DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> > > > > > +   dev_info->deferred_queue_config_capa =
> > > > > > +   DEV_DEFERRED_RX_QUEUE_SETUP |
> > > > > > +   DEV_DEFERRED_TX_QUEUE_SETUP |
> > > > > > +   DEV_DEFERRED_RX_QUEUE_RELEASE |
> > > > > > +   DEV_DEFERRED_TX_QUEUE_RELEASE;
> > > > > > +
> > > > > > dev_info->hash_key_size = (I40E_PFQF_HKEY_MAX_INDEX +
> 1) *
> > > > > > sizeof(uint32_t);
> > > > > > dev_info->reta_size = pf->hash_lut_size; diff --git
> > > > > > a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > > > > > index
> > > > > > 1217e5a61..e5f532cf7 100644
> > > > > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > > > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > > > > @@ -1712,6 +1712,7 @@ i40e_dev_rx_queue_setup(struct
> > > rte_eth_dev
> > > > > *dev,
> > > > > > uint16_t len, i;
> > > > > > uint16_t reg_idx, base, bsf, tc_mapping;
> > > > > > int q_offset, use_def_burst_func = 1;
> > > > > > +   int ret = 0;
> > > > > >
> > > > > > if (hw->mac.type == I40E_MAC_VF || hw->mac.type ==
> > > > > I40E_MAC_X722_VF) {
> > > > > > vf =
> I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > > > > > @@ -1841,6 +1842,25 @@ i40e_dev_rx_queue_setup(struct
> > > rte_eth_dev
> > > > > *dev,
> > > > > > rxq->dcb_tc = i;
> > > > > > }
> > > > > >
> > > > > > +   if (dev->data->dev_started) {
> > > > > > +   ret = i40e_rx_queue_init(rxq);
> > > > > > +   if (ret != I40E_SUCCESS) {
> > > > > > +   PMD_DRV_LOG(ERR,
> > > > > > +   "Failed to do RX queue 
> > > > > > initialization");
> > > > > > +   return ret;
> > > > > > +   }
> > > > > > +   if (ad->rx_vec_allowed)
> > > > >
> > > > > Bette

Re: [dpdk-dev] [PATCH 2/2] test: update common auto test

[Thomas Monjalon]

14/03/2018 10:41, Pavan Nikhilesh:
> Update common auto test to include test for aligning values to multiples
> of given integer.
> 
> Signed-off-by: Pavan Nikhilesh 
> ---
>  test/test/test_common.c | 12 
>  1 file changed, 12 insertions(+)

The unit test can be in the same patch as the code.
A single patch is fine here.

Re: [dpdk-dev] [RFC v4 1/1] lib/compressdev: Adding hash support

[Verma, Shally]

Hi Fiona 

Thanks for feedback. 
Comments inline. 


>-Original Message-
>From: Trahe, Fiona [mailto:fiona.tr...@intel.com]
>Sent: 14 March 2018 18:12
>To: Verma, Shally 
>Cc: Athreya, Narayana Prasad ; Challa, 
>Mahipal ; Gupta,
>Ashish ; dev@dpdk.org; ahmed.mans...@nxp.com; Trahe, 
>Fiona ; De Lara
>Guarch, Pablo ; Jain, Deepak K 
>
>Subject: RE: [RFC v4 1/1] lib/compressdev: Adding hash support
>
>Hi Shally,
>
>Sorry about the delay in responding. Comments below.
>If you want to push next update to github we can continue dev there.
>Regards,
>Fiona
>
>
>> -Original Message-
>> From: Shally Verma [mailto:shally.ve...@caviumnetworks.com]
>> Sent: Thursday, February 1, 2018 11:07 AM
>> To: Trahe, Fiona 
>> Cc: pathr...@caviumnetworks.com; mcha...@caviumnetworks.com; 
>> agu...@caviumnetworks.com;
>> dev@dpdk.org; ahmed.mans...@nxp.com
>> Subject: [RFC v4 1/1] lib/compressdev: Adding hash support
>>
>> Added hash support in lib compressdev. It's an incremental patch to
>> compression lib RFC v3 https://dpdk.org/dev/patchwork/patch/32331/
>>
>> Changes from RFC v3:
>> - Added hash algo enumeration and associated capability stucture
>>   and params in xform and rte_comp_op
>> - Rearranged rte_compresdev_capability structure to have
>>   separate rte_comp_algo_capability and moved
>>   algo specific capabilities: window_size, dictionary support,
>>   and hash as part of it
>> - Added RTE_COMP_UNSPECIFIED=0 in enum rte_comp_algorithm
>> - Redefined RTE_COMP_END_OF_CAPABILITIES_LIST to use RTE_COMP_UNSPECIFIED
>>   to resolve missing-field-initializer compiler warning
>> - Updated compress/decompress xform to input hash algorithm
>>   during session init
>> - Updated struct rte_comp_op to input hash buffer
>> - Fixed checkpatch reported errors on RFCv3
>>
>> Every compression algorithm can indicate its capability to
>> perform alongside hash in its associate rte_comp_algo_capa structure.
>> If none is supported, can terminate array with
>> hash_algo = RTE_COMP_HASH_ALGO_UNSPECIFIED.
>> if supported, application can initialize session with desired
>> algorithm enumeration in xform structure and pass valid hash buffer
>> pointer during enqueue_burst().
>>
>> Signed-off-by: Shally Verma 
>> ---
>>  lib/librte_compressdev/rte_comp.h  | 83 
>> +-
>>  lib/librte_compressdev/rte_compressdev.c   | 19 +
>>  lib/librte_compressdev/rte_compressdev.h   | 59 ---
>>  lib/librte_compressdev/rte_compressdev_version.map |  1 +
>>  4 files changed, 137 insertions(+), 25 deletions(-)
>>
>> diff --git a/lib/librte_compressdev/rte_comp.h 
>> b/lib/librte_compressdev/rte_comp.h
>> index ca8cbb4..341f59f 100644
>> --- a/lib/librte_compressdev/rte_comp.h
>> +++ b/lib/librte_compressdev/rte_comp.h
>> @@ -75,10 +75,11 @@ enum rte_comp_op_status {
>>   */
>>  };
>>
>> -
>>  /** Compression Algorithms */
>>  enum rte_comp_algorithm {
>> -RTE_COMP_NULL = 0,
>> +RTE_COMP_UNSPECIFIED = 0,
>> +/** No Compression algo */
>> +RTE_COMP_NULL,
>>  /**< No compression.
>>   * Pass-through, data is copied unchanged from source buffer to
>>   * destination buffer.
>> @@ -94,6 +95,18 @@ enum rte_comp_algorithm {
>>  RTE_COMP_ALGO_LIST_END
>>  };
>>
>> +
>> +/** Compression hash algorithms */
>> +enum rte_comp_hash_algorithm {
>> +RTE_COMP_HASH_ALGO_UNSPECIFIED = 0,
>> +/**< No hash */
>> +RTE_COMP_HASH_ALGO_SHA1,
>> +/**< SHA1 hash algorithm */
>> +RTE_COMP_HASH_ALGO_SHA256,
>> +/**< SHA256 hash algorithm */
>> +RTE_COMP_HASH_ALGO_LIST_END,
>> +};
>> +
>>  /**< Compression Level.
>>   * The number is interpreted by each PMD differently. However, lower numbers
>>   * give fastest compression, at the expense of compression ratio while
>> @@ -154,21 +167,24 @@ enum rte_comp_flush_flag {
>>  RTE_COMP_FLUSH_SYNC,
>>  /**< All data should be flushed to output buffer. Output data can be
>>   * decompressed. However state and history is not cleared, so future
>> - * ops may use history from this op */
>> + * ops may use history from this op
>> + */
>>  RTE_COMP_FLUSH_FULL,
>>  /**< All data should be flushed to output buffer. Output data can be
>>   * decompressed. State and history data is cleared, so future
>>   * ops will be independent of ops processed before this.
>>   */
>>  RTE_COMP_FLUSH_FINAL
>> -/**< Same as RTE_COMP_FLUSH_FULL but also bfinal bit is set in last 
>> block
>> +/**< Same as RTE_COMP_FLUSH_FULL but also bfinal bit is set in
>> + * last block
>>   */
>>   /* TODO:
>>* describe flag meanings for decompression.
>>* describe behavous in OUT_OF_SPACE case.
>>* At least the last flag is specific to deflate algo. Should this be
>>* called rte_comp_deflate_flush_flag? And should there be
>> -  * comp_op_deflate_params in the op? */
>> +  * comp_op_deflate_params in the op?
>> +  */
>>  };

Re: [dpdk-dev] [PATCH v2] drivers/net/i40e/i40e_ethdev_vf.c: fix missing promiscuous disable at device stop

[Zhang, Qi Z]

Hi Rosen:

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Rosen Xu
> Sent: Thursday, March 15, 2018 5:46 PM
> To: Xing, Beilei 
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] drivers/net/i40e/i40e_ethdev_vf.c: fix
> missing promiscuous disable at device stop
> 
> In scenario of Kernel Driver runs on PF and PMD runs on VF, PMD exit doesn't
> disable promiscuous mode, this will cause vlan filter set by Kernel Driver 
> will
> not take effect.
> 
> This patch will fix it, add promiscuous disable at device stop.
> 
> Signed-off-by: Rosen Xu 
> ---
>  drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index fd003fe..f395b02 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -2051,6 +2051,8 @@ static int eth_i40evf_pci_remove(struct
> rte_pci_device *pci_dev)
> 
>   if (hw->adapter_stopped == 1)
>   return;
> + i40evf_dev_promiscuous_disable(dev);
> + i40evf_dev_allmulticast_disable(dev);

Device's promiscuous mode is not expected to be changed in a dev_start/dev_stop 
cycle
Application need to call rte_eth_promiscuous_disable and 
i40evf_dev_allmulticast_disable to change it explicitly.

Regards
Qi

>   i40evf_stop_queues(dev);
>   i40evf_disable_queues_intr(dev);
>   i40e_dev_clear_queues(dev);
> --
> 1.8.3.1