[dpdk-dev] [dpdk-announce] DPDK PRC Summit Registration is open and reminder the CFP deadline(May 1st)

2018-05-01 Thread Xu, Qian Q
Dear all
Thanks to Linux Foundation's work, now DPDK registration is open. You can go to 
http://dpdk.org/events and see there are two options. One is to register 
LinuxCon + DPDK, and the other is to register DPDK only. You can register 
depends on your preference. And DPDK PRC Summit registration is free. Btw, a 
soft reminder of CFP deadline -- May 1st, and please submit your proposal 
before the time, thank you very much.



Re: [dpdk-dev] pthread_barrier_deadlock in -rc1 (was: "Re: [PATCH v3 0/5] fix control thread affinities")

2018-05-01 Thread Thomas Monjalon
30/04/2018 20:46, Olivier Matz:
> Le 30 avril 2018 17:45:52 GMT+02:00, Maxime Coquelin 
>  a écrit :
> >I face a deadlock issue with your series, that Jianfeng patch does not
> >resolve ("eal: fix threads block on barrier"). Reverting the series and
> >Jianfeng patch makes the issue to disappear.
[...]
> >I don't have more info for now.
> 
> Thanks for the feedback on this issue. I don't see obvious reason for this 
> deadlock yet.
> 
> I'll investigate it asap (not tomorrow, but wednesday). In the worst case, we 
> can revert the series if I cannot find the root cause rapidly.

Guys, thanks for working on it.

There are so many big bugs in RC1 that we need to have an early RC2
today or tomorrow.

Maybe someone else, working today, can investigate?




Re: [dpdk-dev] [PATCH 2/7 v3] bus/fslmc: expose API to free dpci device

2018-05-01 Thread Shreyansh Jain

On Thursday 26 April 2018 03:44 PM, Nipun Gupta wrote:

Signed-off-by: Nipun Gupta 
---
  drivers/bus/fslmc/rte_bus_fslmc_version.map | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/bus/fslmc/rte_bus_fslmc_version.map 
b/drivers/bus/fslmc/rte_bus_fslmc_version.map
index 70fb719..d433714 100644
--- a/drivers/bus/fslmc/rte_bus_fslmc_version.map
+++ b/drivers/bus/fslmc/rte_bus_fslmc_version.map
@@ -114,5 +114,6 @@ DPDK_18.05 {
dpdmai_open;
dpdmai_set_rx_queue;
dpdmai_set_tx_queue;
+   rte_dpaa2_free_dpci_dev;
  
  } DPDK_18.02;




Acked-by: Shreyansh Jain 


Re: [dpdk-dev] [PATCH 0/7 v3] Introduce DPAA2 Command Interface raw driver

2018-05-01 Thread Shreyansh Jain

On Thursday 26 April 2018 03:44 PM, Nipun Gupta wrote:

This patch set introduces DPAA2 based Command Interface
device driver.

This driver is provides communication between the GPP and
AIOP Firmware.

This patchset is based on top of:
https://dpdk.org/dev/patchwork/patch/38798/

Patches 1-3:
   Makes necessary changes and fixes in the DPAA2 bus and
   mempool region
Patches 4-6:
   Add the DPAA2 CMDIF driver
Patches 7:
   Update the respective documentation

Changes in v2:
   - Move CMDIF compilation to common_linuxapp
   - Support physical addressing mode

Changes in v3:
   - Rebased over DPAA2 QDMA patches
   - Updated logging adding Data Path logs too
   - Fix up error handling in patch 3
   - Merged the two separate doc patches (patch 7)

Nipun Gupta (7):
   mempool/dpaa2: add functions exposed to DPDK applications
   bus/fslmc: expose API to free dpci device
   bus/fslmc: keep Tx queues information for DPCI devices too
   raw/dpaa2_cmdif: introduce DPAA2 command interface driver
   raw/dpaa2_cmdif: add attribute get functionality
   raw/dpaa2_cmdif: support enqueue dequeue operations
   doc: add DPAA2 CMDIF rawdev guide



Nipun,

Can you push the series again with meson support?

Regards,
Shreyansh



Re: [dpdk-dev] [PATCH 2/3] net/ixgbe: initialise nb_representor_ports value

2018-05-01 Thread Ananyev, Konstantin


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
> Sent: Monday, April 30, 2018 4:33 PM
> To: dev@dpdk.org
> Cc: Doherty, Declan 
> Subject: [dpdk-dev] [PATCH 2/3] net/ixgbe: initialise nb_representor_ports 
> value
> 
> Initialise rte_ethdev_args nb_representor_ports to zero to handle
> the case where no devargs are passed to the IXGBE PF on
> device probe, so that there is no invalid attempts to create
> representor ports.
> 
> Coverity Issue: 277231
> Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")
> 
> Signed-off-by: Declan Doherty 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 0ccf55dc8..283dd7e49 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1725,8 +1725,7 @@ eth_ixgbe_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   struct rte_pci_device *pci_dev)
>  {
>   char name[RTE_ETH_NAME_MAX_LEN];
> -
> - struct rte_eth_devargs eth_da;
> + struct rte_eth_devargs eth_da = { .nb_representor_ports = 0 };
>   int i, retval;
> 
>   if (pci_dev->device.devargs) {

Might be a bit better:
If (pci_dev->device.devargs) { rte_eth_devargs_parse(...);...}
else memset(ð_da, 0, sizeof(eth_da));
to be more consistent.
BTW, I think rte_eth_devargs_parse() need to add formal check for input 
parameters.
Konstantin 



> --
> 2.14.3



Re: [dpdk-dev] [PATCH 3/3] net/ixgbe: add null pointer check for pf_ethdev

2018-05-01 Thread Ananyev, Konstantin


> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
> Sent: Monday, April 30, 2018 4:33 PM
> To: dev@dpdk.org
> Cc: Doherty, Declan 
> Subject: [dpdk-dev] [PATCH 3/3] net/ixgbe: add null pointer check for 
> pf_ethdev
> 
> Add NULL parameter check for rte_eth_dev_allocated() API call to
> eth_ixgbe_pci_probe().
> 
> Coverity Issue: 277216
> Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")
> 
> Signed-off-by: Declan Doherty 
> ---
>  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 283dd7e49..75f927c06 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1747,6 +1747,9 @@ eth_ixgbe_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   struct rte_eth_dev *pf_ethdev = rte_eth_dev_allocated(
>   pci_dev->device.name);
> 
> + if (pf_ethdev == NULL)
> + return -ENODEV;
> +
>   for (i = 0; i < eth_da.nb_representor_ports; i++) {
>   struct ixgbe_vf_info *vfinfo;
>   struct ixgbe_vf_representor representor;
> --

Looks good - can I just ask to move pf_ethdev definition to the top of the 
function?
To comply with dpdk coding style.
Konstantin

> 2.14.3



[dpdk-dev] [dpdk-announce] SPDK summit - Don't miss the chance to register and learn more about SPDK!!!!!

2018-05-01 Thread Rao, Anu H

Interested in learning more about SPDK? Want to learn how it can help 
accelerate your storage solutions? Attend the SPDK summit and discover the SPDK 
experience. SPDK is based off of DPDK and implements User space, lockless, 
polled-mode libraries to accelerate storage solution. It helps minimize average 
and tail latencies and helps extracts millions of IOPS per core. Its 
specifically designed for non-volatile media and like DPDK its open source and 
BSD licensed. For more info, please visit http://SPDK.io

New to SPDK? No worries, we have various sessions on the agenda that introduce 
you to the project. There is also a hands on lab where you learn as you code.
Already an avid SPDK developer or user? Great! Participate in our developer's 
meetup to brainstorm and share ideas to improve the project as well as discuss 
new features, concepts and BKMs.

The event kicks off with a key note from the Intel(r) Corporation Data Center 
Group Vice President, Jennifer Huffstetler. The agenda continues with an 
awesome line up which includes talks from various SPDK community members 
(Alibaba, eBay, Oracle, Cisco, Nutanix) who are eager to share their 
experience, learning, challenges and benefits with SPDK. SPDK developers will 
present new content on various SPDK features highlighting their use cases and 
benefits. You will also get to see SPDK in action with live demos and the 
hands-on lab. For more info on the SPDK Project please visit http://SPDK.io

The registration link is live for 2018 Annual Storage Performance Development 
Kit US Summit.  Please use the link below to complete the registration and 
hotel room booking. Summit details and agenda are in the link below.
http://www.cvent.com/d/qgqnn3

If you are planning to fly in to attend SPDK summit, please register soon as we 
have limited rooms blocked for the event. To guarantee room availability please 
register before May 2nd   and the deadline to register to attend for the event 
is May 8th.

Registration for the event is free


Thanks
Anu Rao
Software Product Line Manager
Data Center Group, Intel Corporation



[dpdk-dev] [PATCH v2 2/2] net/mlx5: add Rx and Tx tuning parameters

2018-05-01 Thread Shahaf Shuler
A new ethdev API was exposed by
commit 3be82f5cc5e3 ("ethdev: support PMD-tuned Tx/Rx parameters")

Enabling the PMD to provide default parameters in case no strict request
from application in order to improve the out of the box experience.

While the current API lacks the means for the PMD to provide the best
possible value, providing the best default the PMD can guess.
The values are based on Mellanox performance report and depends on the
underlying NIC capabilities.

Cc: ere...@mellanox.com
Cc: am...@mellanox.com
Cc: ol...@mellanox.com

Signed-off-by: Shahaf Shuler 
---

On v2:
 - refactor the code to ease the maintenance.

---
 drivers/net/mlx5/mlx5_ethdev.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 588d4ba627..3fad199a60 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -417,6 +417,45 @@ mlx5_dev_configure(struct rte_eth_dev *dev)
 }
 
 /**
+ * Sets default tuning parameters.
+ *
+ * @param dev
+ *   Pointer to Ethernet device.
+ * @param[out] info
+ *   Info structure output buffer.
+ */
+static void
+mlx5_set_default_params(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
+{
+   struct priv *priv = dev->data->dev_private;
+
+   /* Minimum CPU utilization. */
+   info->default_rxportconf.ring_size = 256;
+   info->default_txportconf.ring_size = 256;
+   info->default_rxportconf.burst_size = 64;
+   info->default_txportconf.burst_size = 64;
+   if (priv->link_speed_capa & ETH_LINK_SPEED_100G) {
+   info->default_rxportconf.nb_queues = 16;
+   info->default_txportconf.nb_queues = 16;
+   if (dev->data->nb_rx_queues > 2 ||
+   dev->data->nb_tx_queues > 2) {
+   /* Max Throughput. */
+   info->default_rxportconf.ring_size = 2048;
+   info->default_txportconf.ring_size = 2048;
+   }
+   } else {
+   info->default_rxportconf.nb_queues = 8;
+   info->default_txportconf.nb_queues = 8;
+   if (dev->data->nb_rx_queues > 2 ||
+   dev->data->nb_tx_queues > 2) {
+   /* Max Throughput. */
+   info->default_rxportconf.ring_size = 4096;
+   info->default_txportconf.ring_size = 4096;
+   }
+   }
+}
+
+/**
  * DPDK callback to get information about the device.
  *
  * @param dev
@@ -458,6 +497,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *info)
info->hash_key_size = rss_hash_default_key_len;
info->speed_capa = priv->link_speed_capa;
info->flow_type_rss_offloads = ~MLX5_RSS_HF_MASK;
+   mlx5_set_default_params(dev, info);
 }
 
 /**
-- 
2.12.0



[dpdk-dev] [PATCH v5 0/8] Introduce DPAA2 QDMA raw driver

2018-05-01 Thread Nipun Gupta
This patch set introduces DPAA2 based QDMA device driver.

It provide means to initiate a DMA transaction from CPU.
The initiated DMA is performed without CPU being involved
in the actual DMA transaction.

This patch series is rebased on dpdk master branch

Patch 1:
  Support meson build in raw
Patches 2-4:
  Makes necessary changes in the DPAA2 bus
Patches 5-7:
  Add the DPAA2 QDMA driver
Patch 8:
  Update the documentation

Changes in v2:
  - Rebased over master branch
  - Pulled in couple of changes which were in CMDIF series
- patch 3: some updations, patch 4
  - handle failues in device init correctly
  - Updated the logging, added DP logs
  - Fixed remove_hw_queues_from_list function

Changes in v3:
  - Fix compilation issue introduced due to a very recent change
of removal of dma_addr_t. Fix in patch 7 where dma_addr_t
was used.

Changes in v4:
  - Support meson build for raw and dpaa2 qdma (patch 1 & 5)
  - Merged the two separate doc patches (patch 8)

Changes in v5:
  - install user header file (rte_pmd_dpaa2_qdma.h) in case of
meson build where it is introduced (patch 6). Previously
it was added in patch 5.

Nipun Gupta (8):
  raw: support meson build
  bus/fslmc: support MC DPDMAI object
  bus/fslmc: support scanning and probing of QDMA devices
  bus/fslmc: add macros required by QDMA for FLE and FD
  raw/dpaa2_qdma: introduce the DPAA2 QDMA driver
  raw/dpaa2_qdma: support configuration APIs
  raw/dpaa2_qdma: support enq and deq operations
  doc: add DPAA2 QDMA rawdev guide

 MAINTAINERS|9 +
 config/common_base |5 +
 config/common_linuxapp |1 +
 doc/api/doxy-api-index.md  |1 +
 doc/api/doxy-api.conf  |1 +
 doc/guides/index.rst   |1 +
 doc/guides/rawdevs/dpaa2_qdma.rst  |  140 +++
 doc/guides/rawdevs/index.rst   |   14 +
 doc/guides/rel_notes/release_18_05.rst |8 +
 drivers/bus/fslmc/Makefile |9 +-
 drivers/bus/fslmc/fslmc_bus.c  |2 +
 drivers/bus/fslmc/fslmc_vfio.c |1 +
 drivers/bus/fslmc/mc/dpdmai.c  |  429 +
 drivers/bus/fslmc/mc/fsl_dpdmai.h  |  189 
 drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h  |  107 +++
 drivers/bus/fslmc/meson.build  |1 +
 drivers/bus/fslmc/portal/dpaa2_hw_pvt.h|8 +-
 drivers/bus/fslmc/rte_bus_fslmc_version.map|9 +
 drivers/bus/fslmc/rte_fslmc.h  |2 +
 drivers/meson.build|3 +-
 drivers/raw/Makefile   |3 +
 drivers/raw/dpaa2_qdma/Makefile|   36 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma.c| 1002 
 drivers/raw/dpaa2_qdma/dpaa2_qdma.h|  150 +++
 drivers/raw/dpaa2_qdma/dpaa2_qdma_logs.h   |   46 +
 drivers/raw/dpaa2_qdma/meson.build |9 +
 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h|  286 ++
 .../raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map  |   20 +
 drivers/raw/meson.build|7 +
 drivers/raw/skeleton_rawdev/meson.build|8 +
 mk/rte.app.mk  |3 +
 31 files changed, 2504 insertions(+), 6 deletions(-)
 create mode 100644 doc/guides/rawdevs/dpaa2_qdma.rst
 create mode 100644 doc/guides/rawdevs/index.rst
 create mode 100644 drivers/bus/fslmc/mc/dpdmai.c
 create mode 100644 drivers/bus/fslmc/mc/fsl_dpdmai.h
 create mode 100644 drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h
 create mode 100644 drivers/raw/dpaa2_qdma/Makefile
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma.c
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma.h
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma_logs.h
 create mode 100644 drivers/raw/dpaa2_qdma/meson.build
 create mode 100644 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h
 create mode 100644 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map
 create mode 100644 drivers/raw/meson.build
 create mode 100644 drivers/raw/skeleton_rawdev/meson.build

-- 
1.9.1



[dpdk-dev] [PATCH v2 1/2] net/mlx5: fix ethtool link setting call order

2018-05-01 Thread Shahaf Shuler
According to ethtool_link_setting API recommendation ETHTOOL_GLINKSETTINGS
should be called before ETHTOOL_GSET as the later one deprecated.

Fixes: f47ba80080ab ("net/mlx5: remove kernel version check")

Signed-off-by: Shahaf Shuler 
Acked-by: Nelio Laranjeiro 
---
On v2:
 - no change.

--
 drivers/net/mlx5/mlx5_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 746b94f734..588d4ba627 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -697,9 +697,9 @@ mlx5_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
time_t start_time = time(NULL);
 
do {
-   ret = mlx5_link_update_unlocked_gset(dev, &dev_link);
+   ret = mlx5_link_update_unlocked_gs(dev, &dev_link);
if (ret)
-   ret = mlx5_link_update_unlocked_gs(dev, &dev_link);
+   ret = mlx5_link_update_unlocked_gset(dev, &dev_link);
if (ret == 0)
break;
/* Handle wait to complete situation. */
-- 
2.12.0



[dpdk-dev] [PATCH v5 1/8] raw: support meson build

2018-05-01 Thread Nipun Gupta
Signed-off-by: Shreyansh Jain 
Signed-off-by: Nipun Gupta 
---
 drivers/meson.build | 3 ++-
 drivers/raw/meson.build | 7 +++
 drivers/raw/skeleton_rawdev/meson.build | 8 
 3 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 drivers/raw/meson.build
 create mode 100644 drivers/raw/skeleton_rawdev/meson.build

diff --git a/drivers/meson.build b/drivers/meson.build
index b146f09..f879cb6 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -7,7 +7,8 @@ driver_classes = ['common',
   'mempool', # depends on common and bus.
   'net', # depends on common, bus and mempool.
   'crypto',  # depends on common, bus and mempool (net in future).
-  'event']   # depends on common, bus, mempool and net.
+  'event',   # depends on common, bus, mempool and net.
+  'raw'] # depends on common, bus, mempool, net and event.
 
 foreach class:driver_classes
drivers = []
diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build
new file mode 100644
index 000..24c82ff
--- /dev/null
+++ b/drivers/raw/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2018 NXP
+
+drivers = ['skeleton_rawdev']
+std_deps = ['rawdev']
+config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
+driver_name_fmt = 'rte_pmd_@0@'
diff --git a/drivers/raw/skeleton_rawdev/meson.build 
b/drivers/raw/skeleton_rawdev/meson.build
new file mode 100644
index 000..7cb2d3f
--- /dev/null
+++ b/drivers/raw/skeleton_rawdev/meson.build
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2018 NXP
+
+deps += ['rawdev', 'kvargs', 'mbuf', 'bus_vdev']
+sources = files('skeleton_rawdev.c',
+   'skeleton_rawdev_test.c')
+
+allow_experimental_apis = true
-- 
1.9.1



[dpdk-dev] [PATCH v5 2/8] bus/fslmc: support MC DPDMAI object

2018-05-01 Thread Nipun Gupta
This patch adds the DPDMAI (Data Path DMA Interface)
object support in MC driver.

Signed-off-by: Cristian Sovaiala 
Signed-off-by: Nipun Gupta 
Acked-by: Shreyansh Jain 
---
 drivers/bus/fslmc/Makefile  |   9 +-
 drivers/bus/fslmc/mc/dpdmai.c   | 429 
 drivers/bus/fslmc/mc/fsl_dpdmai.h   | 189 
 drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h   | 107 +++
 drivers/bus/fslmc/meson.build   |   1 +
 drivers/bus/fslmc/rte_bus_fslmc_version.map |   9 +
 6 files changed, 740 insertions(+), 4 deletions(-)
 create mode 100644 drivers/bus/fslmc/mc/dpdmai.c
 create mode 100644 drivers/bus/fslmc/mc/fsl_dpdmai.h
 create mode 100644 drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h

diff --git a/drivers/bus/fslmc/Makefile b/drivers/bus/fslmc/Makefile
index 3aa34e2..515d0f5 100644
--- a/drivers/bus/fslmc/Makefile
+++ b/drivers/bus/fslmc/Makefile
@@ -32,11 +32,12 @@ SRCS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += \
 
 SRCS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += \
mc/dpmng.c \
-mc/dpbp.c \
-mc/dpio.c \
-mc/mc_sys.c \
+   mc/dpbp.c \
+   mc/dpio.c \
+   mc/mc_sys.c \
mc/dpcon.c \
-   mc/dpci.c
+   mc/dpci.c \
+   mc/dpdmai.c
 
 SRCS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += portal/dpaa2_hw_dpio.c
 SRCS-$(CONFIG_RTE_LIBRTE_FSLMC_BUS) += portal/dpaa2_hw_dpbp.c
diff --git a/drivers/bus/fslmc/mc/dpdmai.c b/drivers/bus/fslmc/mc/dpdmai.c
new file mode 100644
index 000..528889d
--- /dev/null
+++ b/drivers/bus/fslmc/mc/dpdmai.c
@@ -0,0 +1,429 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * dpdmai_open() - Open a control session for the specified object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpdmai_id: DPDMAI unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpdmai_create() function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpdmai_open(struct fsl_mc_io *mc_io,
+   uint32_t cmd_flags,
+   int dpdmai_id,
+   uint16_t *token)
+{
+   struct dpdmai_cmd_open *cmd_params;
+   struct mc_command cmd = { 0 };
+   int err;
+
+   /* prepare command */
+   cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_OPEN,
+ cmd_flags,
+ 0);
+   cmd_params = (struct dpdmai_cmd_open *)cmd.params;
+   cmd_params->dpdmai_id = cpu_to_le32(dpdmai_id);
+
+   /* send command to mc*/
+   err = mc_send_command(mc_io, &cmd);
+   if (err)
+   return err;
+
+   /* retrieve response parameters */
+   *token = mc_cmd_hdr_read_token(&cmd);
+
+   return 0;
+}
+
+/**
+ * dpdmai_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPDMAI object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpdmai_close(struct fsl_mc_io *mc_io,
+uint32_t cmd_flags,
+uint16_t token)
+{
+   struct mc_command cmd = { 0 };
+
+   /* prepare command */
+   cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_CLOSE,
+ cmd_flags, token);
+
+   /* send command to mc*/
+   return mc_send_command(mc_io, &cmd);
+}
+
+/**
+ * dpdmai_create() - Create the DPDMAI object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @dprc_token:Parent container token; '0' for default container
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @cfg:   Configuration structure
+ * @obj_id:Returned object id
+ *
+ * Create the DPDMAI object, allocate required resources and
+ * perform required initialization.
+ *
+ * The object can be created either by declaring it in the
+ * DPL file, or by calling this function.
+ *
+ * The function accepts an authentication token of a parent
+ * container that this object should be assigned to. The token
+ * can be '0' so the object will be assigned to the default container.
+ * The newly created object can be opened with the returned
+ * object id and using the container's associated tokens and MC portals.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpdmai_create(struct fsl_mc_io *mc_io,
+

[dpdk-dev] [PATCH v5 3/8] bus/fslmc: support scanning and probing of QDMA devices

2018-05-01 Thread Nipun Gupta
'dpdmai' devices detected on fsl-mc bus are represented by DPAA2 QDMA
devices in DPDK.

Signed-off-by: Nipun Gupta 
Acked-by: Shreyansh Jain 
---
 drivers/bus/fslmc/fslmc_bus.c  | 2 ++
 drivers/bus/fslmc/fslmc_vfio.c | 1 +
 drivers/bus/fslmc/rte_fslmc.h  | 2 ++
 3 files changed, 5 insertions(+)

diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
index 943c01b..fde5f19 100644
--- a/drivers/bus/fslmc/fslmc_bus.c
+++ b/drivers/bus/fslmc/fslmc_bus.c
@@ -164,6 +164,8 @@
dev->dev_type = DPAA2_CI;
else if (!strncmp("dpmcp", t_ptr, 5))
dev->dev_type = DPAA2_MPORTAL;
+   else if (!strncmp("dpdmai", t_ptr, 6))
+   dev->dev_type = DPAA2_QDMA;
else
dev->dev_type = DPAA2_UNKNOWN;
 
diff --git a/drivers/bus/fslmc/fslmc_vfio.c b/drivers/bus/fslmc/fslmc_vfio.c
index 749d92d..3800c26 100644
--- a/drivers/bus/fslmc/fslmc_vfio.c
+++ b/drivers/bus/fslmc/fslmc_vfio.c
@@ -661,6 +661,7 @@ int rte_dpaa2_intr_disable(struct rte_intr_handle 
*intr_handle, int index)
switch (dev->dev_type) {
case DPAA2_ETH:
case DPAA2_CRYPTO:
+   case DPAA2_QDMA:
ret = fslmc_process_iodevices(dev);
if (ret) {
DPAA2_BUS_DEBUG("Dev (%s) init failed",
diff --git a/drivers/bus/fslmc/rte_fslmc.h b/drivers/bus/fslmc/rte_fslmc.h
index 69d0fec..7b34368 100644
--- a/drivers/bus/fslmc/rte_fslmc.h
+++ b/drivers/bus/fslmc/rte_fslmc.h
@@ -61,6 +61,7 @@ enum rte_dpaa2_dev_type {
DPAA2_IO,   /**< DPIO type device */
DPAA2_CI,   /**< DPCI type device */
DPAA2_MPORTAL,  /**< DPMCP type device */
+   DPAA2_QDMA, /**< DPDMAI type device */
/* Unknown device placeholder */
DPAA2_UNKNOWN,
DPAA2_DEVTYPE_MAX,
@@ -91,6 +92,7 @@ struct rte_dpaa2_device {
union {
struct rte_eth_dev *eth_dev;/**< ethernet device */
struct rte_cryptodev *cryptodev;/**< Crypto Device */
+   struct rte_rawdev *rawdev;  /**< Raw Device */
};
enum rte_dpaa2_dev_type dev_type;   /**< Device Type */
uint16_t object_id; /**< DPAA2 Object ID */
-- 
1.9.1



[dpdk-dev] [PATCH v5 5/8] raw/dpaa2_qdma: introduce the DPAA2 QDMA driver

2018-05-01 Thread Nipun Gupta
DPAA2 QDMA driver uses MC DPDMAI object. This driver enables
the user (app) to perform data DMA without involving CPU in
the DMA process

Signed-off-by: Nipun Gupta 
---
 MAINTAINERS|   8 +
 config/common_base |   5 +
 config/common_linuxapp |   1 +
 drivers/raw/Makefile   |   3 +
 drivers/raw/dpaa2_qdma/Makefile|  34 +++
 drivers/raw/dpaa2_qdma/dpaa2_qdma.c| 294 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma.h|  66 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma_logs.h   |  46 
 drivers/raw/dpaa2_qdma/meson.build |   7 +
 .../raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map  |   4 +
 drivers/raw/meson.build|   2 +-
 mk/rte.app.mk  |   3 +
 12 files changed, 472 insertions(+), 1 deletion(-)
 create mode 100644 drivers/raw/dpaa2_qdma/Makefile
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma.c
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma.h
 create mode 100644 drivers/raw/dpaa2_qdma/dpaa2_qdma_logs.h
 create mode 100644 drivers/raw/dpaa2_qdma/meson.build
 create mode 100644 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map

diff --git a/MAINTAINERS b/MAINTAINERS
index ce06e93..5ca021d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -805,6 +805,14 @@ F: doc/guides/cryptodevs/zuc.rst
 F: doc/guides/cryptodevs/features/zuc.ini
 
 
+Rawdev Drivers
+--
+
+NXP DPAA2 QDMA
+M: Nipun Gupta 
+F: drivers/raw/dpaa2_qdma/
+
+
 Eventdev Drivers
 
 M: Jerin Jacob 
diff --git a/config/common_base b/config/common_base
index 03a8688..9b48bcb 100644
--- a/config/common_base
+++ b/config/common_base
@@ -618,6 +618,11 @@ CONFIG_RTE_RAWDEV_MAX_DEVS=10
 CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV=y
 
 #
+# Compile PMD for NXP DPAA2 QDMA raw device
+#
+CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV=n
+
+#
 # Compile librte_ring
 #
 CONFIG_RTE_LIBRTE_RING=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 14e56cb..21b3fe3 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -38,3 +38,4 @@ CONFIG_RTE_LIBRTE_DPAA2_MEMPOOL=y
 CONFIG_RTE_LIBRTE_DPAA2_PMD=y
 CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=y
 CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC=y
+CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV=y
diff --git a/drivers/raw/Makefile b/drivers/raw/Makefile
index da7c8b4..0f2b076 100644
--- a/drivers/raw/Makefile
+++ b/drivers/raw/Makefile
@@ -5,5 +5,8 @@ include $(RTE_SDK)/mk/rte.vars.mk
 
 # DIRS-$() += 
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += skeleton_rawdev
+ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += dpaa2_qdma
+endif
 
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/raw/dpaa2_qdma/Makefile b/drivers/raw/dpaa2_qdma/Makefile
new file mode 100644
index 000..3b5a45a
--- /dev/null
+++ b/drivers/raw/dpaa2_qdma/Makefile
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2018 NXP
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_dpaa2_qdma.a
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+
+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal
+CFLAGS += -I$(RTE_SDK)/drivers/bus/fslmc
+CFLAGS += -I$(RTE_SDK)/drivers/bus/fslmc/qbman/include
+
+LDLIBS += -lrte_bus_fslmc
+LDLIBS += -lrte_eal
+LDLIBS += -lrte_mempool
+LDLIBS += -lrte_rawdev
+LDLIBS += -lrte_ring
+
+EXPORT_MAP := rte_pmd_dpaa2_qdma_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += dpaa2_qdma.c
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c 
b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
new file mode 100644
index 000..9288350
--- /dev/null
+++ b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
@@ -0,0 +1,294 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2018 NXP
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "dpaa2_qdma.h"
+#include "dpaa2_qdma_logs.h"
+
+/* Dynamic log type identifier */
+int dpaa2_qdma_logtype;
+
+/* QDMA device */
+static struct qdma_device qdma_dev;
+
+/* QDMA H/W queues list */
+TAILQ_HEAD(qdma_hw_queue_list, qdma_hw_queue);
+static struct qdma_hw_queue_list qdma_queue_list
+   = TAILQ_HEAD_INITIALIZER(qdma_queue_list);
+
+static const struct rte_rawdev_ops dpaa2_qdma_ops;
+
+static int
+add_hw_queues_to_list(struct dpaa2_dpdmai_dev *dpdmai_dev)
+{
+   struct qdma_hw_queue *queue;
+   int i;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   for (i = 0; i < dpdmai_dev->num_queues; i++) {
+   queue = rte_zmalloc(NULL, sizeof(struct qdma_hw_queue), 0);
+   if (!queue) {
+   DPAA2_QDMA_ERR(
+ 

[dpdk-dev] [PATCH v5 4/8] bus/fslmc: add macros required by QDMA for FLE and FD

2018-05-01 Thread Nipun Gupta
Signed-off-by: Nipun Gupta 
Acked-by: Hemant Agrawal 
---
 drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h 
b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
index e081afb..09ea603 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
@@ -188,7 +188,7 @@ enum qbman_fd_format {
((fd)->simple.frc = (0x8000 | (len)))
 #define DPAA2_GET_FD_FRC_PARSE_SUM(fd) \
((uint16_t)(((fd)->simple.frc & 0x) >> 16))
-#define DPAA2_SET_FD_FRC(fd, frc)  ((fd)->simple.frc = frc)
+#define DPAA2_SET_FD_FRC(fd, _frc) ((fd)->simple.frc = _frc)
 #define DPAA2_RESET_FD_CTRL(fd) ((fd)->simple.ctrl = 0)
 
 #defineDPAA2_SET_FD_ASAL(fd, asal) ((fd)->simple.ctrl |= (asal << 
16))
@@ -211,10 +211,12 @@ enum qbman_fd_format {
 } while (0)
 #define DPAA2_SET_FLE_OFFSET(fle, offset) \
((fle)->fin_bpid_offset |= (uint32_t)(offset) << 16)
+#define DPAA2_SET_FLE_LEN(fle, len)((fle)->length = len)
 #define DPAA2_SET_FLE_BPID(fle, bpid) ((fle)->fin_bpid_offset |= (size_t)bpid)
 #define DPAA2_GET_FLE_BPID(fle) ((fle)->fin_bpid_offset & 0x00ff)
 #define DPAA2_SET_FLE_FIN(fle) ((fle)->fin_bpid_offset |= 1 << 31)
 #define DPAA2_SET_FLE_IVP(fle)   (((fle)->fin_bpid_offset |= 0x4000))
+#define DPAA2_SET_FLE_BMT(fle)   (((fle)->fin_bpid_offset |= 0x8000))
 #define DPAA2_SET_FD_COMPOUND_FMT(fd)  \
((fd)->simple.bpid_offset |= (uint32_t)1 << 28)
 #define DPAA2_GET_FD_ADDR(fd)  \
@@ -224,6 +226,10 @@ enum qbman_fd_format {
 #define DPAA2_GET_FD_BPID(fd)  (((fd)->simple.bpid_offset & 0x3FFF))
 #define DPAA2_GET_FD_IVP(fd)   (((fd)->simple.bpid_offset & 0x4000) >> 14)
 #define DPAA2_GET_FD_OFFSET(fd)(((fd)->simple.bpid_offset & 
0x0FFF) >> 16)
+#define DPAA2_GET_FD_FRC(fd)   ((fd)->simple.frc)
+#define DPAA2_GET_FD_FLC(fd) \
+   (((uint64_t)((fd)->simple.flc_hi) << 32) + (fd)->simple.flc_lo)
+#define DPAA2_GET_FD_ERR(fd)   ((fd)->simple.bpid_offset & 0x00FF)
 #define DPAA2_GET_FLE_OFFSET(fle) (((fle)->fin_bpid_offset & 0x0FFF) >> 16)
 #define DPAA2_SET_FLE_SG_EXT(fle) ((fle)->fin_bpid_offset |= (uint64_t)1 << 29)
 #define DPAA2_IS_SET_FLE_SG_EXT(fle)   \
-- 
1.9.1



[dpdk-dev] [PATCH v6 6/8] raw/dpaa2_qdma: support configuration APIs

2018-05-01 Thread Nipun Gupta
Signed-off-by: Nipun Gupta 
---
 doc/api/doxy-api-index.md  |   1 +
 doc/api/doxy-api.conf  |   1 +
 drivers/raw/dpaa2_qdma/Makefile|   2 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma.c| 375 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma.h|  63 
 drivers/raw/dpaa2_qdma/meson.build |   2 +
 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h| 216 
 .../raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map  |  12 +
 8 files changed, 672 insertions(+)
 create mode 100644 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h

diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 26ce7b4..437d903 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -38,6 +38,7 @@ The public API headers are grouped by topics:
   [i40e]   (@ref rte_pmd_i40e.h),
   [bnxt]   (@ref rte_pmd_bnxt.h),
   [dpaa]   (@ref rte_pmd_dpaa.h),
+  [dpaa2_qdma] (@ref rte_pmd_dpaa2_qdma.h),
   [crypto_scheduler]   (@ref rte_cryptodev_scheduler.h)
 
 - **memory**:
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 5686cbb..88bee03 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -37,6 +37,7 @@ INPUT   = doc/api/doxy-api-index.md \
   drivers/net/i40e \
   drivers/net/ixgbe \
   drivers/net/softnic \
+  drivers/raw/dpaa2_qdma \
   lib/librte_eal/common/include \
   lib/librte_eal/common/include/generic \
   lib/librte_acl \
diff --git a/drivers/raw/dpaa2_qdma/Makefile b/drivers/raw/dpaa2_qdma/Makefile
index 3b5a45a..264eca8 100644
--- a/drivers/raw/dpaa2_qdma/Makefile
+++ b/drivers/raw/dpaa2_qdma/Makefile
@@ -31,4 +31,6 @@ LIBABIVER := 1
 #
 SRCS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += dpaa2_qdma.c
 
+SYMLINK-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV)-include += 
rte_pmd_dpaa2_qdma.h
+
 include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c 
b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
index 9288350..b38a282 100644
--- a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
+++ b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
@@ -20,6 +20,7 @@
 
 #include "dpaa2_qdma.h"
 #include "dpaa2_qdma_logs.h"
+#include "rte_pmd_dpaa2_qdma.h"
 
 /* Dynamic log type identifier */
 int dpaa2_qdma_logtype;
@@ -32,6 +33,380 @@
 static struct qdma_hw_queue_list qdma_queue_list
= TAILQ_HEAD_INITIALIZER(qdma_queue_list);
 
+/* QDMA Virtual Queues */
+struct qdma_virt_queue *qdma_vqs;
+
+/* QDMA per core data */
+struct qdma_per_core_info qdma_core_info[RTE_MAX_LCORE];
+
+static struct qdma_hw_queue *
+alloc_hw_queue(uint32_t lcore_id)
+{
+   struct qdma_hw_queue *queue = NULL;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   /* Get a free queue from the list */
+   TAILQ_FOREACH(queue, &qdma_queue_list, next) {
+   if (queue->num_users == 0) {
+   queue->lcore_id = lcore_id;
+   queue->num_users++;
+   break;
+   }
+   }
+
+   return queue;
+}
+
+static void
+free_hw_queue(struct qdma_hw_queue *queue)
+{
+   DPAA2_QDMA_FUNC_TRACE();
+
+   queue->num_users--;
+}
+
+
+static struct qdma_hw_queue *
+get_hw_queue(uint32_t lcore_id)
+{
+   struct qdma_per_core_info *core_info;
+   struct qdma_hw_queue *queue, *temp;
+   uint32_t least_num_users;
+   int num_hw_queues, i;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   core_info = &qdma_core_info[lcore_id];
+   num_hw_queues = core_info->num_hw_queues;
+
+   /*
+* Allocate a HW queue if there are less queues
+* than maximum per core queues configured
+*/
+   if (num_hw_queues < qdma_dev.max_hw_queues_per_core) {
+   queue = alloc_hw_queue(lcore_id);
+   if (queue) {
+   core_info->hw_queues[num_hw_queues] = queue;
+   core_info->num_hw_queues++;
+   return queue;
+   }
+   }
+
+   queue = core_info->hw_queues[0];
+   /* In case there is no queue associated with the core return NULL */
+   if (!queue)
+   return NULL;
+
+   /* Fetch the least loaded H/W queue */
+   least_num_users = core_info->hw_queues[0]->num_users;
+   for (i = 0; i < num_hw_queues; i++) {
+   temp = core_info->hw_queues[i];
+   if (temp->num_users < least_num_users)
+   queue = temp;
+   }
+
+   if (queue)
+   queue->num_users++;
+
+   return queue;
+}
+
+static void
+put_hw_queue(struct qdma_hw_queue *queue)
+{
+   struct qdma_per_core_info *core_info;
+   int lcore_id, num_hw_queues, i;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   /*
+* If this is the last user of the 

[dpdk-dev] [PATCH v5 8/8] doc: add DPAA2 QDMA rawdev guide

2018-05-01 Thread Nipun Gupta
Signed-off-by: Nipun Gupta 
---
 MAINTAINERS|   1 +
 doc/guides/index.rst   |   1 +
 doc/guides/rawdevs/dpaa2_qdma.rst  | 140 +
 doc/guides/rawdevs/index.rst   |  14 
 doc/guides/rel_notes/release_18_05.rst |   8 ++
 5 files changed, 164 insertions(+)
 create mode 100644 doc/guides/rawdevs/dpaa2_qdma.rst
 create mode 100644 doc/guides/rawdevs/index.rst

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ca021d..3fc4a2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -811,6 +811,7 @@ Rawdev Drivers
 NXP DPAA2 QDMA
 M: Nipun Gupta 
 F: drivers/raw/dpaa2_qdma/
+F: doc/guides/rawdevs/dpaa2_qdma.rst
 
 
 Eventdev Drivers
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index d60529d..a93baac 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -20,6 +20,7 @@ DPDK documentation
eventdevs/index
mempool/index
platform/index
+   rawdevs/index
contributing/index
rel_notes/index
faq/index
diff --git a/doc/guides/rawdevs/dpaa2_qdma.rst 
b/doc/guides/rawdevs/dpaa2_qdma.rst
new file mode 100644
index 000..b9bc4ec
--- /dev/null
+++ b/doc/guides/rawdevs/dpaa2_qdma.rst
@@ -0,0 +1,140 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2018 NXP
+
+NXP DPAA2 QDMA Driver
+=
+
+The DPAA2 QDMA is an implementation of the rawdev API, that provide means
+to initiate a DMA transaction from CPU. The initiated DMA is performed
+without CPU being involved in the actual DMA transaction. This is achieved
+via using the DPDMAI device exposed by MC.
+
+More information can be found at `NXP Official Website
+`_.
+
+Features
+
+
+The DPAA2 QDMA implements following features in the rawdev API;
+
+- Supports issuing DMA of data within memory without hogging CPU while
+  performing DMA operation.
+- Supports configuring to optionally get status of the DMA translation on
+  per DMA operation basis.
+
+Supported DPAA2 SoCs
+
+
+- LS2084A/LS2044A
+- LS2088A/LS2048A
+- LS1088A/LS1048A
+
+Prerequisites
+-
+
+There are three main pre-requisities for executing DPAA2 QDMA on a DPAA2
+compatible board:
+
+1. **ARM 64 Tool Chain**
+
+   For example, the `*aarch64* Linaro Toolchain 
`_.
+
+2. **Linux Kernel**
+
+   It can be obtained from `NXP's Github hosting 
`_.
+
+3. **Rootfile system**
+
+   Any *aarch64* supporting filesystem can be used. For example,
+   Ubuntu 15.10 (Wily) or 16.04 LTS (Xenial) userland which can be obtained
+   from `here 
`_.
+
+As an alternative method, DPAA2 QDMA can also be executed using images provided
+as part of SDK from NXP. The SDK includes all the above prerequisites necessary
+to bring up a DPAA2 board.
+
+The following dependencies are not part of DPDK and must be installed
+separately:
+
+- **NXP Linux SDK**
+
+  NXP Linux software development kit (SDK) includes support for family
+  of QorIQ® ARM-Architecture-based system on chip (SoC) processors
+  and corresponding boards.
+
+  It includes the Linux board support packages (BSPs) for NXP SoCs,
+  a fully operational tool chain, kernel and board specific modules.
+
+  SDK and related information can be obtained from:  `NXP QorIQ SDK  
`_.
+
+- **DPDK Extra Scripts**
+
+  DPAA2 based resources can be configured easily with the help of ready scripts
+  as provided in the DPDK Extra repository.
+
+  `DPDK Extras Scripts `_.
+
+Currently supported by DPDK:
+
+- NXP LSDK **17.12+**.
+- MC Firmware version **10.3.0** and higher.
+- Supported architectures:  **arm64 LE**.
+
+- Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup 
the basic DPDK environment.
+
+.. note::
+
+   Some part of fslmc bus code (mc flib - object library) routines are
+   dual licensed (BSD & GPLv2).
+
+Pre-Installation Configuration
+--
+
+Config File Options
+~~~
+
+The following options can be modified in the ``config`` file.
+
+- ``CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV`` (default ``y``)
+
+  Toggle compilation of the ``lrte_pmd_dpaa2_qdma`` driver.
+
+Enabling logs
+-
+
+For enabling logs, use the following EAL parameter:
+
+.. code-block:: console
+
+   ./your_qdma_application  --log-level=pmd.raw.dpaa2.qdma,
+
+Using ``pmd.raw.dpaa2.qdma`` as log matching criteria, all Event PMD logs can 
be
+enabled which are lower than logging ``level``.
+
+Driver Compilation
+~~
+
+To compile the DPAA2 QDMA PMD for Linux arm6

[dpdk-dev] [PATCH v5 7/8] raw/dpaa2_qdma: support enq and deq operations

2018-05-01 Thread Nipun Gupta
Signed-off-by: Nipun Gupta 
---
 drivers/raw/dpaa2_qdma/dpaa2_qdma.c| 333 +
 drivers/raw/dpaa2_qdma/dpaa2_qdma.h|  21 ++
 drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma.h|  70 +
 .../raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map  |   4 +
 4 files changed, 428 insertions(+)

diff --git a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c 
b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
index b38a282..1d15c30 100644
--- a/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
+++ b/drivers/raw/dpaa2_qdma/dpaa2_qdma.c
@@ -344,6 +344,339 @@
return i;
 }
 
+static void
+dpaa2_qdma_populate_fle(struct qbman_fle *fle,
+   uint64_t src, uint64_t dest,
+   size_t len, uint32_t flags)
+{
+   struct qdma_sdd *sdd;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   sdd = (struct qdma_sdd *)((uint8_t *)(fle) +
+   (DPAA2_QDMA_MAX_FLE * sizeof(struct qbman_fle)));
+
+   /* first frame list to source descriptor */
+   DPAA2_SET_FLE_ADDR(fle, DPAA2_VADDR_TO_IOVA(sdd));
+   DPAA2_SET_FLE_LEN(fle, (2 * (sizeof(struct qdma_sdd;
+
+   /* source and destination descriptor */
+   DPAA2_SET_SDD_RD_COHERENT(sdd); /* source descriptor CMD */
+   sdd++;
+   DPAA2_SET_SDD_WR_COHERENT(sdd); /* dest descriptor CMD */
+
+   fle++;
+   /* source frame list to source buffer */
+   if (flags & RTE_QDMA_JOB_SRC_PHY) {
+   DPAA2_SET_FLE_ADDR(fle, src);
+   DPAA2_SET_FLE_BMT(fle);
+   } else {
+   DPAA2_SET_FLE_ADDR(fle, DPAA2_VADDR_TO_IOVA(src));
+   }
+   DPAA2_SET_FLE_LEN(fle, len);
+
+   fle++;
+   /* destination frame list to destination buffer */
+   if (flags & RTE_QDMA_JOB_DEST_PHY) {
+   DPAA2_SET_FLE_BMT(fle);
+   DPAA2_SET_FLE_ADDR(fle, dest);
+   } else {
+   DPAA2_SET_FLE_ADDR(fle, DPAA2_VADDR_TO_IOVA(dest));
+   }
+   DPAA2_SET_FLE_LEN(fle, len);
+
+   /* Final bit: 1, for last frame list */
+   DPAA2_SET_FLE_FIN(fle);
+}
+
+static int
+dpdmai_dev_enqueue(struct dpaa2_dpdmai_dev *dpdmai_dev,
+  uint16_t txq_id,
+  uint16_t vq_id,
+  struct rte_qdma_job *job)
+{
+   struct qdma_io_meta *io_meta;
+   struct qbman_fd fd;
+   struct dpaa2_queue *txq;
+   struct qbman_fle *fle;
+   struct qbman_eq_desc eqdesc;
+   struct qbman_swp *swp;
+   int ret;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   if (unlikely(!DPAA2_PER_LCORE_DPIO)) {
+   ret = dpaa2_affine_qbman_swp();
+   if (ret) {
+   DPAA2_QDMA_ERR("Failure in affining portal");
+   return 0;
+   }
+   }
+   swp = DPAA2_PER_LCORE_PORTAL;
+
+   txq = &(dpdmai_dev->tx_queue[txq_id]);
+
+   /* Prepare enqueue descriptor */
+   qbman_eq_desc_clear(&eqdesc);
+   qbman_eq_desc_set_fq(&eqdesc, txq->fqid);
+   qbman_eq_desc_set_no_orp(&eqdesc, 0);
+   qbman_eq_desc_set_response(&eqdesc, 0, 0);
+
+   /*
+* Get an FLE/SDD from FLE pool.
+* Note: IO metadata is before the FLE and SDD memory.
+*/
+   ret = rte_mempool_get(qdma_dev.fle_pool, (void **)(&io_meta));
+   if (ret) {
+   DPAA2_QDMA_DP_WARN("Memory alloc failed for FLE");
+   return ret;
+   }
+
+   /* Set the metadata */
+   io_meta->cnxt = (size_t)job;
+   io_meta->id = vq_id;
+
+   fle = (struct qbman_fle *)(io_meta + 1);
+
+   /* populate Frame descriptor */
+   memset(&fd, 0, sizeof(struct qbman_fd));
+   DPAA2_SET_FD_ADDR(&fd, DPAA2_VADDR_TO_IOVA(fle));
+   DPAA2_SET_FD_COMPOUND_FMT(&fd);
+   DPAA2_SET_FD_FRC(&fd, QDMA_SER_CTX);
+
+   /* Populate FLE */
+   memset(fle, 0, QDMA_FLE_POOL_SIZE);
+   dpaa2_qdma_populate_fle(fle, job->src, job->dest, job->len, job->flags);
+
+   /* Enqueue the packet to the QBMAN */
+   do {
+   ret = qbman_swp_enqueue_multiple(swp, &eqdesc, &fd, NULL, 1);
+   if (ret < 0 && ret != -EBUSY)
+   DPAA2_QDMA_ERR("Transmit failure with err: %d", ret);
+   } while (ret == -EBUSY);
+
+   DPAA2_QDMA_DP_DEBUG("Successfully transmitted a packet");
+
+   return ret;
+}
+
+int __rte_experimental
+rte_qdma_vq_enqueue_multi(uint16_t vq_id,
+ struct rte_qdma_job **job,
+ uint16_t nb_jobs)
+{
+   int i, ret;
+
+   DPAA2_QDMA_FUNC_TRACE();
+
+   for (i = 0; i < nb_jobs; i++) {
+   ret = rte_qdma_vq_enqueue(vq_id, job[i]);
+   if (ret < 0)
+   break;
+   }
+
+   return i;
+}
+
+int __rte_experimental
+rte_qdma_vq_enqueue(uint16_t vq_id,
+   struct rte_qdma_job *job)
+{
+   struct qdma_virt_queue *qdma_vq = &qdma_vqs[vq_id];
+   struct qdma_hw_queue *qdma_pq = qdma_vq->hw_queue;
+   struct dpaa2_dpd

[dpdk-dev] [PATCH 2/2] net/dpaa2: add missing device info fields

2018-05-01 Thread Hemant Agrawal
Add the hashed RSS support info and other fields in device info.

Signed-off-by: Hemant Agrawal 
---
 drivers/net/dpaa2/dpaa2_ethdev.c | 5 +
 drivers/net/dpaa2/dpaa2_ethdev.h | 6 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 2f34022..c304b82 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -207,6 +207,11 @@ dpaa2_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->speed_capa = ETH_LINK_SPEED_1G |
ETH_LINK_SPEED_2_5G |
ETH_LINK_SPEED_10G;
+
+   dev_info->max_hash_mac_addrs = 0;
+   dev_info->max_vfs = 0;
+   dev_info->max_vmdq_pools = ETH_16_POOLS;
+   dev_info->flow_type_rss_offloads = DPAA2_RSS_OFFLOAD_ALL;
 }
 
 static int
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.h b/drivers/net/dpaa2/dpaa2_ethdev.h
index ba0856f..bd69f52 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.h
+++ b/drivers/net/dpaa2/dpaa2_ethdev.h
@@ -50,6 +50,12 @@
 /* Disable RX tail drop, default is enable */
 #define DPAA2_RX_TAILDROP_OFF  0x04
 
+#define DPAA2_RSS_OFFLOAD_ALL ( \
+   ETH_RSS_IP | \
+   ETH_RSS_UDP | \
+   ETH_RSS_TCP | \
+   ETH_RSS_SCTP)
+
 /* LX2 FRC Parsed values (Little Endian) */
 #define DPAA2_PKT_TYPE_ETHER   0x0060
 #define DPAA2_PKT_TYPE_IPV40x
-- 
2.7.4



[dpdk-dev] [PATCH 1/2] net/dpaa: fix the RSS hash support

2018-05-01 Thread Hemant Agrawal
Fixes: 4fa5e0bbc573 ("net/dpaa: support hashed RSS")
Cc: sta...@dpdk.org

Signed-off-by: Hemant Agrawal 
---
 drivers/net/dpaa/dpaa_ethdev.h | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index c051ae3..df2b384 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -74,14 +74,10 @@
 #define DPAA_DEBUG_FQ_TX_ERROR   1
 
 #define DPAA_RSS_OFFLOAD_ALL ( \
-   ETH_RSS_FRAG_IPV4 | \
-   ETH_RSS_NONFRAG_IPV4_TCP | \
-   ETH_RSS_NONFRAG_IPV4_UDP | \
-   ETH_RSS_NONFRAG_IPV4_SCTP | \
-   ETH_RSS_FRAG_IPV6 | \
-   ETH_RSS_NONFRAG_IPV6_TCP | \
-   ETH_RSS_NONFRAG_IPV6_UDP | \
-   ETH_RSS_NONFRAG_IPV6_SCTP)
+   ETH_RSS_IP | \
+   ETH_RSS_UDP | \
+   ETH_RSS_TCP | \
+   ETH_RSS_SCTP)
 
 #define DPAA_TX_CKSUM_OFFLOAD_MASK ( \
PKT_TX_IP_CKSUM |\
-- 
2.7.4



Re: [dpdk-dev] [PATCH v5 1/2] ethdev: add supported hash function check

2018-05-01 Thread Ferruh Yigit
On 4/23/2018 7:14 PM, Thomas Monjalon wrote:
> 23/04/2018 18:06, Ferruh Yigit:
>> On 4/20/2018 3:30 PM, Xueming Li wrote:
>>> Add supported RSS hash function check in device configuration to
>>> have better error verbosity for application developers.
>>>
>>> Signed-off-by: Xueming Li 
>>> Acked-by: Adrien Mazarguil 
>>>  
>>> +   /* Check that device supports requested rss hash functions. */
>>> +   if ((dev_info.flow_type_rss_offloads |
>>> +dev_conf->rx_adv_conf.rss_conf.rss_hf) !=
>>> +   dev_info.flow_type_rss_offloads) {
>>> +   RTE_PMD_DEBUG_TRACE("ethdev port_id=%d invalid rss_hf: "
>>> +   "0x%"PRIx64", valid value: 0x%"PRIx64"\n",
>>> +   port_id,
>>> +   dev_conf->rx_adv_conf.rss_conf.rss_hf,
>>> +   dev_info.flow_type_rss_offloads);
>>> +   return -EINVAL;
>>> +   }
>>
>> Hi Thomas,
>>
>> This can break the PMDs that are not setting flow_type_rss_offloads properly.
>> How can we highlight this so that PMD owners can double check?
> 
> Can we have a check-list in the RC1 announce email?

Hi Thomas, Xueming,

This change is breaking multiple sample applications, testpmd was also broken
but already fixed by Qi [1].

Indeed this patch should update sample applications and testpmd as well when
doing an ethdev API update, also should update release notes "API Changes" 
section.

We can fix sample applications for rc2, but same thing also can hit users.

Or for this release we can remote returning error, instead update log message to
error. Next release add the return and change log message back to debug.

What do you think?


[1]
Commit: 9089296206ce ("app/testpmd: fix config due to RSS offload check")


[dpdk-dev] [PATCH 2/2] net/mlx5: fix probe return value polarity

2018-05-01 Thread Shahaf Shuler
mlx5 prefixed function returns a negative errno value.
the error handler on mlx5_pci_probe is doing the same.

Fixes: a6d83b6a9209 ("net/mlx5: standardize on negative errno values")
Cc: nelio.laranje...@6wind.com

Signed-off-by: Shahaf Shuler 
---
 drivers/net/mlx5/mlx5.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 46cb370a29..ab860b5985 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -804,12 +804,16 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
goto error;
/* Receive command fd from primary process */
err = mlx5_socket_connect(eth_dev);
-   if (err < 0)
+   if (err < 0) {
+   err = -err;
goto error;
+   }
/* Remap UAR for Tx queues. */
err = mlx5_tx_uar_remap(eth_dev, err);
-   if (err)
+   if (err) {
+   err = -err;
goto error;
+   }
/*
 * Ethdev pointer is still required as input since
 * the primary device is not accessible from the
-- 
2.12.0



[dpdk-dev] [PATCH 1/2] net/mlx5: fix socket connection return value

2018-05-01 Thread Shahaf Shuler
Upon success, mlx5_socket_connect should return the fd descriptor of the
primary process

Fixes: a6d83b6a9209 ("net/mlx5: standardize on negative errno values")
Cc: nelio.laranje...@6wind.com

Signed-off-by: Yongseok Koh 
Signed-off-by: Shahaf Shuler 
---
 drivers/net/mlx5/mlx5.c| 2 +-
 drivers/net/mlx5/mlx5_socket.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 8f983061a0..46cb370a29 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -804,7 +804,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
goto error;
/* Receive command fd from primary process */
err = mlx5_socket_connect(eth_dev);
-   if (err)
+   if (err < 0)
goto error;
/* Remap UAR for Tx queues. */
err = mlx5_tx_uar_remap(eth_dev, err);
diff --git a/drivers/net/mlx5/mlx5_socket.c b/drivers/net/mlx5/mlx5_socket.c
index e12c4cb2e1..99297d5c43 100644
--- a/drivers/net/mlx5/mlx5_socket.c
+++ b/drivers/net/mlx5/mlx5_socket.c
@@ -294,7 +294,7 @@ mlx5_socket_connect(struct rte_eth_dev *dev)
}
ret = *fd;
close(socket_fd);
-   return 0;
+   return ret;
 error:
if (socket_fd != -1)
close(socket_fd);
-- 
2.12.0



[dpdk-dev] [PATCH 1/2] net/dpaa: enhance the RSS hash support

2018-05-01 Thread Shreyansh Jain
From: Hemant Agrawal 

Enhance the RSS hash fields supported by DPAA1.
The RSS Hash key fields are configured external to DPDK, through SoC
specific scripts.

Signed-off-by: Hemant Agrawal 
Acked-by: Shreyansh Jain 
---
 drivers/net/dpaa/dpaa_ethdev.h | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index c051ae32a..df2b38444 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -74,14 +74,10 @@
 #define DPAA_DEBUG_FQ_TX_ERROR   1
 
 #define DPAA_RSS_OFFLOAD_ALL ( \
-   ETH_RSS_FRAG_IPV4 | \
-   ETH_RSS_NONFRAG_IPV4_TCP | \
-   ETH_RSS_NONFRAG_IPV4_UDP | \
-   ETH_RSS_NONFRAG_IPV4_SCTP | \
-   ETH_RSS_FRAG_IPV6 | \
-   ETH_RSS_NONFRAG_IPV6_TCP | \
-   ETH_RSS_NONFRAG_IPV6_UDP | \
-   ETH_RSS_NONFRAG_IPV6_SCTP)
+   ETH_RSS_IP | \
+   ETH_RSS_UDP | \
+   ETH_RSS_TCP | \
+   ETH_RSS_SCTP)
 
 #define DPAA_TX_CKSUM_OFFLOAD_MASK ( \
PKT_TX_IP_CKSUM |\
-- 
2.14.1



[dpdk-dev] [PATCH 2/2] net/dpaa2: update RSS hash and other device info fields

2018-05-01 Thread Shreyansh Jain
From: Hemant Agrawal 

Add RSS Hash fields supported and set default values to other device
information fields.

Signed-off-by: Hemant Agrawal 
Acked-by: Shreyansh Jain 
---
 drivers/net/dpaa2/dpaa2_ethdev.c | 5 +
 drivers/net/dpaa2/dpaa2_ethdev.h | 6 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 2f34022e5..c304b82bd 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -207,6 +207,11 @@ dpaa2_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
dev_info->speed_capa = ETH_LINK_SPEED_1G |
ETH_LINK_SPEED_2_5G |
ETH_LINK_SPEED_10G;
+
+   dev_info->max_hash_mac_addrs = 0;
+   dev_info->max_vfs = 0;
+   dev_info->max_vmdq_pools = ETH_16_POOLS;
+   dev_info->flow_type_rss_offloads = DPAA2_RSS_OFFLOAD_ALL;
 }
 
 static int
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.h b/drivers/net/dpaa2/dpaa2_ethdev.h
index ba0856f3e..bd69f523d 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.h
+++ b/drivers/net/dpaa2/dpaa2_ethdev.h
@@ -50,6 +50,12 @@
 /* Disable RX tail drop, default is enable */
 #define DPAA2_RX_TAILDROP_OFF  0x04
 
+#define DPAA2_RSS_OFFLOAD_ALL ( \
+   ETH_RSS_IP | \
+   ETH_RSS_UDP | \
+   ETH_RSS_TCP | \
+   ETH_RSS_SCTP)
+
 /* LX2 FRC Parsed values (Little Endian) */
 #define DPAA2_PKT_TYPE_ETHER   0x0060
 #define DPAA2_PKT_TYPE_IPV40x
-- 
2.14.1



Re: [dpdk-dev] [PATCH 1/2] net/dpaa: enhance the RSS hash support

2018-05-01 Thread Shreyansh Jain

On Tuesday 01 May 2018 06:22 PM, Shreyansh Jain wrote:

From: Hemant Agrawal 

Enhance the RSS hash fields supported by DPAA1.
The RSS Hash key fields are configured external to DPDK, through SoC
specific scripts.

Signed-off-by: Hemant Agrawal 
Acked-by: Shreyansh Jain 
---


Self NACK.
Patchset was already sent out by Hemant earlier [1].
[1] http://dpdk.org/ml/archives/dev/2018-May/099844.html

-
Shreyansh




Re: [dpdk-dev] [PATCH 2/3] net/ixgbe: initialise nb_representor_ports value

2018-05-01 Thread Doherty, Declan

On 01/05/2018 10:46 AM, Ananyev, Konstantin wrote:




-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
Sent: Monday, April 30, 2018 4:33 PM
To: dev@dpdk.org
Cc: Doherty, Declan 
Subject: [dpdk-dev] [PATCH 2/3] net/ixgbe: initialise nb_representor_ports value

Initialise rte_ethdev_args nb_representor_ports to zero to handle
the case where no devargs are passed to the IXGBE PF on
device probe, so that there is no invalid attempts to create
representor ports.

Coverity Issue: 277231
Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")

Signed-off-by: Declan Doherty 
---
  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 0ccf55dc8..283dd7e49 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1725,8 +1725,7 @@ eth_ixgbe_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
struct rte_pci_device *pci_dev)
  {
char name[RTE_ETH_NAME_MAX_LEN];
-
-   struct rte_eth_devargs eth_da;
+   struct rte_eth_devargs eth_da = { .nb_representor_ports = 0 };
int i, retval;

if (pci_dev->device.devargs) {


Might be a bit better:
If (pci_dev->device.devargs) { rte_eth_devargs_parse(...);...}
else memset(ð_da, 0, sizeof(eth_da));
to be more consistent.
BTW, I think rte_eth_devargs_parse() need to add formal check for input 
parameters.
Konstantin



Ok, thanks Konstantin, that makes sense, we're working on cleaning up 
rte_eth_devargs_parse() to align with kvargs so I'll make sure to add 
those checks.






--
2.14.3






Re: [dpdk-dev] [PATCH 3/3] net/ixgbe: add null pointer check for pf_ethdev

2018-05-01 Thread Doherty, Declan

On 01/05/2018 10:47 AM, Ananyev, Konstantin wrote:




-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Declan Doherty
Sent: Monday, April 30, 2018 4:33 PM
To: dev@dpdk.org
Cc: Doherty, Declan 
Subject: [dpdk-dev] [PATCH 3/3] net/ixgbe: add null pointer check for pf_ethdev

Add NULL parameter check for rte_eth_dev_allocated() API call to
eth_ixgbe_pci_probe().

Coverity Issue: 277216
Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")

Signed-off-by: Declan Doherty 
---
  drivers/net/ixgbe/ixgbe_ethdev.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 283dd7e49..75f927c06 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1747,6 +1747,9 @@ eth_ixgbe_pci_probe(struct rte_pci_driver *pci_drv 
__rte_unused,
struct rte_eth_dev *pf_ethdev = rte_eth_dev_allocated(
pci_dev->device.name);

+   if (pf_ethdev == NULL)
+   return -ENODEV;
+
for (i = 0; i < eth_da.nb_representor_ports; i++) {
struct ixgbe_vf_info *vfinfo;
struct ixgbe_vf_representor representor;
--


Looks good - can I just ask to move pf_ethdev definition to the top of the 
function?
To comply with dpdk coding style.
Konstantin


Will do.


2.14.3






Re: [dpdk-dev] [PATCH v3 0/5] Initial compressdev unit tests

2018-05-01 Thread Daly, Lee

<...> 
> Added initial tests for Compressdev library.
> The tests are performed compressing a test buffer (or multiple test buffers)
> with compressdev or Zlib, and decompressing it/them with the other library
> (if compression is done with compressdev, decompression is done with Zlib,
> and viceversa).
> 
> Tests added so far are based on the deflate algorithm,
> including:
> - Fixed huffman on single buffer
> - Dynamic huffman on single buffer
> - Multi compression level test on single buffer
> - Multi buffer
> - Multi xform using the same buffer
> 
> Due to a dependency on Zlib, the test is not enabled by default.
> Once the library is installed, the configuration option
> CONFIG_RTE_COMPRESSDEV_TEST must be set to Y.
> However, if building with Meson, the test will be built automatically, if 
> Zlib is
> installed.
> 
> The test requires a compressdev PMD to be initialized, when running the test
> app. For example:
> 
> ./build/app/test --vdev="compress_X"
> 
> RTE>>compressdev_autotest
> 
> This patchset depends on the Compressdev API patchset:
> http://dpdk.org/ml/archives/dev/2018-April/099580.html
> ("[PATCH v6 00/14] Implement compression API")
> 
<...>
Series-acked-by: Lee Daly 


[dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Bruce Richardson
The Tx function selection code in the driver only used the older txq
flags values to check whether the scalar or vector functions should be
used. This caused performance regressions with testpmd io-fwd as the
scalar path rather than the vector one was being used in the default
case. Fix this by changing the code to take account of new offloads and
deleting the defines used for the old ones.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")

Signed-off-by: Bruce Richardson 
---
 drivers/net/i40e/i40e_rxtx.c | 45 +++-
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index ec1ce54ca..c523af575 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -40,9 +40,6 @@
 /* Base address of the HW descriptor ring should be 128B aligned. */
 #define I40E_RING_BASE_ALIGN   128
 
-#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
-   ETH_TXQ_FLAGS_NOOFFLOADS)
-
 #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
 
 #ifdef RTE_LIBRTE_IEEE1588
@@ -70,6 +67,12 @@
 #define I40E_TX_OFFLOAD_NOTSUP_MASK \
(PKT_TX_OFFLOAD_MASK ^ I40E_TX_OFFLOAD_MASK)
 
+static const uint64_t i40e_simple_ol_mask = (DEV_TX_OFFLOAD_MULTI_SEGS |
+   DEV_TX_OFFLOAD_VLAN_INSERT |
+   DEV_TX_OFFLOAD_SCTP_CKSUM |
+   DEV_TX_OFFLOAD_UDP_CKSUM |
+   DEV_TX_OFFLOAD_TCP_CKSUM);
+
 static inline void
 i40e_rxd_to_vlan_tci(struct rte_mbuf *mb, volatile union i40e_rx_desc *rxdp)
 {
@@ -2108,11 +2111,9 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
 dev->data->nb_tx_queues)) {
/**
 * If it is the first queue to setup,
-* set all flags to default and call
+* set all flags and call
 * i40e_set_tx_function.
 */
-   ad->tx_simple_allowed = true;
-   ad->tx_vec_allowed = true;
i40e_set_tx_function_flag(dev, txq);
i40e_set_tx_function(dev);
return 0;
@@ -2128,9 +2129,8 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
}
/* check simple tx conflict */
if (ad->tx_simple_allowed) {
-   if (((txq->txq_flags & I40E_SIMPLE_FLAGS) !=
-I40E_SIMPLE_FLAGS) ||
-   txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
+   if ((txq->offloads & i40e_simple_ol_mask) != 0 ||
+   txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
PMD_DRV_LOG(ERR, "No-simple tx is required.");
return -EINVAL;
}
@@ -3080,18 +3080,21 @@ i40e_set_tx_function_flag(struct rte_eth_dev *dev, 
struct i40e_tx_queue *txq)
I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
 
/* Use a simple Tx queue (no offloads, no multi segs) if possible */
-   if (((txq->txq_flags & I40E_SIMPLE_FLAGS) == I40E_SIMPLE_FLAGS)
-   && (txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST)) {
-   if (txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ) {
-   PMD_INIT_LOG(DEBUG, "Vector tx"
-" can be enabled on this txq.");
-
-   } else {
-   ad->tx_vec_allowed = false;
-   }
-   } else {
-   ad->tx_simple_allowed = false;
-   }
+   ad->tx_simple_allowed = ((txq->offloads & i40e_simple_ol_mask) == 0 &&
+   txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST);
+   ad->tx_vec_allowed = (ad->tx_simple_allowed &&
+   txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ);
+
+   if (ad->tx_vec_allowed)
+   PMD_INIT_LOG(DEBUG, "Vector Tx can be enabled on Tx queue %u.",
+   txq->queue_id);
+   else if (ad->tx_simple_allowed)
+   PMD_INIT_LOG(DEBUG, "Simple Tx can be enabled on Tx queue %u.",
+   txq->queue_id);
+   else
+   PMD_INIT_LOG(DEBUG,
+   "Neither simple nor vector Tx enabled on Tx 
queue %u\n",
+   txq->queue_id);
 }
 
 void __attribute__((cold))
-- 
2.14.3



Re: [dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Ananyev, Konstantin
Hi Bruce,

> 
> The Tx function selection code in the driver only used the older txq
> flags values to check whether the scalar or vector functions should be
> used. This caused performance regressions with testpmd io-fwd as the
> scalar path rather than the vector one was being used in the default
> case. Fix this by changing the code to take account of new offloads and
> deleting the defines used for the old ones.
> 
> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> 
> Signed-off-by: Bruce Richardson 
> ---
>  drivers/net/i40e/i40e_rxtx.c | 45 
> +++-
>  1 file changed, 24 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index ec1ce54ca..c523af575 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -40,9 +40,6 @@
>  /* Base address of the HW descriptor ring should be 128B aligned. */
>  #define I40E_RING_BASE_ALIGN 128
> 
> -#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> - ETH_TXQ_FLAGS_NOOFFLOADS)
> -
>  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> 
>  #ifdef RTE_LIBRTE_IEEE1588
> @@ -70,6 +67,12 @@
>  #define I40E_TX_OFFLOAD_NOTSUP_MASK \
>   (PKT_TX_OFFLOAD_MASK ^ I40E_TX_OFFLOAD_MASK)
> 
> +static const uint64_t i40e_simple_ol_mask = (DEV_TX_OFFLOAD_MULTI_SEGS |
> + DEV_TX_OFFLOAD_VLAN_INSERT |
> + DEV_TX_OFFLOAD_SCTP_CKSUM |
> + DEV_TX_OFFLOAD_UDP_CKSUM |
> + DEV_TX_OFFLOAD_TCP_CKSUM);
> +

Seems incomplete.
>From i40e_ethdev.c full-featured tx supports:
dev_info->tx_offload_capa =
DEV_TX_OFFLOAD_VLAN_INSERT |
DEV_TX_OFFLOAD_QINQ_INSERT |
DEV_TX_OFFLOAD_IPV4_CKSUM |
DEV_TX_OFFLOAD_UDP_CKSUM |
DEV_TX_OFFLOAD_TCP_CKSUM |
DEV_TX_OFFLOAD_SCTP_CKSUM |
DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM |
DEV_TX_OFFLOAD_TCP_TSO |
DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
DEV_TX_OFFLOAD_GRE_TNL_TSO |
DEV_TX_OFFLOAD_IPIP_TNL_TSO |
DEV_TX_OFFLOAD_GENEVE_TNL_TSO;

So we probably need the same here plus multiseg.
BTW, it is really strange that we don't have multiseg in tx_offload_capa.
Should be present I think.
Might be worse to create a new define for it, or just use 
dev_info->tx_offload_capa directly.
Konstantin



>  static inline void
>  i40e_rxd_to_vlan_tci(struct rte_mbuf *mb, volatile union i40e_rx_desc *rxdp)
>  {
> @@ -2108,11 +2111,9 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev 
> *dev,
>dev->data->nb_tx_queues)) {
>   /**
>* If it is the first queue to setup,
> -  * set all flags to default and call
> +  * set all flags and call
>* i40e_set_tx_function.
>*/
> - ad->tx_simple_allowed = true;
> - ad->tx_vec_allowed = true;
>   i40e_set_tx_function_flag(dev, txq);
>   i40e_set_tx_function(dev);
>   return 0;
> @@ -2128,9 +2129,8 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
>   }
>   /* check simple tx conflict */
>   if (ad->tx_simple_allowed) {
> - if (((txq->txq_flags & I40E_SIMPLE_FLAGS) !=
> -  I40E_SIMPLE_FLAGS) ||
> - txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
> + if ((txq->offloads & i40e_simple_ol_mask) != 0 ||
> + txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
>   PMD_DRV_LOG(ERR, "No-simple tx is required.");
>   return -EINVAL;
>   }
> @@ -3080,18 +3080,21 @@ i40e_set_tx_function_flag(struct rte_eth_dev *dev, 
> struct i40e_tx_queue *txq)
>   I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> 
>   /* Use a simple Tx queue (no offloads, no multi segs) if possible */
> - if (((txq->txq_flags & I40E_SIMPLE_FLAGS) == I40E_SIMPLE_FLAGS)
> - && (txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST)) {
> - if (txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ) {
> - PMD_INIT_LOG(DEBUG, "Vector tx"
> -  " can be enabled on this txq.");
> -
> - } else {
> - ad->tx_vec_allowed = false;
> - }
> - } else {
> - ad->tx_simple_allowed = false;
> - }
> + ad->tx_simple_allowed = ((txq->offloads & i40e_simple_ol_mask) == 0 &&
> + txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST);
> + ad->tx_vec_allowed = (ad->tx_simple_allowed &&
> + txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ);
> +
> + if (ad->tx_vec_allowed)
> + PMD_INIT_LOG(DEBUG, "Vector Tx can be enabled on Tx queue %u.",
> +   

Re: [dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Bruce Richardson
On Tue, May 01, 2018 at 02:24:39PM +0100, Ananyev, Konstantin wrote:
> Hi Bruce,
> 
> > 
> > The Tx function selection code in the driver only used the older txq
> > flags values to check whether the scalar or vector functions should be
> > used. This caused performance regressions with testpmd io-fwd as the
> > scalar path rather than the vector one was being used in the default
> > case. Fix this by changing the code to take account of new offloads and
> > deleting the defines used for the old ones.
> > 
> > Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> >  drivers/net/i40e/i40e_rxtx.c | 45 
> > +++-
> >  1 file changed, 24 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > index ec1ce54ca..c523af575 100644
> > --- a/drivers/net/i40e/i40e_rxtx.c
> > +++ b/drivers/net/i40e/i40e_rxtx.c
> > @@ -40,9 +40,6 @@
> >  /* Base address of the HW descriptor ring should be 128B aligned. */
> >  #define I40E_RING_BASE_ALIGN   128
> > 
> > -#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> > -   ETH_TXQ_FLAGS_NOOFFLOADS)
> > -
> >  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> > 
> >  #ifdef RTE_LIBRTE_IEEE1588
> > @@ -70,6 +67,12 @@
> >  #define I40E_TX_OFFLOAD_NOTSUP_MASK \
> > (PKT_TX_OFFLOAD_MASK ^ I40E_TX_OFFLOAD_MASK)
> > 
> > +static const uint64_t i40e_simple_ol_mask = (DEV_TX_OFFLOAD_MULTI_SEGS |
> > +   DEV_TX_OFFLOAD_VLAN_INSERT |
> > +   DEV_TX_OFFLOAD_SCTP_CKSUM |
> > +   DEV_TX_OFFLOAD_UDP_CKSUM |
> > +   DEV_TX_OFFLOAD_TCP_CKSUM);
> > +
> 
> Seems incomplete.
> From i40e_ethdev.c full-featured tx supports:
> dev_info->tx_offload_capa =
> DEV_TX_OFFLOAD_VLAN_INSERT |
> DEV_TX_OFFLOAD_QINQ_INSERT |
> DEV_TX_OFFLOAD_IPV4_CKSUM |
> DEV_TX_OFFLOAD_UDP_CKSUM |
> DEV_TX_OFFLOAD_TCP_CKSUM |
> DEV_TX_OFFLOAD_SCTP_CKSUM |
> DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM |
> DEV_TX_OFFLOAD_TCP_TSO |
> DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
> DEV_TX_OFFLOAD_GRE_TNL_TSO |
> DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> 
> So we probably need the same here plus multiseg.
> BTW, it is really strange that we don't have multiseg in tx_offload_capa.
> Should be present I think.
> Might be worse to create a new define for it, or just use 
> dev_info->tx_offload_capa directly.
> Konstantin
> 
Thanks, good point, I never thought to check the advertised capabilities. I
just translated what was being used by the old code txq_flags translation 
function. I'll clean this up and do a V2.

/Bruce


[dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Ferruh Yigit
Many sample applications fail because of
dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()

The sample applications need to be fixed/updated before returning error
on rte_eth_dev_configure()

This patch keeps the error log but removes returning error.

Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
Cc: xuemi...@mellanox.com

Signed-off-by: Ferruh Yigit 
---
 lib/librte_ethdev/rte_ethdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 59810dde8..5a67e6a7d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -1148,7 +1148,6 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
port_id,
dev_conf->rx_adv_conf.rss_conf.rss_hf,
dev_info.flow_type_rss_offloads);
-   return -EINVAL;
}
 
/*
-- 
2.14.3



[dpdk-dev] [PATCH] igb_uio: pass MODULE_CFLAGS in new Kbuild

2018-05-01 Thread luca . boccassi
From: Luca Boccassi 

With the legacy build system MODULE_CFLAGS can be set to pass compiler
flags specific for the kernel modules builds.
This is used currently by Ubuntu and Debian.
Set ccflags-y in the Kbuild to achieve the same result with Meson, and
to keep backward compatbility with older scripts.

Fixes regression in Ubuntu/Debian when the Kbuild is included in the
DKMS source package, as DKMS will pick it up silently by default if
present, causing the MODULE_CFLAGS to be ignored.

Fixes: a52f4574f798 ("igb_uio: build with meson")
Cc: sta...@dpdk.org
---
 kernel/linux/igb_uio/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/linux/igb_uio/Kbuild b/kernel/linux/igb_uio/Kbuild
index 98c98fe52..3ab85c411 100644
--- a/kernel/linux/igb_uio/Kbuild
+++ b/kernel/linux/igb_uio/Kbuild
@@ -1 +1,2 @@
+ccflags-y := $(MODULE_CFLAGS)
 obj-m := igb_uio.o
-- 
2.14.2



Re: [dpdk-dev] [PATCH] igb_uio: pass MODULE_CFLAGS in new Kbuild

2018-05-01 Thread Richardson, Bruce


> -Original Message-
> From: luca.bocca...@gmail.com [mailto:luca.bocca...@gmail.com]
> Sent: Tuesday, May 1, 2018 2:39 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce ; Luca Boccassi
> ; sta...@dpdk.org
> Subject: [PATCH] igb_uio: pass MODULE_CFLAGS in new Kbuild
> 
> From: Luca Boccassi 
> 
> With the legacy build system MODULE_CFLAGS can be set to pass compiler
> flags specific for the kernel modules builds.
> This is used currently by Ubuntu and Debian.
> Set ccflags-y in the Kbuild to achieve the same result with Meson, and to
> keep backward compatbility with older scripts.
> 
> Fixes regression in Ubuntu/Debian when the Kbuild is included in the DKMS
> source package, as DKMS will pick it up silently by default if present,
> causing the MODULE_CFLAGS to be ignored.
> 
> Fixes: a52f4574f798 ("igb_uio: build with meson")
> Cc: sta...@dpdk.org
> ---
>  kernel/linux/igb_uio/Kbuild | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/linux/igb_uio/Kbuild b/kernel/linux/igb_uio/Kbuild
> index 98c98fe52..3ab85c411 100644
> --- a/kernel/linux/igb_uio/Kbuild
> +++ b/kernel/linux/igb_uio/Kbuild
> @@ -1 +1,2 @@
> +ccflags-y := $(MODULE_CFLAGS)
>  obj-m := igb_uio.o

Acked-by: Bruce Richardson 


Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Xueming(Steven) Li
Looks good, thanks.

How do you think rss_hf, normally people think it best effort.

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, May 1, 2018 9:34 PM
> To: Thomas Monjalon 
> Cc: dev@dpdk.org; Ferruh Yigit ; Xueming(Steven) Li 
> 
> Subject: [PATCH] ethdev: fix applications failure on configure
> 
> Many sample applications fail because of dev_info.flow_type_rss_offloads 
> check in
> rte_eth_dev_configure()
> 
> The sample applications need to be fixed/updated before returning error on 
> rte_eth_dev_configure()
> 
> This patch keeps the error log but removes returning error.
> 
> Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
> Cc: xuemi...@mellanox.com
> 
> Signed-off-by: Ferruh Yigit 
> ---
>  lib/librte_ethdev/rte_ethdev.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c 
> index
> 59810dde8..5a67e6a7d 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -1148,7 +1148,6 @@ rte_eth_dev_configure(uint16_t port_id, uint16_t 
> nb_rx_q, uint16_t nb_tx_q,
>   port_id,
>   dev_conf->rx_adv_conf.rss_conf.rss_hf,
>   dev_info.flow_type_rss_offloads);
> - return -EINVAL;
>   }
> 
>   /*
> --
> 2.14.3



[dpdk-dev] [PATCH v2] igb_uio: pass MODULE_CFLAGS in new Kbuild

2018-05-01 Thread luca . boccassi
From: Luca Boccassi 

With the legacy build system MODULE_CFLAGS can be set to pass compiler
flags specific for the kernel modules builds.
This is used currently by Ubuntu and Debian.
Set ccflags-y in the Kbuild to achieve the same result with Meson, and
to keep backward compatbility with older scripts.

Fixes regression in Ubuntu/Debian when the Kbuild is included in the
DKMS source package, as DKMS will pick it up silently by default if
present, causing the MODULE_CFLAGS to be ignored.

Fixes: a52f4574f798 ("igb_uio: build with meson")
Cc: sta...@dpdk.org

Signed-off-by: Luca Boccassi 
Acked-by: Bruce Richardson 
---
v2: forgot --signed-off, added

 kernel/linux/igb_uio/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/linux/igb_uio/Kbuild b/kernel/linux/igb_uio/Kbuild
index 98c98fe52..3ab85c411 100644
--- a/kernel/linux/igb_uio/Kbuild
+++ b/kernel/linux/igb_uio/Kbuild
@@ -1 +1,2 @@
+ccflags-y := $(MODULE_CFLAGS)
 obj-m := igb_uio.o
-- 
2.14.2



Re: [dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Bruce Richardson
On Tue, May 01, 2018 at 02:24:39PM +0100, Ananyev, Konstantin wrote:
> Hi Bruce,
> 
> > 
> > The Tx function selection code in the driver only used the older txq
> > flags values to check whether the scalar or vector functions should be
> > used. This caused performance regressions with testpmd io-fwd as the
> > scalar path rather than the vector one was being used in the default
> > case. Fix this by changing the code to take account of new offloads and
> > deleting the defines used for the old ones.
> > 
> > Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> >  drivers/net/i40e/i40e_rxtx.c | 45 
> > +++-
> >  1 file changed, 24 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > index ec1ce54ca..c523af575 100644
> > --- a/drivers/net/i40e/i40e_rxtx.c
> > +++ b/drivers/net/i40e/i40e_rxtx.c
> > @@ -40,9 +40,6 @@
> >  /* Base address of the HW descriptor ring should be 128B aligned. */
> >  #define I40E_RING_BASE_ALIGN   128
> > 
> > -#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> > -   ETH_TXQ_FLAGS_NOOFFLOADS)
> > -
> >  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> > 
> >  #ifdef RTE_LIBRTE_IEEE1588
> > @@ -70,6 +67,12 @@
> >  #define I40E_TX_OFFLOAD_NOTSUP_MASK \
> > (PKT_TX_OFFLOAD_MASK ^ I40E_TX_OFFLOAD_MASK)
> > 
> > +static const uint64_t i40e_simple_ol_mask = (DEV_TX_OFFLOAD_MULTI_SEGS |
> > +   DEV_TX_OFFLOAD_VLAN_INSERT |
> > +   DEV_TX_OFFLOAD_SCTP_CKSUM |
> > +   DEV_TX_OFFLOAD_UDP_CKSUM |
> > +   DEV_TX_OFFLOAD_TCP_CKSUM);
> > +
> 
> Seems incomplete.
> From i40e_ethdev.c full-featured tx supports:
> dev_info->tx_offload_capa =
> DEV_TX_OFFLOAD_VLAN_INSERT |
> DEV_TX_OFFLOAD_QINQ_INSERT |
> DEV_TX_OFFLOAD_IPV4_CKSUM |
> DEV_TX_OFFLOAD_UDP_CKSUM |
> DEV_TX_OFFLOAD_TCP_CKSUM |
> DEV_TX_OFFLOAD_SCTP_CKSUM |
> DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM |
> DEV_TX_OFFLOAD_TCP_TSO |
> DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
> DEV_TX_OFFLOAD_GRE_TNL_TSO |
> DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> 
> So we probably need the same here plus multiseg.
> BTW, it is really strange that we don't have multiseg in tx_offload_capa.
> Should be present I think.
> Might be worse to create a new define for it, or just use 
> dev_info->tx_offload_capa directly.
> Konstantin
> 
Thinking about this more, it seems that right now we don't need a masks at
all. Any bits set in the offloads is going to cause us to use the scalar
path or to error out with an invalid offload requested. Yes, it's not
future-proofed in that it will need to be changed if we do end up
supporting some offloads with the vector path in future, but then the same
problem would occur if we just re-use the advertised capabilities too, like
you suggest.

Therefore I think for V2 we'll just check for a non-zero offloads value.

/Bruce


[dpdk-dev] ethdev new offloading API switch in PMDs

2018-05-01 Thread Ferruh Yigit
Hi,

Following PMDs still has .txq_flags in use, after basic grep, no in-dept
investigation done.

With PMDs switch to new API, that flag no longer should be needed.

Old applications still use it but ethdev converts them to the offloads, so that
PMDs can only concern about offloads.

Can maintainer of following PMDs please check their offloading API 
implementation:

axgbe
bnxt
e1000
ena
failsafe
fm10k
i40e
ixgbe
mlx4
mlx5
octeontx
qede
sfc
tap
thunderx
virtio
vmxnet3


Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Thomas Monjalon
01/05/2018 15:33, Ferruh Yigit:
> Many sample applications fail because of
> dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()

We need to define the API behaviour in doxygen.

> The sample applications need to be fixed/updated before returning error
> on rte_eth_dev_configure()
> 
> This patch keeps the error log but removes returning error.

If the doc is updated in 18.05, we can have a deprecation notice
to insert the error return in 18.08.

> Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
> Cc: xuemi...@mellanox.com
> 
> Signed-off-by: Ferruh Yigit 





Re: [dpdk-dev] [PATCH v5 1/2] ethdev: add supported hash function check

2018-05-01 Thread Thomas Monjalon
01/05/2018 13:04, Ferruh Yigit:
> On 4/23/2018 7:14 PM, Thomas Monjalon wrote:
> > 23/04/2018 18:06, Ferruh Yigit:
> >> On 4/20/2018 3:30 PM, Xueming Li wrote:
> >>> Add supported RSS hash function check in device configuration to
> >>> have better error verbosity for application developers.
> >>>
> >>> Signed-off-by: Xueming Li 
> >>> Acked-by: Adrien Mazarguil 
> >>>  
> >>> + /* Check that device supports requested rss hash functions. */
> >>> + if ((dev_info.flow_type_rss_offloads |
> >>> +  dev_conf->rx_adv_conf.rss_conf.rss_hf) !=
> >>> + dev_info.flow_type_rss_offloads) {
> >>> + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d invalid rss_hf: "
> >>> + "0x%"PRIx64", valid value: 0x%"PRIx64"\n",
> >>> + port_id,
> >>> + dev_conf->rx_adv_conf.rss_conf.rss_hf,
> >>> + dev_info.flow_type_rss_offloads);
> >>> + return -EINVAL;
> >>> + }
> >>
> >> Hi Thomas,
> >>
> >> This can break the PMDs that are not setting flow_type_rss_offloads 
> >> properly.
> >> How can we highlight this so that PMD owners can double check?
> > 
> > Can we have a check-list in the RC1 announce email?
> 
> Hi Thomas, Xueming,
> 
> This change is breaking multiple sample applications, testpmd was also broken
> but already fixed by Qi [1].
> 
> Indeed this patch should update sample applications and testpmd as well when
> doing an ethdev API update, also should update release notes "API Changes" 
> section.
> 
> We can fix sample applications for rc2, but same thing also can hit users.
> 
> Or for this release we can remote returning error, instead update log message 
> to
> error. Next release add the return and change log message back to debug.
> 
> What do you think?

Yes:
1/ update the API doc and sample apps in 18.05
2/ send a deprecation notice
3/ add error return in 18.08

I've  replied to your patch too:
http://dpdk.org/ml/archives/dev/2018-May/099865.html




Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 3:01 PM, Thomas Monjalon wrote:
> 01/05/2018 15:33, Ferruh Yigit:
>> Many sample applications fail because of
>> dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()
> 
> We need to define the API behaviour in doxygen.
> 
>> The sample applications need to be fixed/updated before returning error
>> on rte_eth_dev_configure()
>>
>> This patch keeps the error log but removes returning error.
> 
> If the doc is updated in 18.05, we can have a deprecation notice
> to insert the error return in 18.08.

+1 to add a deprecation notice for this release and do the error return on 
18.08.

Is the doc update you mentioned doxygen update?

Who can do doc update and deprecation notice patches for this release?

> 
>> Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
>> Cc: xuemi...@mellanox.com
>>
>> Signed-off-by: Ferruh Yigit 


Re: [dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Ananyev, Konstantin


> -Original Message-
> From: Richardson, Bruce
> Sent: Tuesday, May 1, 2018 2:53 PM
> To: Ananyev, Konstantin 
> Cc: Xing, Beilei ; Zhang, Qi Z ; 
> dev@dpdk.org; Yigit, Ferruh 
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix Tx fn selection when using new 
> ethdev offloads
> 
> On Tue, May 01, 2018 at 02:24:39PM +0100, Ananyev, Konstantin wrote:
> > Hi Bruce,
> >
> > >
> > > The Tx function selection code in the driver only used the older txq
> > > flags values to check whether the scalar or vector functions should be
> > > used. This caused performance regressions with testpmd io-fwd as the
> > > scalar path rather than the vector one was being used in the default
> > > case. Fix this by changing the code to take account of new offloads and
> > > deleting the defines used for the old ones.
> > >
> > > Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> > >
> > > Signed-off-by: Bruce Richardson 
> > > ---
> > >  drivers/net/i40e/i40e_rxtx.c | 45 
> > > +++-
> > >  1 file changed, 24 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > > index ec1ce54ca..c523af575 100644
> > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > @@ -40,9 +40,6 @@
> > >  /* Base address of the HW descriptor ring should be 128B aligned. */
> > >  #define I40E_RING_BASE_ALIGN 128
> > >
> > > -#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> > > - ETH_TXQ_FLAGS_NOOFFLOADS)
> > > -
> > >  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> > >
> > >  #ifdef RTE_LIBRTE_IEEE1588
> > > @@ -70,6 +67,12 @@
> > >  #define I40E_TX_OFFLOAD_NOTSUP_MASK \
> > >   (PKT_TX_OFFLOAD_MASK ^ I40E_TX_OFFLOAD_MASK)
> > >
> > > +static const uint64_t i40e_simple_ol_mask = (DEV_TX_OFFLOAD_MULTI_SEGS |
> > > + DEV_TX_OFFLOAD_VLAN_INSERT |
> > > + DEV_TX_OFFLOAD_SCTP_CKSUM |
> > > + DEV_TX_OFFLOAD_UDP_CKSUM |
> > > + DEV_TX_OFFLOAD_TCP_CKSUM);
> > > +
> >
> > Seems incomplete.
> > From i40e_ethdev.c full-featured tx supports:
> > dev_info->tx_offload_capa =
> > DEV_TX_OFFLOAD_VLAN_INSERT |
> > DEV_TX_OFFLOAD_QINQ_INSERT |
> > DEV_TX_OFFLOAD_IPV4_CKSUM |
> > DEV_TX_OFFLOAD_UDP_CKSUM |
> > DEV_TX_OFFLOAD_TCP_CKSUM |
> > DEV_TX_OFFLOAD_SCTP_CKSUM |
> > DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM |
> > DEV_TX_OFFLOAD_TCP_TSO |
> > DEV_TX_OFFLOAD_VXLAN_TNL_TSO |
> > DEV_TX_OFFLOAD_GRE_TNL_TSO |
> > DEV_TX_OFFLOAD_IPIP_TNL_TSO |
> > DEV_TX_OFFLOAD_GENEVE_TNL_TSO;
> >
> > So we probably need the same here plus multiseg.
> > BTW, it is really strange that we don't have multiseg in tx_offload_capa.
> > Should be present I think.
> > Might be worse to create a new define for it, or just use 
> > dev_info->tx_offload_capa directly.
> > Konstantin
> >
> Thinking about this more, it seems that right now we don't need a masks at
> all. Any bits set in the offloads is going to cause us to use the scalar
> path or to error out with an invalid offload requested. Yes, it's not
> future-proofed in that it will need to be changed if we do end up
> supporting some offloads with the vector path in future, but then the same
> problem would occur if we just re-use the advertised capabilities too, like
> you suggest.
> 
> Therefore I think for V2 we'll just check for a non-zero offloads value.

Ok by me.
Konstantin



Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Thomas Monjalon
01/05/2018 16:08, Ferruh Yigit:
> On 5/1/2018 3:01 PM, Thomas Monjalon wrote:
> > 01/05/2018 15:33, Ferruh Yigit:
> >> Many sample applications fail because of
> >> dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()
> > 
> > We need to define the API behaviour in doxygen.
> > 
> >> The sample applications need to be fixed/updated before returning error
> >> on rte_eth_dev_configure()
> >>
> >> This patch keeps the error log but removes returning error.
> > 
> > If the doc is updated in 18.05, we can have a deprecation notice
> > to insert the error return in 18.08.
> 
> +1 to add a deprecation notice for this release and do the error return on 
> 18.08.
> 
> Is the doc update you mentioned doxygen update?

Yes, doxygen update.

> Who can do doc update and deprecation notice patches for this release?

Either you Ferruh, or Xueming and me together.
What do you prefer?

> >> Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
> >> Cc: xuemi...@mellanox.com
> >>
> >> Signed-off-by: Ferruh Yigit 





[dpdk-dev] [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Bruce Richardson
The Tx function selection code in the driver only used the older txq
flags values to check whether the scalar or vector functions should be
used. This caused performance regressions with testpmd io-fwd as the
scalar path rather than the vector one was being used in the default
case. Fix this by changing the code to take account of new offloads and
deleting the defines used for the old ones.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")

Signed-off-by: Bruce Richardson 
---
 drivers/net/i40e/i40e_rxtx.c | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index ec1ce54ca..006f5b846 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -40,9 +40,6 @@
 /* Base address of the HW descriptor ring should be 128B aligned. */
 #define I40E_RING_BASE_ALIGN   128
 
-#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
-   ETH_TXQ_FLAGS_NOOFFLOADS)
-
 #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
 
 #ifdef RTE_LIBRTE_IEEE1588
@@ -2108,11 +2105,9 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
 dev->data->nb_tx_queues)) {
/**
 * If it is the first queue to setup,
-* set all flags to default and call
+* set all flags and call
 * i40e_set_tx_function.
 */
-   ad->tx_simple_allowed = true;
-   ad->tx_vec_allowed = true;
i40e_set_tx_function_flag(dev, txq);
i40e_set_tx_function(dev);
return 0;
@@ -2128,9 +2123,8 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
}
/* check simple tx conflict */
if (ad->tx_simple_allowed) {
-   if (((txq->txq_flags & I40E_SIMPLE_FLAGS) !=
-I40E_SIMPLE_FLAGS) ||
-   txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
+   if (txq->offloads != 0 ||
+   txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
PMD_DRV_LOG(ERR, "No-simple tx is required.");
return -EINVAL;
}
@@ -3080,18 +3074,21 @@ i40e_set_tx_function_flag(struct rte_eth_dev *dev, 
struct i40e_tx_queue *txq)
I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
 
/* Use a simple Tx queue (no offloads, no multi segs) if possible */
-   if (((txq->txq_flags & I40E_SIMPLE_FLAGS) == I40E_SIMPLE_FLAGS)
-   && (txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST)) {
-   if (txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ) {
-   PMD_INIT_LOG(DEBUG, "Vector tx"
-" can be enabled on this txq.");
-
-   } else {
-   ad->tx_vec_allowed = false;
-   }
-   } else {
-   ad->tx_simple_allowed = false;
-   }
+   ad->tx_simple_allowed = (txq->offloads == 0 &&
+   txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST);
+   ad->tx_vec_allowed = (ad->tx_simple_allowed &&
+   txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ);
+
+   if (ad->tx_vec_allowed)
+   PMD_INIT_LOG(DEBUG, "Vector Tx can be enabled on Tx queue %u.",
+   txq->queue_id);
+   else if (ad->tx_simple_allowed)
+   PMD_INIT_LOG(DEBUG, "Simple Tx can be enabled on Tx queue %u.",
+   txq->queue_id);
+   else
+   PMD_INIT_LOG(DEBUG,
+   "Neither simple nor vector Tx enabled on Tx 
queue %u\n",
+   txq->queue_id);
 }
 
 void __attribute__((cold))
-- 
2.14.3



Re: [dpdk-dev] [dpdk-web] [PATCH v2] update stable releases roadmap

2018-05-01 Thread Aaron Conole
Thomas Monjalon  writes:

> 25/04/2018 12:03, Luca Boccassi:
>> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
>> > On 4/20/2018 4:52 PM, Aaron Conole wrote:
>> > > Kevin Traynor  writes:
>> > > > On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>> > > > > 18/04/2018 14:28, Ferruh Yigit:
>> > > > > > On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
>> > > > > > > 18/04/2018 11:05, Ferruh Yigit:
>> > > > > > > > On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>> > > > > > > > > -Typically a new stable release version
>> > > > > > > > > follows a mainline release
>> > > > > > > > > -by 1-2 weeks, depending on the test results.
>> > > > > > > > > +The first stable release (.1) of a branch
>> > > > > > > > > should follow
>> > > > > > > > > +its mainline release (.0) by at least two
>> > > > > > > > > months,
>> > > > > > > > > +after the first release candidate (-rc1) of
>> > > > > > > > > the next branch.
>> > > > > > > > 
>> > > > > > > > Hi Thomas,
>> > > > > > > > 
>> > > > > > > > What this change suggest? To be able to backport patches
>> > > > > > > > from rc1?
>> > > > > > > 
>> > > > > > > Yes, it is the proposal we discussed earlier.
>> > > > > > > We can wait one week after RC1 to get some validation
>> > > > > > > confirmation.
>> > > > > > > Do you agree?
>> > > > > > 
>> > > > > > This has been discussed in tech-board, what I remember the
>> > > > > > decision was to wait
>> > > > > > the release to backport patches into stable tree.
>> > > > 
>> > > > Any minutes? I couldn't find them
>> > > > 
>> > > > > It was not so clear to me.
>> > > > > I thought post-rc1 was acceptable. The idea is to speed-up
>> > > > > stable releases
>> > > > > pace, especially first release of a series.
>> > > > > 
>> > > > > 
>> > > > 
>> > > > I think timing of stable releases and bugfix backports to the
>> > > > stable
>> > > > branch are two separate items.
>> > > > 
>> > > > I do think that bugfix backports to stable should happen on a
>> > > > regular
>> > > > basis (e.g. every 2 weeks). Otherwise we are back to the
>> > > > situation where
>> > > > if there's a bugfix after a DPDK release, a user like (surprise,
>> > > > surprise) OVS may not be able to use that DPDK version for ~3
>> > > > months.
>> > > > 
>> > > > Someone who wants to get the latest bugfixes can just take the
>> > > > latest on
>> > > > the stable branch and importantly, can have confidence that the
>> > > > community has officially accepted those patches. If someone
>> > > > requires
>> > > > stable to be validated, then they have to wait until the release.
>> > > 
>> > > +1 - this seems to make the most sense to me.  Keep the patches
>> > > flowing,
>> > > but don't label/tag it until validation.  That serves an additional
>> > > function: developers know their CC's to stable are being processed.
>> > 
>> > Are stable trees verified?
>> 
>> Verification is one issue - so far, Intel and ATT have provided time
>> and resources to do some regression tests, but only at release time
>> (before tagging). And it has been a manual process.
>> It would be great if more companies would step up to help - and even
>> better if regressions could be automated (nightly job?).
>> 
>> The other issue is deciding when a patch is "good to go" - until now,
>> the criteria has been "when it's merged into master".
>> So either that criteria needs to change, and another equally
>> "authoritative" is decided on, or patches should get reviewed and
>> merged in master more often and more quickly :-P
>> 
>> We also have not been looking directly at the the various -next trees,
>> as things are more "in-flux" there and could be reverted, or clash with
>> changes from other trees - hence why we merge from master.
>
> Yes, backporting from master is definitely the right thing to do.
> Backporting more regularly would be also an improvement.
> There will be always the question of the bug-free ideal in stable
> branches. I agree we need more help to validate the stable branches.
> But realistically, it will never be perfect.
>
> So the questions are:
>   - What we must wait before pushing a backport in the stable tree?
>   - What we must wait before tagging a stable release?
>
> I think it is reasonnable to push backports one or two weeks after
> it is in the master branch, assuming master is tested by the community.
> If a corner case is found later, it will be fixed with another patch.

+1 - I agree here.  Folks who truly care about 'validated stable'
(whatever definition that takes) will only use a labeled version anyway.

OTOH, developers who want to see that their patches are landing in
stable (and more over, who want to ensure that their proposed backports
are actually complete - which is more relevant w.r.t. hardware),
shouldn't have to wait for the label.

Most other projects work this way, as well.  Keep pulling in the
relevant patches from master to the stable branch(es).  Do the official
label / release at a certain point in time 

Re: [dpdk-dev] [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Bruce Richardson
On Tue, May 01, 2018 at 03:13:54PM +0100, Bruce Richardson wrote:
> The Tx function selection code in the driver only used the older txq
> flags values to check whether the scalar or vector functions should be
> used. This caused performance regressions with testpmd io-fwd as the
> scalar path rather than the vector one was being used in the default
> case. Fix this by changing the code to take account of new offloads and
> deleting the defines used for the old ones.
> 
> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> 
> Signed-off-by: Bruce Richardson 
> ---
Apologies: forgot to add:

v2: eliminate mask for offload flags, and use vector path only if 
offloads == 0


Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 3:12 PM, Thomas Monjalon wrote:
> 01/05/2018 16:08, Ferruh Yigit:
>> On 5/1/2018 3:01 PM, Thomas Monjalon wrote:
>>> 01/05/2018 15:33, Ferruh Yigit:
 Many sample applications fail because of
 dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()
>>>
>>> We need to define the API behaviour in doxygen.
>>>
 The sample applications need to be fixed/updated before returning error
 on rte_eth_dev_configure()

 This patch keeps the error log but removes returning error.
>>>
>>> If the doc is updated in 18.05, we can have a deprecation notice
>>> to insert the error return in 18.08.
>>
>> +1 to add a deprecation notice for this release and do the error return on 
>> 18.08.
>>
>> Is the doc update you mentioned doxygen update?
> 
> Yes, doxygen update.
> 
>> Who can do doc update and deprecation notice patches for this release?
> 
> Either you Ferruh, or Xueming and me together.
> What do you prefer?

Or as Xueming suggested, we can take rss_hf config as best effort and not return
error at all.

I think this forces PMDs to have up-to-date flow_type_rss_offloads values, is
there any other benefit?
What was the initial motivation to add error return on this check?

> 
 Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
 Cc: xuemi...@mellanox.com

 Signed-off-by: Ferruh Yigit 
> 
> 
> 



Re: [dpdk-dev] [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 3:16 PM, Bruce Richardson wrote:
> On Tue, May 01, 2018 at 03:13:54PM +0100, Bruce Richardson wrote:
>> The Tx function selection code in the driver only used the older txq
>> flags values to check whether the scalar or vector functions should be
>> used. This caused performance regressions with testpmd io-fwd as the
>> scalar path rather than the vector one was being used in the default
>> case. Fix this by changing the code to take account of new offloads and
>> deleting the defines used for the old ones.
>>
>> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
>>
>> Signed-off-by: Bruce Richardson 
>> ---
> Apologies: forgot to add:
> 
> v2: eliminate mask for offload flags, and use vector path only if 
> offloads == 0
> 

Reviewed-by: Ferruh Yigit 


Re: [dpdk-dev] [PATCH] net/vmxnet3: convert to new rx offload api

2018-05-01 Thread Ferruh Yigit
On 4/30/2018 11:20 PM, Louis Luo wrote:
> Ethdev RX offloads API has changed since: commit ce17eddefc20
> ("ethdev: introduce Rx queue offloads API")
> 
> This patch adopts the new RX Offload API in vmxnet3 driver.
>
> Signed-off-by: Louis Luo 

Hi Louis,

Overall patch looks good, only there is 32bits build error because of logging,
more details below.

Can you please send a new version of the patch, keeping Yong's ack.

<...>

> @@ -376,9 +393,25 @@ vmxnet3_dev_configure(struct rte_eth_dev *dev)
>   const struct rte_memzone *mz;
>   struct vmxnet3_hw *hw = dev->data->dev_private;
>   size_t size;
> + uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
> + uint64_t tx_offloads = dev->data->dev_conf.txmode.offloads;
>  
>   PMD_INIT_FUNC_TRACE();
>  
> + if ((rx_offloads & VMXNET3_RX_OFFLOAD_CAP) != rx_offloads) {
> + RTE_LOG(ERR, PMD, "Requested RX offloads 0x%lx"
> + " do not match supported 0x%lx\n",
> + rx_offloads, (uint64_t)VMXNET3_RX_OFFLOAD_CAP);

%lx usage causing build error with 32bit build [1], please prefer PRIx64.

[1]
 argument of type "uint64_t={__uint64_t={unsigned long long}}" is incompatible
with format "%lx", expecting argument of type "unsigned long"

<...>


Re: [dpdk-dev] [dpdk-stable] [PATCH v2] igb_uio: pass MODULE_CFLAGS in new Kbuild

2018-05-01 Thread Thomas Monjalon
01/05/2018 15:50, luca.bocca...@gmail.com:
> From: Luca Boccassi 
> 
> With the legacy build system MODULE_CFLAGS can be set to pass compiler
> flags specific for the kernel modules builds.
> This is used currently by Ubuntu and Debian.
> Set ccflags-y in the Kbuild to achieve the same result with Meson, and
> to keep backward compatbility with older scripts.
> 
> Fixes regression in Ubuntu/Debian when the Kbuild is included in the
> DKMS source package, as DKMS will pick it up silently by default if
> present, causing the MODULE_CFLAGS to be ignored.
> 
> Fixes: a52f4574f798 ("igb_uio: build with meson")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Luca Boccassi 
> Acked-by: Bruce Richardson 

Applied, thanks





Re: [dpdk-dev] [PATCH] ethdev: Fix issue in Doxygen for TM API

2018-05-01 Thread Dumitrescu, Cristian


> -Original Message-
> From: Shelton, Benjamin H
> Sent: Wednesday, March 21, 2018 3:46 PM
> To: dev@dpdk.org; Dumitrescu, Cristian 
> Cc: Shelton, Benjamin H 
> Subject: [PATCH] ethdev: Fix issue in Doxygen for TM API
> 
> The rte_tm_node_wfq_weight_mode_update() API function operates on
> non-leaf nodes, not leaf nodes.
> 
> Signed-off-by: Ben Shelton 
> ---
>  lib/librte_ether/rte_tm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_ether/rte_tm.h b/lib/librte_ether/rte_tm.h
> index 2b25a87..f735f84 100644
> --- a/lib/librte_ether/rte_tm.h
> +++ b/lib/librte_ether/rte_tm.h
> @@ -1643,7 +1643,7 @@ rte_tm_node_stats_update(uint16_t port_id,
>   * @param[in] port_id
>   *   The port identifier of the Ethernet device.
>   * @param[in] node_id
> - *   Node ID. Needs to be valid leaf node ID.
> + *   Node ID. Needs to be valid non-leaf node ID.
>   * @param[in] wfq_weight_mode
>   *   WFQ weight mode for each SP priority. When NULL, it indicates that
> WFQ is
>   *   to be used for all priorities. When non-NULL, it points to a 
> pre-allocated
> --
> 2.6.4

Acked-by: Cristian Dumitrescu 

Applied to next-qos tree, thanks!



Re: [dpdk-dev] [PATCH] ethdev: add support for WRED thresholds in bytes

2018-05-01 Thread Dumitrescu, Cristian


> -Original Message-
> From: Rao, Nikhil
> Sent: Tuesday, February 20, 2018 1:31 PM
> To: Dumitrescu, Cristian 
> Cc: dev@dpdk.org; Shelton, Benjamin H ;
> Vangati, Narender ; Gujjar, Abhinandan S
> ; Rao, Nikhil 
> Subject: [PATCH] ethdev: add support for WRED thresholds in bytes
> 
> WRED thresholds can be specified in bytes if the TM leaf
> node supports it. Also extend WRED thresholds to 32 bits from 16.
> 
> TM capability (port/level/queue) fields
> cman_wred_packet_mode_supported and
> cman_wred_byte_mode_supported, when non-zero, indicate support for
> WRED
> thresholds in packets and bytes respectively.
> 
> The packet_mode member of struct rte_tm_wred_params, when non-zero,
> indicates that the min and max thresholds are specified in
> packets and when zero, indicates that the min and max thresholds
> are specified in bytes.
> 
> Signed-off-by: Nikhil Rao 
> ---
> 
> Thanks to Cristian for his help with developing this patch.
> 
>  lib/librte_ether/rte_tm.h| 53
> ++--
>  drivers/net/softnic/rte_eth_softnic_tm.c | 22 +
>  2 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/librte_ether/rte_tm.h b/lib/librte_ether/rte_tm.h
> index 2b25a87..23098ab 100644
> --- a/lib/librte_ether/rte_tm.h
> +++ b/lib/librte_ether/rte_tm.h
> @@ -377,6 +377,22 @@ struct rte_tm_capabilities {
>*/
>   uint32_t sched_wfq_weight_max;
> 
> + /** WRED packet mode support. When non-zero, this parameter
> indicates
> +  * that there is atleast one leaf node that supports the WRED packet
> +  * mode, which might not be true for all the leaf nodes. In packet
> +  * mode, the WRED thresholds specify the queue length in packets,
> as
> +  * opposed to bytes.
> +  */
> + int cman_wred_packet_mode_supported;
> +
> + /** WRED byte mode support. When non-zero, this parameter
> indicates that
> +  * there is atleast one leaf node that supports the WRED byte mode,
> +  * which might not be true for all the leaf nodes. In byte mode, the
> +  * WRED thresholds specify the queue length in bytes, as opposed to
> +  * packets.
> +  */
> + int cman_wred_byte_mode_supported;
> +
>   /** Head drop algorithm support. When non-zero, this parameter
>* indicates that there is at least one leaf node that supports the
> head
>* drop algorithm, which might not be true for all the leaf nodes.
> @@ -628,6 +644,24 @@ struct rte_tm_level_capabilities {
>*/
>   uint32_t shaper_shared_n_max;
> 
> + /** WRED packet mode support. When non-zero,
> this
> +  * parameter indicates that there is atleast one leaf
> +  * node on this level that supports the WRED packet
> +  * mode, which might not be true for all the leaf
> +  * nodes. In packet mode, the WRED thresholds
> specify
> +  * the queue length in packets, as opposed to bytes.
> +  */
> + int cman_wred_packet_mode_supported;
> +
> + /** WRED byte mode support. When non-zero, this
> +  * parameter indicates that there is atleast one leaf
> +  * node on this level that supports the WRED byte
> mode,
> +  * which might not be true for all the leaf nodes. In
> +  * byte mode, the WRED thresholds specify the
> queue
> +  * length in bytes, as opposed to packets.
> +  */
> + int cman_wred_byte_mode_supported;
> +
>   /** Head drop algorithm support. When non-zero,
> this
>* parameter indicates that there is at least one leaf
>* node on this level that supports the head drop
> @@ -743,6 +777,12 @@ struct rte_tm_node_capabilities {
> 
>   /** Items valid only for leaf nodes. */
>   struct {
> + /** WRED packet mode support for current node. */
> + int cman_wred_packet_mode_supported;
> +
> + /** WRED byte mode support for current node. */
> + int cman_wred_byte_mode_supported;
> +
>   /** Head drop algorithm support for current node.
> */
>   int cman_head_drop_supported;
> 
> @@ -791,10 +831,10 @@ enum rte_tm_cman_mode {
>   */
>  struct rte_tm_red_params {
>   /** Minimum queue threshold */
> - uint16_t min_th;
> + uint32_t min_th;
> 
>   /** Maximum queue threshold */
> - uint16_t max_th;
> + uint32_t max_th;
> 
>   /** Inverse of packet marking probability maximum value (maxp),
> i.e.
>* maxp_inv = 1 / maxp
> @@ -815,10 +855,19 @@ struct rte_tm_red_params {
>   * WRED context is used to perform congestion management for a single
> leaf
> 

Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Thomas Monjalon
01/05/2018 15:33, Ferruh Yigit:
> Many sample applications fail because of
> dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()
> 
> The sample applications need to be fixed/updated before returning error
> on rte_eth_dev_configure()
> 
> This patch keeps the error log but removes returning error.
> 
> Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
> Cc: xuemi...@mellanox.com
> 
> Signed-off-by: Ferruh Yigit 

Applied, thanks

We'll decide later whether we need to return an error in 18.08 or not.




Re: [dpdk-dev] [PATCH] net/i40e: revert default PF PMD device name

2018-05-01 Thread Ferruh Yigit
On 4/30/2018 4:30 PM, Declan Doherty wrote:
> Changes introduced by e0cb96204b71 modified the default name generated
> for the i40e PF PMD, this patch reverts the default name to the
> original PCI BDBF.
> 
> Fixes: e0cb96204b71 ("net/i40e: add support for representor ports")
> Signed-off-by: Declan Doherty 

Reviewed-by: Ferruh Yigit 


Re: [dpdk-dev] [PATCH] net/i40e: revert default PF PMD device name

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 4:41 PM, Ferruh Yigit wrote:
> On 4/30/2018 4:30 PM, Declan Doherty wrote:
>> Changes introduced by e0cb96204b71 modified the default name generated
>> for the i40e PF PMD, this patch reverts the default name to the
>> original PCI BDBF.
>>
>> Fixes: e0cb96204b71 ("net/i40e: add support for representor ports")
>> Signed-off-by: Declan Doherty 
> 
> Reviewed-by: Ferruh Yigit 

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


Re: [dpdk-dev] [dpdk-web] [PATCH v2] update stable releases roadmap

2018-05-01 Thread Kevin Traynor
On 05/01/2018 03:16 PM, Aaron Conole wrote:
> Thomas Monjalon  writes:
> 
>> 25/04/2018 12:03, Luca Boccassi:
>>> On Wed, 2018-04-25 at 09:33 +0100, Ferruh Yigit wrote:
 On 4/20/2018 4:52 PM, Aaron Conole wrote:
> Kevin Traynor  writes:
>> On 04/18/2018 02:28 PM, Thomas Monjalon wrote:
>>> 18/04/2018 14:28, Ferruh Yigit:
 On 4/18/2018 10:14 AM, Thomas Monjalon wrote:
> 18/04/2018 11:05, Ferruh Yigit:
>> On 4/11/2018 12:28 AM, Thomas Monjalon wrote:
>>> -   Typically a new stable release version
>>> follows a mainline release
>>> -   by 1-2 weeks, depending on the test results.
>>> +   The first stable release (.1) of a branch
>>> should follow
>>> +   its mainline release (.0) by at least two
>>> months,
>>> +   after the first release candidate (-rc1) of
>>> the next branch.
>>
>> Hi Thomas,
>>
>> What this change suggest? To be able to backport patches
>> from rc1?
>
> Yes, it is the proposal we discussed earlier.
> We can wait one week after RC1 to get some validation
> confirmation.
> Do you agree?

 This has been discussed in tech-board, what I remember the
 decision was to wait
 the release to backport patches into stable tree.
>>
>> Any minutes? I couldn't find them
>>
>>> It was not so clear to me.
>>> I thought post-rc1 was acceptable. The idea is to speed-up
>>> stable releases
>>> pace, especially first release of a series.
>>>
>>>
>>
>> I think timing of stable releases and bugfix backports to the
>> stable
>> branch are two separate items.
>>
>> I do think that bugfix backports to stable should happen on a
>> regular
>> basis (e.g. every 2 weeks). Otherwise we are back to the
>> situation where
>> if there's a bugfix after a DPDK release, a user like (surprise,
>> surprise) OVS may not be able to use that DPDK version for ~3
>> months.
>>
>> Someone who wants to get the latest bugfixes can just take the
>> latest on
>> the stable branch and importantly, can have confidence that the
>> community has officially accepted those patches. If someone
>> requires
>> stable to be validated, then they have to wait until the release.
>
> +1 - this seems to make the most sense to me.  Keep the patches
> flowing,
> but don't label/tag it until validation.  That serves an additional
> function: developers know their CC's to stable are being processed.

 Are stable trees verified?
>>>
>>> Verification is one issue - so far, Intel and ATT have provided time
>>> and resources to do some regression tests, but only at release time
>>> (before tagging). And it has been a manual process.
>>> It would be great if more companies would step up to help - and even
>>> better if regressions could be automated (nightly job?).
>>>
>>> The other issue is deciding when a patch is "good to go" - until now,
>>> the criteria has been "when it's merged into master".
>>> So either that criteria needs to change, and another equally
>>> "authoritative" is decided on, or patches should get reviewed and
>>> merged in master more often and more quickly :-P
>>>
>>> We also have not been looking directly at the the various -next trees,
>>> as things are more "in-flux" there and could be reverted, or clash with
>>> changes from other trees - hence why we merge from master.
>>
>> Yes, backporting from master is definitely the right thing to do.
>> Backporting more regularly would be also an improvement.
>> There will be always the question of the bug-free ideal in stable
>> branches. I agree we need more help to validate the stable branches.
>> But realistically, it will never be perfect.
>>
>> So the questions are:
>>  - What we must wait before pushing a backport in the stable tree?
>>  - What we must wait before tagging a stable release?
>>
>> I think it is reasonnable to push backports one or two weeks after
>> it is in the master branch, assuming master is tested by the community.
>> If a corner case is found later, it will be fixed with another patch.
> 
> +1 - I agree here.  Folks who truly care about 'validated stable'
> (whatever definition that takes) will only use a labeled version anyway.
> 
> OTOH, developers who want to see that their patches are landing in
> stable (and more over, who want to ensure that their proposed backports
> are actually complete - which is more relevant w.r.t. hardware),
> shouldn't have to wait for the label.
> 
> Most other projects work this way, as well.  Keep pulling in the
> relevant patches from master to the stable branch(es).  Do the official
> label / release at a certain point in time relative to the main release
> (or as needed in the case of "oh no, a serious bug here").
> 

I agree and I think it's the best way. However,

Re: [dpdk-dev] [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 3:37 PM, Ferruh Yigit wrote:
> On 5/1/2018 3:16 PM, Bruce Richardson wrote:
>> On Tue, May 01, 2018 at 03:13:54PM +0100, Bruce Richardson wrote:
>>> The Tx function selection code in the driver only used the older txq
>>> flags values to check whether the scalar or vector functions should be
>>> used. This caused performance regressions with testpmd io-fwd as the
>>> scalar path rather than the vector one was being used in the default
>>> case. Fix this by changing the code to take account of new offloads and
>>> deleting the defines used for the old ones.
>>>
>>> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
>>>
>>> Signed-off-by: Bruce Richardson 
>>> ---
>> Apologies: forgot to add:
>>
>> v2: eliminate mask for offload flags, and use vector path only if 
>> offloads == 0
>>
> 
> Reviewed-by: Ferruh Yigit 

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


Re: [dpdk-dev] [PATCH] ethdev: fix applications failure on configure

2018-05-01 Thread Thomas Monjalon
01/05/2018 17:30, Thomas Monjalon:
> 01/05/2018 15:33, Ferruh Yigit:
> > Many sample applications fail because of
> > dev_info.flow_type_rss_offloads check in rte_eth_dev_configure()
> > 
> > The sample applications need to be fixed/updated before returning error
> > on rte_eth_dev_configure()
> > 
> > This patch keeps the error log but removes returning error.
> > 
> > Fixes: 8863a1fbfc66 ("ethdev: add supported hash function check")
> > Cc: xuemi...@mellanox.com
> > 
> > Signed-off-by: Ferruh Yigit 
> 
> Applied, thanks

I've also removed the error return for rte_eth_dev_rss_hash_update
which was introduced by the same above patch.

Signed-off-by: Thomas Monjalon 




Re: [dpdk-dev] [dpdk-web] [PATCH v2] update stable releases roadmap

2018-05-01 Thread Thomas Monjalon
01/05/2018 17:46, Kevin Traynor:
> On 05/01/2018 03:16 PM, Aaron Conole wrote:
> > Thomas Monjalon  writes:
> >> So the questions are:
> >>- What we must wait before pushing a backport in the stable tree?
> >>- What we must wait before tagging a stable release?
> >>
> >> I think it is reasonnable to push backports one or two weeks after
> >> it is in the master branch, assuming master is tested by the community.
> >> If a corner case is found later, it will be fixed with another patch.
> > 
> > +1 - I agree here.  Folks who truly care about 'validated stable'
> > (whatever definition that takes) will only use a labeled version anyway.
> > 
> > OTOH, developers who want to see that their patches are landing in
> > stable (and more over, who want to ensure that their proposed backports
> > are actually complete - which is more relevant w.r.t. hardware),
> > shouldn't have to wait for the label.
> > 
> > Most other projects work this way, as well.  Keep pulling in the
> > relevant patches from master to the stable branch(es).  Do the official
> > label / release at a certain point in time relative to the main release
> > (or as needed in the case of "oh no, a serious bug here").
> > 
> 
> I agree and I think it's the best way. However, it also requires
> semi-frequent pull request merging into the master branch for this to
> work. Otherwise there is still delay, just earlier in the process.
> 
> Not sure if there is a written/un-written workflow for when the next-*
> branches merge into master at the moment?

We try to have more pulls before RC1.
It is not formal yet.




Re: [dpdk-dev] [PATCH 1/2] net/dpaa: fix the RSS hash support

2018-05-01 Thread Ferruh Yigit
On 5/1/2018 11:44 AM, Hemant Agrawal wrote:
> Fixes: 4fa5e0bbc573 ("net/dpaa: support hashed RSS")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Hemant Agrawal 

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


[dpdk-dev] [PATCH 1/2] ethdev: move log macro to header

2018-05-01 Thread Ferruh Yigit
Signed-off-by: Ferruh Yigit 
---
 lib/librte_ethdev/rte_ethdev.c | 17 +++--
 lib/librte_ethdev/rte_ethdev.h |  5 +
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 5a67e6a7d..a1fbb081d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -41,10 +41,7 @@
 #include "rte_ethdev_driver.h"
 #include "ethdev_profile.h"
 
-static int ethdev_logtype;
-
-#define ethdev_log(level, fmt, ...) \
-   rte_log(RTE_LOG_ ## level, ethdev_logtype, fmt "\n", ## __VA_ARGS__)
+int ethdev_logtype;
 
 static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
 struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
@@ -282,12 +279,12 @@ rte_eth_dev_allocate(const char *name)
 
port_id = rte_eth_dev_find_free_port();
if (port_id == RTE_MAX_ETHPORTS) {
-   ethdev_log(ERR, "Reached maximum number of Ethernet ports");
+   RTE_ETHDEV_LOG(ERR, "Reached maximum number of Ethernet ports");
goto unlock;
}
 
if (rte_eth_dev_allocated(name) != NULL) {
-   ethdev_log(ERR,
+   RTE_ETHDEV_LOG(ERR,
"Ethernet Device with name %s already allocated!",
name);
goto unlock;
@@ -640,7 +637,7 @@ rte_eth_dev_attach(const char *devargs, uint16_t *port_id)
 
/* no point looking at the port count if no port exists */
if (!rte_eth_dev_count_total()) {
-   ethdev_log(ERR, "No port found for device (%s)", da.name);
+   RTE_ETHDEV_LOG(ERR, "No port found for device (%s)", da.name);
ret = -1;
goto err;
}
@@ -675,7 +672,7 @@ rte_eth_dev_detach(uint16_t port_id, char *name 
__rte_unused)
 
dev_flags = rte_eth_devices[port_id].data->dev_flags;
if (dev_flags & RTE_ETH_DEV_BONDED_SLAVE) {
-   ethdev_log(ERR,
+   RTE_ETHDEV_LOG(ERR,
"Port %" PRIu16 " is bonded, cannot detach", port_id);
return -ENOTSUP;
}
@@ -3202,7 +3199,7 @@ rte_eth_dev_callback_register(uint16_t port_id,
return -EINVAL;
 
if (!rte_eth_dev_is_valid_port(port_id) && port_id != RTE_ETH_ALL) {
-   ethdev_log(ERR, "Invalid port_id=%d", port_id);
+   RTE_ETHDEV_LOG(ERR, "Invalid port_id=%d", port_id);
return -EINVAL;
}
 
@@ -3265,7 +3262,7 @@ rte_eth_dev_callback_unregister(uint16_t port_id,
return -EINVAL;
 
if (!rte_eth_dev_is_valid_port(port_id) && port_id != RTE_ETH_ALL) {
-   ethdev_log(ERR, "Invalid port_id=%d", port_id);
+   RTE_ETHDEV_LOG(ERR, "Invalid port_id=%d", port_id);
return -EINVAL;
}
 
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 7ccf4bae6..f05095c85 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -159,6 +159,11 @@ extern "C" {
 #include "rte_eth_ctrl.h"
 #include "rte_dev_info.h"
 
+extern int ethdev_logtype;
+
+#define RTE_ETHDEV_LOG(level, fmt, ...) \
+   rte_log(RTE_LOG_ ## level, ethdev_logtype, fmt "\n", ## __VA_ARGS__)
+
 struct rte_mbuf;
 
 /**
-- 
2.14.3



[dpdk-dev] [PATCH 2/2] ethdev: convert static logtype usage to dynamic

2018-05-01 Thread Ferruh Yigit
Replace RTE_PMD_DEBUG_TRACE with RTE_ETHDEV_LOG.

RTE_PMD_DEBUG_TRACE is using hardcoded PMD logtype and ERR log level,
controlled by compile time flags.
RTE_ETHDEV_LOG is using dynamic ethdev_logtype.

Also a few minor cleanups, like
- use %u for unsigned values like port_id which is uint16_t
- use PRIx64 for owner_id
- Join some log lines
- Unify to not have a "." at the end of the log

Signed-off-by: Ferruh Yigit 
---
 lib/librte_ethdev/rte_ethdev.c | 242 -
 1 file changed, 119 insertions(+), 123 deletions(-)

diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index a1fbb081d..4cd907fcf 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -284,8 +284,7 @@ rte_eth_dev_allocate(const char *name)
}
 
if (rte_eth_dev_allocated(name) != NULL) {
-   RTE_ETHDEV_LOG(ERR,
-   "Ethernet Device with name %s already allocated!",
+   RTE_ETHDEV_LOG(ERR, "Ethernet Device with name %s already 
allocated!",
name);
goto unlock;
}
@@ -325,8 +324,7 @@ rte_eth_dev_attach_secondary(const char *name)
break;
}
if (i == RTE_MAX_ETHPORTS) {
-   RTE_PMD_DEBUG_TRACE(
-   "device %s is not driven by the primary process\n",
+   RTE_ETHDEV_LOG(ERR, "device %s is not driven by the primary 
process",
name);
} else {
eth_dev = eth_dev_get(i);
@@ -373,7 +371,7 @@ rte_eth_is_valid_owner_id(uint64_t owner_id)
 {
if (owner_id == RTE_ETH_DEV_NO_OWNER ||
rte_eth_dev_shared_data->next_owner_id <= owner_id) {
-   RTE_PMD_DEBUG_TRACE("Invalid owner_id=%016lX.\n", owner_id);
+   RTE_ETHDEV_LOG(ERR, "Invalid owner_id=%"PRIx64, owner_id);
return 0;
}
return 1;
@@ -422,21 +420,20 @@ _rte_eth_dev_owner_set(const uint16_t port_id, const 
uint64_t old_owner_id,
 
port_owner = &rte_eth_devices[port_id].data->owner;
if (port_owner->id != old_owner_id) {
-   RTE_PMD_DEBUG_TRACE("Cannot set owner to port %d already owned"
-   " by %s_%016lX.\n", port_id,
-   port_owner->name, port_owner->id);
+   RTE_ETHDEV_LOG(ERR, "Cannot set owner to port %u already owned 
by %s_%"PRIx64,
+   port_id, port_owner->name, port_owner->id);
return -EPERM;
}
 
sret = snprintf(port_owner->name, RTE_ETH_MAX_OWNER_NAME_LEN, "%s",
new_owner->name);
if (sret < 0 || sret >= RTE_ETH_MAX_OWNER_NAME_LEN)
-   RTE_PMD_DEBUG_TRACE("Port %d owner name was truncated.\n",
+   RTE_ETHDEV_LOG(ERR, "Port %u owner name was truncated",
port_id);
 
port_owner->id = new_owner->id;
 
-   RTE_PMD_DEBUG_TRACE("Port %d owner is %s_%016lX.\n", port_id,
+   RTE_ETHDEV_LOG(ERR, "Port %u owner is %s_%"PRIx64, port_id,
new_owner->name, new_owner->id);
 
return 0;
@@ -488,8 +485,8 @@ rte_eth_dev_owner_delete(const uint64_t owner_id)
RTE_ETH_FOREACH_DEV_OWNED_BY(port_id, owner_id)
memset(&rte_eth_devices[port_id].data->owner, 0,
   sizeof(struct rte_eth_dev_owner));
-   RTE_PMD_DEBUG_TRACE("All port owners owned by %016X identifier"
-   " have removed.\n", owner_id);
+   RTE_ETHDEV_LOG(ERR, "All port owners owned by %"PRIx64" 
identifier have removed",
+   owner_id);
}
 
rte_spinlock_unlock(&rte_eth_dev_shared_data->ownership_lock);
@@ -505,7 +502,7 @@ rte_eth_dev_owner_get(const uint16_t port_id, struct 
rte_eth_dev_owner *owner)
rte_spinlock_lock(&rte_eth_dev_shared_data->ownership_lock);
 
if (!rte_eth_dev_is_valid_port(port_id)) {
-   RTE_PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+   RTE_ETHDEV_LOG(ERR, "Invalid port_id=%u", port_id);
ret = -ENODEV;
} else {
rte_memcpy(owner, &rte_eth_devices[port_id].data->owner,
@@ -570,7 +567,7 @@ rte_eth_dev_get_name_by_port(uint16_t port_id, char *name)
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
 
if (name == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
+   RTE_ETHDEV_LOG(ERR, "Null pointer is specified");
return -EINVAL;
}
 
@@ -587,7 +584,7 @@ rte_eth_dev_get_port_by_name(const char *name, uint16_t 
*port_id)
uint32_t pid;
 
if (name == NULL) {
-   RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
+   RTE_ETHDEV_LOG(ERR, "Null pointer is specified");
return -

Re: [dpdk-dev] [PATCH] net/vmxnet3: convert to new rx offload api

2018-05-01 Thread Louis Luo
Hi Ferruh,

Thanks for your review! Initially I did use PRIx64 there, but checkpatch.sh 
always failed and complained about it for Camel case. So I just replaced it 
with %lx. I will change it back and resend the review.

Thanks,
Louis

On 5/1/18, 7:58 AM, "Ferruh Yigit"  wrote:

On 4/30/2018 11:20 PM, Louis Luo wrote:
> Ethdev RX offloads API has changed since: commit ce17eddefc20
> ("ethdev: introduce Rx queue offloads API")
> 
> This patch adopts the new RX Offload API in vmxnet3 driver.
>
> Signed-off-by: Louis Luo 

Hi Louis,

Overall patch looks good, only there is 32bits build error because of 
logging,
more details below.

Can you please send a new version of the patch, keeping Yong's ack.

<...>

> @@ -376,9 +393,25 @@ vmxnet3_dev_configure(struct rte_eth_dev *dev)
>   const struct rte_memzone *mz;
>   struct vmxnet3_hw *hw = dev->data->dev_private;
>   size_t size;
> + uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
> + uint64_t tx_offloads = dev->data->dev_conf.txmode.offloads;
>  
>   PMD_INIT_FUNC_TRACE();
>  
> + if ((rx_offloads & VMXNET3_RX_OFFLOAD_CAP) != rx_offloads) {
> + RTE_LOG(ERR, PMD, "Requested RX offloads 0x%lx"
> + " do not match supported 0x%lx\n",
> + rx_offloads, (uint64_t)VMXNET3_RX_OFFLOAD_CAP);

%lx usage causing build error with 32bit build [1], please prefer PRIx64.

[1]
 argument of type "uint64_t={__uint64_t={unsigned long long}}" is 
incompatible
with format "%lx", expecting argument of type "unsigned long"

<...>




Re: [dpdk-dev] [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev offloads

2018-05-01 Thread Ananyev, Konstantin


> -Original Message-
> From: Richardson, Bruce
> Sent: Tuesday, May 1, 2018 3:14 PM
> To: Xing, Beilei ; Zhang, Qi Z 
> Cc: dev@dpdk.org; Yigit, Ferruh ; Ananyev, Konstantin 
> ; Richardson,
> Bruce 
> Subject: [PATCH v2] net/i40e: fix Tx fn selection when using new ethdev 
> offloads
> 
> The Tx function selection code in the driver only used the older txq
> flags values to check whether the scalar or vector functions should be
> used. This caused performance regressions with testpmd io-fwd as the
> scalar path rather than the vector one was being used in the default
> case. Fix this by changing the code to take account of new offloads and
> deleting the defines used for the old ones.
> 
> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> 
> Signed-off-by: Bruce Richardson 
> ---
>  drivers/net/i40e/i40e_rxtx.c | 39 ++-
>  1 file changed, 18 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index ec1ce54ca..006f5b846 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -40,9 +40,6 @@
>  /* Base address of the HW descriptor ring should be 128B aligned. */
>  #define I40E_RING_BASE_ALIGN 128
> 
> -#define I40E_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> - ETH_TXQ_FLAGS_NOOFFLOADS)
> -
>  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
> 
>  #ifdef RTE_LIBRTE_IEEE1588
> @@ -2108,11 +2105,9 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev 
> *dev,
>dev->data->nb_tx_queues)) {
>   /**
>* If it is the first queue to setup,
> -  * set all flags to default and call
> +  * set all flags and call
>* i40e_set_tx_function.
>*/
> - ad->tx_simple_allowed = true;
> - ad->tx_vec_allowed = true;
>   i40e_set_tx_function_flag(dev, txq);
>   i40e_set_tx_function(dev);
>   return 0;
> @@ -2128,9 +2123,8 @@ i40e_dev_tx_queue_setup_runtime(struct rte_eth_dev *dev,
>   }
>   /* check simple tx conflict */
>   if (ad->tx_simple_allowed) {
> - if (((txq->txq_flags & I40E_SIMPLE_FLAGS) !=
> -  I40E_SIMPLE_FLAGS) ||
> - txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
> + if (txq->offloads != 0 ||
> + txq->tx_rs_thresh < RTE_PMD_I40E_TX_MAX_BURST) {
>   PMD_DRV_LOG(ERR, "No-simple tx is required.");
>   return -EINVAL;
>   }
> @@ -3080,18 +3074,21 @@ i40e_set_tx_function_flag(struct rte_eth_dev *dev, 
> struct i40e_tx_queue *txq)
>   I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> 
>   /* Use a simple Tx queue (no offloads, no multi segs) if possible */
> - if (((txq->txq_flags & I40E_SIMPLE_FLAGS) == I40E_SIMPLE_FLAGS)
> - && (txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST)) {
> - if (txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ) {
> - PMD_INIT_LOG(DEBUG, "Vector tx"
> -  " can be enabled on this txq.");
> -
> - } else {
> - ad->tx_vec_allowed = false;
> - }
> - } else {
> - ad->tx_simple_allowed = false;
> - }
> + ad->tx_simple_allowed = (txq->offloads == 0 &&
> + txq->tx_rs_thresh >= RTE_PMD_I40E_TX_MAX_BURST);

Actually after another thought - who setup txq->offloads?
I did a quick scan, through i40e code and seems no one does.
So now it seems not possible to enable TX offloads at all.
Konstantin

BTW, seems like rxq->offloads are not properly initialised too.

> + ad->tx_vec_allowed = (ad->tx_simple_allowed &&
> + txq->tx_rs_thresh <= RTE_I40E_TX_MAX_FREE_BUF_SZ);
> +
> + if (ad->tx_vec_allowed)
> + PMD_INIT_LOG(DEBUG, "Vector Tx can be enabled on Tx queue %u.",
> + txq->queue_id);
> + else if (ad->tx_simple_allowed)
> + PMD_INIT_LOG(DEBUG, "Simple Tx can be enabled on Tx queue %u.",
> + txq->queue_id);
> + else
> + PMD_INIT_LOG(DEBUG,
> + "Neither simple nor vector Tx enabled on Tx 
> queue %u\n",
> + txq->queue_id);
>  }
> 
>  void __attribute__((cold))
> --
> 2.14.3



[dpdk-dev] [PATCH] net/vmxnet3: convert to new rx offload api

2018-05-01 Thread Louis Luo
Ethdev RX offloads API has changed since: commit ce17eddefc20
("ethdev: introduce Rx queue offloads API")

This patch adopts the new RX Offload API in vmxnet3 driver.

Signed-off-by: Louis Luo 

Acked-by: Yong Wang 
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 61 ++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 4568521..424cc30 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -42,6 +42,23 @@
 
 #defineVMXNET3_TX_MAX_SEG  UINT8_MAX
 
+#define VMXNET3_TX_OFFLOAD_CAP \
+   (DEV_TX_OFFLOAD_VLAN_INSERT |   \
+DEV_TX_OFFLOAD_IPV4_CKSUM |\
+DEV_TX_OFFLOAD_TCP_CKSUM | \
+DEV_TX_OFFLOAD_UDP_CKSUM | \
+DEV_TX_OFFLOAD_TCP_TSO |   \
+DEV_TX_OFFLOAD_MULTI_SEGS)
+
+#define VMXNET3_RX_OFFLOAD_CAP \
+   (DEV_RX_OFFLOAD_VLAN_STRIP |\
+DEV_RX_OFFLOAD_SCATTER |   \
+DEV_RX_OFFLOAD_IPV4_CKSUM |\
+DEV_RX_OFFLOAD_UDP_CKSUM | \
+DEV_RX_OFFLOAD_TCP_CKSUM | \
+DEV_RX_OFFLOAD_TCP_LRO |   \
+DEV_RX_OFFLOAD_JUMBO_FRAME)
+
 static int eth_vmxnet3_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_vmxnet3_dev_uninit(struct rte_eth_dev *eth_dev);
 static int vmxnet3_dev_configure(struct rte_eth_dev *dev);
@@ -376,9 +393,25 @@ vmxnet3_dev_configure(struct rte_eth_dev *dev)
const struct rte_memzone *mz;
struct vmxnet3_hw *hw = dev->data->dev_private;
size_t size;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
+   uint64_t tx_offloads = dev->data->dev_conf.txmode.offloads;
 
PMD_INIT_FUNC_TRACE();
 
+   if ((rx_offloads & VMXNET3_RX_OFFLOAD_CAP) != rx_offloads) {
+   RTE_LOG(ERR, PMD, "Requested RX offloads 0x%" PRIx64
+   " do not match supported 0x%" PRIx64,
+   rx_offloads, (uint64_t)VMXNET3_RX_OFFLOAD_CAP);
+   return -ENOTSUP;
+   }
+
+   if ((tx_offloads & VMXNET3_TX_OFFLOAD_CAP) != tx_offloads) {
+   RTE_LOG(ERR, PMD, "Requested TX offloads 0x%" PRIx64
+   " do not match supported 0x%" PRIx64,
+   tx_offloads, (uint64_t)VMXNET3_TX_OFFLOAD_CAP);
+   return -ENOTSUP;
+   }
+
if (dev->data->nb_tx_queues > VMXNET3_MAX_TX_QUEUES ||
dev->data->nb_rx_queues > VMXNET3_MAX_RX_QUEUES) {
PMD_INIT_LOG(ERR, "ERROR: Number of queues not supported");
@@ -567,6 +600,7 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
uint32_t mtu = dev->data->mtu;
Vmxnet3_DriverShared *shared = hw->shared;
Vmxnet3_DSDevRead *devRead = &shared->devRead;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
uint32_t i;
int ret;
 
@@ -644,10 +678,10 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
devRead->rxFilterConf.rxMode = 0;
 
/* Setting up feature flags */
-   if (dev->data->dev_conf.rxmode.hw_ip_checksum)
+   if (rx_offloads & DEV_RX_OFFLOAD_CHECKSUM)
devRead->misc.uptFeatures |= VMXNET3_F_RXCSUM;
 
-   if (dev->data->dev_conf.rxmode.enable_lro) {
+   if (rx_offloads & DEV_RX_OFFLOAD_TCP_LRO) {
devRead->misc.uptFeatures |= VMXNET3_F_LRO;
devRead->misc.maxNumRxSG = 0;
}
@@ -1050,17 +1084,10 @@ vmxnet3_dev_info_get(struct rte_eth_dev *dev 
__rte_unused,
.nb_mtu_seg_max = VMXNET3_MAX_TXD_PER_PKT,
};
 
-   dev_info->rx_offload_capa =
-   DEV_RX_OFFLOAD_VLAN_STRIP |
-   DEV_RX_OFFLOAD_UDP_CKSUM |
-   DEV_RX_OFFLOAD_TCP_CKSUM |
-   DEV_RX_OFFLOAD_TCP_LRO;
-
-   dev_info->tx_offload_capa =
-   DEV_TX_OFFLOAD_VLAN_INSERT |
-   DEV_TX_OFFLOAD_TCP_CKSUM |
-   DEV_TX_OFFLOAD_UDP_CKSUM |
-   DEV_TX_OFFLOAD_TCP_TSO;
+   dev_info->rx_offload_capa = VMXNET3_RX_OFFLOAD_CAP;
+   dev_info->rx_queue_offload_capa = 0;
+   dev_info->tx_offload_capa = VMXNET3_TX_OFFLOAD_CAP;
+   dev_info->tx_queue_offload_capa = 0;
 }
 
 static const uint32_t *
@@ -1154,8 +1181,9 @@ vmxnet3_dev_promiscuous_disable(struct rte_eth_dev *dev)
 {
struct vmxnet3_hw *hw = dev->data->dev_private;
uint32_t *vf_table = hw->shared->devRead.rxFilterConf.vfTable;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
 
-   if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+   if (rx_offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
memcpy(vf_table, hw->shadow_vfta, VMXNET3_VFT_TABLE_SIZE);
else
memset(vf_table, 0xff, VMXNET3_VFT_TABLE_SIZE);
@@ -1217,9 +1245,10 @@ vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, 
int mask)
struct vmxnet3_hw *hw = dev->data->dev_privat

Re: [dpdk-dev] [PATCH 1/2] ethdev: move log macro to header

2018-05-01 Thread Thomas Monjalon
01/05/2018 19:28, Ferruh Yigit:
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> -static int ethdev_logtype;
> -
> -#define ethdev_log(level, fmt, ...) \
> - rte_log(RTE_LOG_ ## level, ethdev_logtype, fmt "\n", ## __VA_ARGS__)
> +int ethdev_logtype;
>  
[...]
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> +extern int ethdev_logtype;
> +
> +#define RTE_ETHDEV_LOG(level, fmt, ...) \
> + rte_log(RTE_LOG_ ## level, ethdev_logtype, fmt "\n", ## __VA_ARGS__)

Why moving this macro in the header file? For using it in inline functions?
Probably worth an explanation in the commit message.




Re: [dpdk-dev] [PATCH] net/vmxnet3: convert to new rx offload api

2018-05-01 Thread Thomas Monjalon
01/05/2018 20:10, Louis Luo:
> Ethdev RX offloads API has changed since: commit ce17eddefc20
> ("ethdev: introduce Rx queue offloads API")
> 
> This patch adopts the new RX Offload API in vmxnet3 driver.
> 
> Signed-off-by: Louis Luo 
> 
> Acked-by: Yong Wang 

It looks to be a v2.
Please use -v2 and --in-reply-to as explained in http://dpdk.org/dev#send





[dpdk-dev] [PATCH] eal: fix typo in doc of pointer offset macro

2018-05-01 Thread Thomas Monjalon
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/common/include/rte_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/rte_common.h 
b/lib/librte_eal/common/include/rte_common.h
index 69e5ed1e3..ca4d0eaa6 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -124,7 +124,7 @@ static void __attribute__((constructor(RTE_PRIO(prio)), 
used)) func(void)
 /*** Macros for pointer arithmetic /
 
 /**
- * add a byte-value offset from a pointer
+ * add a byte-value offset to a pointer
  */
 #define RTE_PTR_ADD(ptr, x) ((void*)((uintptr_t)(ptr) + (x)))
 
-- 
2.16.2



[dpdk-dev] [PATCH] mem: fix typo in local function name

2018-05-01 Thread Thomas Monjalon
Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime")

Signed-off-by: Thomas Monjalon 
---
 lib/librte_eal/linuxapp/eal/eal_memalloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c 
b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index 360d8f73c..ace2bcf3e 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
@@ -143,7 +143,7 @@ prepare_numa(int *oldpolicy, struct bitmask *oldmask, int 
socket_id)
 }
 
 static void
-resotre_numa(int *oldpolicy, struct bitmask *oldmask)
+restore_numa(int *oldpolicy, struct bitmask *oldmask)
 {
RTE_LOG(DEBUG, EAL,
"Restoring previous memory policy: %d\n", *oldpolicy);
@@ -889,7 +889,7 @@ eal_memalloc_alloc_seg_bulk(struct rte_memseg **ms, int 
n_segs, size_t page_sz,
 
 #ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
if (have_numa)
-   resotre_numa(&oldpolicy, oldmask);
+   restore_numa(&oldpolicy, oldmask);
 #endif
return ret;
 }
-- 
2.16.2



[dpdk-dev] [PATCH] use SPDX license tag in Mellanox copyrighted files

2018-05-01 Thread Thomas Monjalon
Some files were left with full license and wrong copyright format.
They are switched to this format:
SPDX-License-Identifier: BSD-3-Clause
Copyright 2017 Mellanox Technologies, Ltd

Fixes: 5feecc57d90b ("align SPDX Mellanox copyrights")

Signed-off-by: Thomas Monjalon 
---
 devtools/check-dup-includes.sh  | 23 ++--
 doc/guides/howto/rte_flow.rst   | 32 ++--
 doc/guides/prog_guide/rte_flow.rst  | 30 ++
 doc/guides/sample_app_ug/flow_filtering.rst | 32 ++--
 drivers/net/failsafe/Makefile   | 33 +++--
 examples/flow_filtering/Makefile| 33 ++---
 examples/flow_filtering/flow_blocks.c   | 32 ++--
 examples/flow_filtering/main.c  | 32 ++--
 8 files changed, 17 insertions(+), 230 deletions(-)

diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
index 10365e4a1..e4c2748c6 100755
--- a/devtools/check-dup-includes.sh
+++ b/devtools/check-dup-includes.sh
@@ -1,25 +1,6 @@
 #! /bin/sh -e
-
-# Copyright 2017 Mellanox Technologies, Ltd. All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-#   * Redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer.
-#   * Redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in
-# the documentation and/or other materials provided with the
-# distribution.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
-# IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
-# CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
-# TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
-# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE  SOFTWARE.
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright 2017 Mellanox Technologies, Ltd
 
 # Check C files in git repository for duplicated includes.
 # Usage: devtools/check-dup-includes.sh [directory]
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 4a27c995d..4cc8edc10 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -1,33 +1,5 @@
-..  BSD LICENSE
-Copyright(c) 2017 Mellanox Corporation. All rights reserved.
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-* Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in
-the documentation and/or other materials provided with the
-distribution.
-* Neither the name of Mellanox Corporation nor the names of its
-contributors may be used to endorse or promote products derived
-from this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright 2017 Mellanox Technologies, Ltd
 
 Generic flow API - examples
 ===
diff --git a/doc/guides/prog_guide/rte_flow.rst 
b/doc/guides/prog_guide/rte_flow.rst
index 7af132ebf..b305a72a5 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1,32 +1,6 @@
-..  BSD LICENSE
+..  SPDX-License-Identifier: BSD-3-Clause
 Copyright 2016 6WIND S.A.
-Copyright 2016 Mellanox.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-* Redistributions of so

[dpdk-dev] ethdev flags and capabilities

2018-05-01 Thread Thomas Monjalon
Since DPDK 18.05-rc1, we have 2 new fields in rte_eth_dev_info:
const uint32_t *dev_flags;
uint64_t dev_capa;

The field dev_flags (http://dpdk.org/commit/736b30ebf2)
is a pointer to rte_eth_dev_data.dev_flags for these bits:
RTE_ETH_DEV_INTR_LSC
RTE_ETH_DEV_BONDED_SLAVE
RTE_ETH_DEV_INTR_RMV
RTE_ETH_DEV_REPRESENTOR

The field dev_capa (http://dpdk.org/commit/cac923cfea)
is an integer for these bits:
RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP
RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP

How can we merge them?
Should we move the capabilities in rte_eth_dev_data.dev_flags?
Or do we want to keep the capabilities in rte_eth_dev_info?
Is it OK to use pointers in rte_eth_dev_info or should we make a copy
of rte_eth_dev_data fields?

We need to take a decision before RC3. Thanks




[dpdk-dev] [PATCH] net/vmxnet3: convert to new rx offload api

2018-05-01 Thread Louis Luo
Ethdev RX offloads API has changed since: commit ce17eddefc20
("ethdev: introduce Rx queue offloads API")

This patch adopts the new RX Offload API in vmxnet3 driver.

Signed-off-by: Louis Luo 

Acked-by: Yong Wang 
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 61 ++--
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 4568521..424cc30 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -42,6 +42,23 @@
 
 #defineVMXNET3_TX_MAX_SEG  UINT8_MAX
 
+#define VMXNET3_TX_OFFLOAD_CAP \
+   (DEV_TX_OFFLOAD_VLAN_INSERT |   \
+DEV_TX_OFFLOAD_IPV4_CKSUM |\
+DEV_TX_OFFLOAD_TCP_CKSUM | \
+DEV_TX_OFFLOAD_UDP_CKSUM | \
+DEV_TX_OFFLOAD_TCP_TSO |   \
+DEV_TX_OFFLOAD_MULTI_SEGS)
+
+#define VMXNET3_RX_OFFLOAD_CAP \
+   (DEV_RX_OFFLOAD_VLAN_STRIP |\
+DEV_RX_OFFLOAD_SCATTER |   \
+DEV_RX_OFFLOAD_IPV4_CKSUM |\
+DEV_RX_OFFLOAD_UDP_CKSUM | \
+DEV_RX_OFFLOAD_TCP_CKSUM | \
+DEV_RX_OFFLOAD_TCP_LRO |   \
+DEV_RX_OFFLOAD_JUMBO_FRAME)
+
 static int eth_vmxnet3_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_vmxnet3_dev_uninit(struct rte_eth_dev *eth_dev);
 static int vmxnet3_dev_configure(struct rte_eth_dev *dev);
@@ -376,9 +393,25 @@ vmxnet3_dev_configure(struct rte_eth_dev *dev)
const struct rte_memzone *mz;
struct vmxnet3_hw *hw = dev->data->dev_private;
size_t size;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
+   uint64_t tx_offloads = dev->data->dev_conf.txmode.offloads;
 
PMD_INIT_FUNC_TRACE();
 
+   if ((rx_offloads & VMXNET3_RX_OFFLOAD_CAP) != rx_offloads) {
+   RTE_LOG(ERR, PMD, "Requested RX offloads 0x%" PRIx64
+   " do not match supported 0x%" PRIx64,
+   rx_offloads, (uint64_t)VMXNET3_RX_OFFLOAD_CAP);
+   return -ENOTSUP;
+   }
+
+   if ((tx_offloads & VMXNET3_TX_OFFLOAD_CAP) != tx_offloads) {
+   RTE_LOG(ERR, PMD, "Requested TX offloads 0x%" PRIx64
+   " do not match supported 0x%" PRIx64,
+   tx_offloads, (uint64_t)VMXNET3_TX_OFFLOAD_CAP);
+   return -ENOTSUP;
+   }
+
if (dev->data->nb_tx_queues > VMXNET3_MAX_TX_QUEUES ||
dev->data->nb_rx_queues > VMXNET3_MAX_RX_QUEUES) {
PMD_INIT_LOG(ERR, "ERROR: Number of queues not supported");
@@ -567,6 +600,7 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
uint32_t mtu = dev->data->mtu;
Vmxnet3_DriverShared *shared = hw->shared;
Vmxnet3_DSDevRead *devRead = &shared->devRead;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
uint32_t i;
int ret;
 
@@ -644,10 +678,10 @@ vmxnet3_setup_driver_shared(struct rte_eth_dev *dev)
devRead->rxFilterConf.rxMode = 0;
 
/* Setting up feature flags */
-   if (dev->data->dev_conf.rxmode.hw_ip_checksum)
+   if (rx_offloads & DEV_RX_OFFLOAD_CHECKSUM)
devRead->misc.uptFeatures |= VMXNET3_F_RXCSUM;
 
-   if (dev->data->dev_conf.rxmode.enable_lro) {
+   if (rx_offloads & DEV_RX_OFFLOAD_TCP_LRO) {
devRead->misc.uptFeatures |= VMXNET3_F_LRO;
devRead->misc.maxNumRxSG = 0;
}
@@ -1050,17 +1084,10 @@ vmxnet3_dev_info_get(struct rte_eth_dev *dev 
__rte_unused,
.nb_mtu_seg_max = VMXNET3_MAX_TXD_PER_PKT,
};
 
-   dev_info->rx_offload_capa =
-   DEV_RX_OFFLOAD_VLAN_STRIP |
-   DEV_RX_OFFLOAD_UDP_CKSUM |
-   DEV_RX_OFFLOAD_TCP_CKSUM |
-   DEV_RX_OFFLOAD_TCP_LRO;
-
-   dev_info->tx_offload_capa =
-   DEV_TX_OFFLOAD_VLAN_INSERT |
-   DEV_TX_OFFLOAD_TCP_CKSUM |
-   DEV_TX_OFFLOAD_UDP_CKSUM |
-   DEV_TX_OFFLOAD_TCP_TSO;
+   dev_info->rx_offload_capa = VMXNET3_RX_OFFLOAD_CAP;
+   dev_info->rx_queue_offload_capa = 0;
+   dev_info->tx_offload_capa = VMXNET3_TX_OFFLOAD_CAP;
+   dev_info->tx_queue_offload_capa = 0;
 }
 
 static const uint32_t *
@@ -1154,8 +1181,9 @@ vmxnet3_dev_promiscuous_disable(struct rte_eth_dev *dev)
 {
struct vmxnet3_hw *hw = dev->data->dev_private;
uint32_t *vf_table = hw->shared->devRead.rxFilterConf.vfTable;
+   uint64_t rx_offloads = dev->data->dev_conf.rxmode.offloads;
 
-   if (dev->data->dev_conf.rxmode.hw_vlan_filter)
+   if (rx_offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
memcpy(vf_table, hw->shadow_vfta, VMXNET3_VFT_TABLE_SIZE);
else
memset(vf_table, 0xff, VMXNET3_VFT_TABLE_SIZE);
@@ -1217,9 +1245,10 @@ vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, 
int mask)
struct vmxnet3_hw *hw = dev->data->dev_privat

Re: [dpdk-dev] [PATCH 1/1] net/ixgbe: Add API to update SBP bit

2018-05-01 Thread Shweta Choudaha
Hi Helin, Qi, Wenzhuo,

   Any update for this patch.
Anything else needed or can this be merged ?

Thanks,
Shweta

On Thu, Apr 26, 2018 at 11:56 AM, Ferruh Yigit 
wrote:

> On 4/26/2018 11:20 AM, Shweta Choudaha wrote:
> > Hi Ferruh/ Helin,
> >
> >   Anything else needed for this patch
> >
> > http://dpdk.org/dev/patchwork/patch/37802/
> > Or can this be now acked  - Have addressed all comments so far.
>
> Hi Helin, Qi, Wenzhuo,
>
> Any more comment on patch?
> Please let me know if you prefer me getting this directly to next-net?
>
> >
> > Thanks,
> > Shweta
> >
> > On Tue, Apr 10, 2018 at 4:58 PM, Shweta Choudaha <
> shweta.choud...@gmail.com
> > > wrote:
> >
> > Thanks for the review.
> > I have sent an updated patch and will send patch to remove
> experimental from
> > API for next release
> >
> > Thanks,
> > Shweta
> >
> > On Wed, Apr 4, 2018 at 11:40 AM, Bruce Richardson
> > mailto:bruce.richard...@intel.com>>
> wrote:
> >
> > On Wed, Apr 04, 2018 at 11:14:35AM +0100, Ferruh Yigit wrote:
> > > On 4/4/2018 3:25 AM, Lu, Wenzhuo wrote:
> > > > Hi Shweta,
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: dev [mailto:dev-boun...@dpdk.org
> > ] On Behalf Of Shweta Choudaha
> > > >> Sent: Friday, February 23, 2018 7:59 PM
> > > >> To: dev@dpdk.org 
> > > >> Cc: shweta.choud...@att.com  >
> > > >> Subject: [dpdk-dev] [PATCH 1/1] net/ixgbe: Add API to
> update SBP bit
> > > >>
> > > >> From: Shweta Choudaha  > >
> > > >>
> > > >> Add ixgbe API to enable SBP bit in FCTRL register to allow
> > receiving packets
> > > >> that may otherwise be considered length errors by ixgbe and
> dropped
> > > >>
> > > >> Signed-off-by: Shweta Choudaha  > >
> > > >> Reviewed-by: Chas Williams  ch...@att.com>>
> > > >> Reviewed-by: Luca Boccassi  bl...@debian.org>>
> > > >> ---
> > > >
> > > >
> > > >> --- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> > > >> +++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> > > >> @@ -52,3 +52,9 @@ DPDK_17.08 {
> > > >>rte_pmd_ixgbe_bypass_wd_timeout_show;
> > > >>rte_pmd_ixgbe_bypass_wd_timeout_store;
> > > >>  } DPDK_17.05;
> > > >> +
> > > >> +EXPERIMENTAL {
> > > >> +  global:
> > > >> +
> > > >> +  rte_pmd_ixgbe_upd_fctrl_sbp;
> > > >> +} DPDK_17.08;
> > > > The patch is fine except we should use 18.05 here.
> > >
> > > We have a rule to have an API as experimental for one release.
> > >
> > > Not sure about this rule covering the PMD specific APIs but by
> default
> > it is, we
> > > can discuss to have an exception for PMD APIs or not.
> > >
> > > After one release developer should send patch to remove
> experimental
> > from API
> > >
> > +1 for following the process.
> > I don't see why pmd-specific APIs should be a general exception.
> Any
> > exceptions should be on an individual case-by-case basis IMHO
> >
> >
> >
>
>


[dpdk-dev] [PATCH] net/bnxt: remove unused txq flags

2018-05-01 Thread Ajit Khaparde
We are still using the txq_flags which is no longer needed with the
new offload API. Cleaning it up.

Signed-off-by: Ajit Khaparde 
---
 drivers/net/bnxt/bnxt_ethdev.c | 1 -
 drivers/net/bnxt/bnxt_txq.h| 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index dc445f9a5..2fbb48b4b 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -1536,7 +1536,6 @@ bnxt_txq_info_get_op(struct rte_eth_dev *dev, uint16_t 
queue_id,
 
qinfo->conf.tx_free_thresh = txq->tx_free_thresh;
qinfo->conf.tx_rs_thresh = 0;
-   qinfo->conf.txq_flags = txq->txq_flags;
qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
 }
 
diff --git a/drivers/net/bnxt/bnxt_txq.h b/drivers/net/bnxt/bnxt_txq.h
index 8df87148f..720ca90cf 100644
--- a/drivers/net/bnxt/bnxt_txq.h
+++ b/drivers/net/bnxt/bnxt_txq.h
@@ -22,7 +22,6 @@ struct bnxt_tx_queue {
uint8_t pthresh; /* Prefetch threshold register */
uint8_t hthresh; /* Host threshold register */
uint8_t wthresh; /* Write-back threshold reg */
-   uint32_ttxq_flags; /* Holds flags for this TXq */
uint32_tctx_curr; /* Hardware context states */
uint8_t tx_deferred_start; /* not in global dev start */
 
-- 
2.15.1 (Apple Git-101)



Re: [dpdk-dev] [PATCH 2/2] net/mlx5: fix probe return value polarity

2018-05-01 Thread Yongseok Koh

> On May 1, 2018, at 4:18 AM, Shahaf Shuler  wrote:
> 
> mlx5 prefixed function returns a negative errno value.
> the error handler on mlx5_pci_probe is doing the same.
> 
> Fixes: a6d83b6a9209 ("net/mlx5: standardize on negative errno values")
> Cc: nelio.laranje...@6wind.com
> 
> Signed-off-by: Shahaf Shuler 
> ---
> drivers/net/mlx5/mlx5.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 46cb370a29..ab860b5985 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -804,12 +804,16 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   goto error;

Shouldn't you do the same for mlx5_uar_init_secondary()?
Looks like a few more. E.g. mlx5_args(), mlx5_get_mtu() and 
mlx5_uar_init_primary().
What about ibv_query_port() and mlx5_flow_create_drop_queue()? 

Thanks

>   /* Receive command fd from primary process */
>   err = mlx5_socket_connect(eth_dev);
> - if (err < 0)
> + if (err < 0) {
> + err = -err;

Instead of changing sign, how about 'err = rte_errno;' ?
However, err looks redundant to me because mlx5_* funcs set rte_errno.
Here, err is used to set rte_errno at the end.

Thanks,
Yongseok

>   goto error;
> + }
>   /* Remap UAR for Tx queues. */
>   err = mlx5_tx_uar_remap(eth_dev, err);
> - if (err)
> + if (err) {
> + err = -err;
>   goto error;
> + }
>   /*
>* Ethdev pointer is still required as input since
>* the primary device is not accessible from the
> -- 
> 2.12.0
> 



[dpdk-dev] [PATCH 1/2] net/i40e: fix queue offload initialize

2018-05-01 Thread Qi Zhang
Add missing queue offload initialization.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
Fixes: c3ac7c5b0b8a ("net/i40e: convert to new Rx offloads API")

Signed-off-by: Qi Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 1 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 1 +
 drivers/net/i40e/i40e_rxtx.c   | 2 ++
 drivers/net/i40e/i40e_vf_representor.c | 1 +
 4 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 284e9cb64..a001d5b99 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3345,6 +3345,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 48e7ac21e..de5f460e9 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2238,6 +2238,7 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 006f5b846..755109ee5 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1857,6 +1857,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->drop_en = rx_conf->rx_drop_en;
rxq->vsi = vsi;
rxq->rx_deferred_start = rx_conf->rx_deferred_start;
+   rxq->offloads = rx_conf->offloads;
 
/* Allocate the maximun number of RX ring hardware descriptor. */
len = I40E_MAX_RING_DESC;
@@ -2297,6 +2298,7 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->reg_idx = reg_idx;
txq->port_id = dev->data->port_id;
txq->txq_flags = tx_conf->txq_flags;
+   txq->offloads = tx_conf->offloads;
txq->vsi = vsi;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
 
diff --git a/drivers/net/i40e/i40e_vf_representor.c 
b/drivers/net/i40e/i40e_vf_representor.c
index a8aa0115d..7b67e23ae 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -81,6 +81,7 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev *ethdev,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
-- 
2.13.6



[dpdk-dev] [PATCH 2/2] net/i40e: remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
Since we move to new offload APIs, txq_flags is no long needed.
This patch remove the dependence on that.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
Fixes: c3ac7c5b0b8a ("net/i40e: convert to new Rx offloads API")

Signed-off-by: Qi Zhang 
---
 drivers/net/i40e/i40e_ethdev.c | 2 --
 drivers/net/i40e/i40e_ethdev_vf.c  | 2 --
 drivers/net/i40e/i40e_rxtx.c   | 4 +---
 drivers/net/i40e/i40e_rxtx.h   | 1 -
 drivers/net/i40e/i40e_vf_representor.c | 2 --
 5 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index a001d5b99..92ee6c5ae 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3343,8 +3343,6 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index de5f460e9..b9dea2e5b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2236,8 +2236,6 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 755109ee5..62985c3a9 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1237,7 +1237,7 @@ i40e_tx_free_bufs(struct i40e_tx_queue *txq)
for (i = 0; i < txq->tx_rs_thresh; i++)
rte_prefetch0((txep + i)->mbuf);
 
-   if (txq->txq_flags & (uint32_t)ETH_TXQ_FLAGS_NOREFCOUNT) {
+   if (txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE) {
for (i = 0; i < txq->tx_rs_thresh; ++i, ++txep) {
rte_mempool_put(txep->mbuf->pool, txep->mbuf);
txep->mbuf = NULL;
@@ -2297,7 +2297,6 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->queue_id = queue_idx;
txq->reg_idx = reg_idx;
txq->port_id = dev->data->port_id;
-   txq->txq_flags = tx_conf->txq_flags;
txq->offloads = tx_conf->offloads;
txq->vsi = vsi;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
@@ -2951,7 +2950,6 @@ i40e_txq_info_get(struct rte_eth_dev *dev, uint16_t 
queue_id,
 
qinfo->conf.tx_free_thresh = txq->tx_free_thresh;
qinfo->conf.tx_rs_thresh = txq->tx_rs_thresh;
-   qinfo->conf.txq_flags = txq->txq_flags;
qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
 }
 
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 10feec4a2..ea73a8a1b 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -142,7 +142,6 @@ struct i40e_tx_queue {
uint16_t port_id; /**< Device port identifier. */
uint16_t queue_id; /**< TX queue index. */
uint16_t reg_idx;
-   uint32_t txq_flags;
struct i40e_vsi *vsi; /**< the VSI this queue belongs to */
uint16_t tx_next_dd;
uint16_t tx_next_rs;
diff --git a/drivers/net/i40e/i40e_vf_representor.c 
b/drivers/net/i40e/i40e_vf_representor.c
index 7b67e23ae..068404f75 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -79,8 +79,6 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev *ethdev,
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
-- 
2.13.6



Re: [dpdk-dev] [PATCH 2/2] net/i40e: remove dependence on Tx queue flags

2018-05-01 Thread Zhang, Qi Z
Hi Ferruh:

> -Original Message-
> From: Zhang, Qi Z
> Sent: Wednesday, May 2, 2018 10:44 AM
> To: Yigit, Ferruh ; Ananyev, Konstantin
> 
> Cc: dev@dpdk.org; Xing, Beilei ; Zhang, Qi Z
> 
> Subject: [PATCH 2/2] net/i40e: remove dependence on Tx queue flags
> 
> Since we move to new offload APIs, txq_flags is no long needed.
> This patch remove the dependence on that.
> 
> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> Fixes: c3ac7c5b0b8a ("net/i40e: convert to new Rx offloads API")

The above fix line or RX should be removed, if no other issue for the patch, 
Would you capture this when apply?

Thanks
Qi

> 
> Signed-off-by: Qi Zhang 
> ---
>  drivers/net/i40e/i40e_ethdev.c | 2 --
>  drivers/net/i40e/i40e_ethdev_vf.c  | 2 --
>  drivers/net/i40e/i40e_rxtx.c   | 4 +---
>  drivers/net/i40e/i40e_rxtx.h   | 1 -
>  drivers/net/i40e/i40e_vf_representor.c | 2 --
>  5 files changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index a001d5b99..92ee6c5ae 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -3343,8 +3343,6 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
>   },
>   .tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
>   .tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
> - .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> - ETH_TXQ_FLAGS_NOOFFLOADS,
>   .offloads = 0,
>   };
> 
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index de5f460e9..b9dea2e5b 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -2236,8 +2236,6 @@ i40evf_dev_info_get(struct rte_eth_dev *dev,
> struct rte_eth_dev_info *dev_info)
>   },
>   .tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
>   .tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
> - .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> - ETH_TXQ_FLAGS_NOOFFLOADS,
>   .offloads = 0,
>   };
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c index
> 755109ee5..62985c3a9 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -1237,7 +1237,7 @@ i40e_tx_free_bufs(struct i40e_tx_queue *txq)
>   for (i = 0; i < txq->tx_rs_thresh; i++)
>   rte_prefetch0((txep + i)->mbuf);
> 
> - if (txq->txq_flags & (uint32_t)ETH_TXQ_FLAGS_NOREFCOUNT) {
> + if (txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE) {
>   for (i = 0; i < txq->tx_rs_thresh; ++i, ++txep) {
>   rte_mempool_put(txep->mbuf->pool, txep->mbuf);
>   txep->mbuf = NULL;
> @@ -2297,7 +2297,6 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev
> *dev,
>   txq->queue_id = queue_idx;
>   txq->reg_idx = reg_idx;
>   txq->port_id = dev->data->port_id;
> - txq->txq_flags = tx_conf->txq_flags;
>   txq->offloads = tx_conf->offloads;
>   txq->vsi = vsi;
>   txq->tx_deferred_start = tx_conf->tx_deferred_start; @@ -2951,7
> +2950,6 @@ i40e_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
> 
>   qinfo->conf.tx_free_thresh = txq->tx_free_thresh;
>   qinfo->conf.tx_rs_thresh = txq->tx_rs_thresh;
> - qinfo->conf.txq_flags = txq->txq_flags;
>   qinfo->conf.tx_deferred_start = txq->tx_deferred_start;  }
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h index
> 10feec4a2..ea73a8a1b 100644
> --- a/drivers/net/i40e/i40e_rxtx.h
> +++ b/drivers/net/i40e/i40e_rxtx.h
> @@ -142,7 +142,6 @@ struct i40e_tx_queue {
>   uint16_t port_id; /**< Device port identifier. */
>   uint16_t queue_id; /**< TX queue index. */
>   uint16_t reg_idx;
> - uint32_t txq_flags;
>   struct i40e_vsi *vsi; /**< the VSI this queue belongs to */
>   uint16_t tx_next_dd;
>   uint16_t tx_next_rs;
> diff --git a/drivers/net/i40e/i40e_vf_representor.c
> b/drivers/net/i40e/i40e_vf_representor.c
> index 7b67e23ae..068404f75 100644
> --- a/drivers/net/i40e/i40e_vf_representor.c
> +++ b/drivers/net/i40e/i40e_vf_representor.c
> @@ -79,8 +79,6 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev
> *ethdev,
>   },
>   .tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
>   .tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
> - .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
> - ETH_TXQ_FLAGS_NOOFFLOADS,
>   .offloads = 0,
>   };
> 
> --
> 2.13.6



[dpdk-dev] [PATCH 0/3] remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
The patchset remove txq_flags dependence on Intel devices: ixgbe, e1000, fm10k.
(i40e has been covered on another fix patchset)

Qi Zhang (3):
  net/ixgbe: remove dependence on Tx queue flags
  net/e1000: remove dependence on Tx queue flags
  net/fm10k: remove dependence on Tx queue flags

 drivers/net/e1000/igb_ethdev.c   | 2 --
 drivers/net/fm10k/fm10k.h| 1 -
 drivers/net/fm10k/fm10k_ethdev.c | 4 +---
 drivers/net/ixgbe/ixgbe_ethdev.c | 6 --
 drivers/net/ixgbe/ixgbe_rxtx.c   | 2 --
 drivers/net/ixgbe/ixgbe_rxtx.h   | 1 -
 6 files changed, 1 insertion(+), 15 deletions(-)

-- 
2.13.6



[dpdk-dev] [PATCH 1/3] net/ixgbe: remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
Since we move to new offload APIs, txq_flags is no long needed.
This patch remove the dependence on that.

Fixes: 51215925a32f ("net/ixgbe: convert to new Tx offloads API")

Signed-off-by: Qi Zhang 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 6 --
 drivers/net/ixgbe/ixgbe_rxtx.c   | 2 --
 drivers/net/ixgbe/ixgbe_rxtx.h   | 1 -
 3 files changed, 9 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 6088c7e48..709251fbb 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3727,9 +3727,6 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = IXGBE_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = IXGBE_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-ETH_TXQ_FLAGS_NOOFFLOADS |
-ETH_TXQ_FLAGS_IGNORE,
.offloads = 0,
};
 
@@ -3835,9 +3832,6 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
},
.tx_free_thresh = IXGBE_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = IXGBE_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-ETH_TXQ_FLAGS_NOOFFLOADS |
-ETH_TXQ_FLAGS_IGNORE,
.offloads = 0,
};
 
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2892436e9..47045ddd0 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2620,7 +2620,6 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->reg_idx = (uint16_t)((RTE_ETH_DEV_SRIOV(dev).active == 0) ?
queue_idx : RTE_ETH_DEV_SRIOV(dev).def_pool_q_idx + queue_idx);
txq->port_id = dev->data->port_id;
-   txq->txq_flags = tx_conf->txq_flags;
txq->offloads = tx_conf->offloads;
txq->ops = &def_txq_ops;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
@@ -5441,7 +5440,6 @@ ixgbe_txq_info_get(struct rte_eth_dev *dev, uint16_t 
queue_id,
 
qinfo->conf.tx_free_thresh = txq->tx_free_thresh;
qinfo->conf.tx_rs_thresh = txq->tx_rs_thresh;
-   qinfo->conf.txq_flags = txq->txq_flags;
qinfo->conf.offloads = txq->offloads;
qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
 }
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index 7dbbbe5b3..20ef7b6ff 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -222,7 +222,6 @@ struct ixgbe_tx_queue {
uint8_t pthresh;   /**< Prefetch threshold register. */
uint8_t hthresh;   /**< Host threshold register. */
uint8_t wthresh;   /**< Write-back threshold reg. */
-   uint32_t txq_flags; /**< Holds flags for this TXq */
uint64_t offloads; /**< Tx offload flags of DEV_TX_OFFLOAD_* */
uint32_tctx_curr;  /**< Hardware context states. */
/** Hardware context0 history. */
-- 
2.13.6



[dpdk-dev] [PATCH 3/3] net/fm10k: remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
Since we move to new offload APIs, txq_flags is no long needed.
This patch remove the dependence on that.

Fixes: 30f3ce999e6a ("net/fm10k: convert to new Tx offloads API")

Signed-off-by: Qi Zhang 
---
 drivers/net/fm10k/fm10k.h| 1 -
 drivers/net/fm10k/fm10k_ethdev.c | 4 +---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index ce0f2c8f4..ef3078091 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -212,7 +212,6 @@ struct fm10k_tx_queue {
uint16_t next_rs; /* Next pos to set RS flag */
uint16_t next_dd; /* Next pos to check DD flag */
volatile uint32_t *tail_ptr;
-   uint32_t txq_flags; /* Holds flags for this TXq */
uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
uint16_t nb_desc;
uint16_t port_id;
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 7dfeddfe0..612490bef 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1442,7 +1442,6 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
},
.tx_free_thresh = FM10K_TX_FREE_THRESH_DEFAULT(0),
.tx_rs_thresh = FM10K_TX_RS_THRESH_DEFAULT(0),
-   .txq_flags = FM10K_SIMPLE_TX_FLAG,
.offloads = 0,
};
 
@@ -2114,7 +2113,6 @@ fm10k_tx_queue_setup(struct rte_eth_dev *dev, uint16_t 
queue_id,
q->nb_desc = nb_desc;
q->port_id = dev->data->port_id;
q->queue_id = queue_id;
-   q->txq_flags = conf->txq_flags;
q->offloads = conf->offloads;
q->ops = &def_txq_ops;
q->tail_ptr = (volatile uint32_t *)
@@ -2981,7 +2979,7 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
uint16_t tx_ftag_en = 0;
 
if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
-   /* primary process has set the ftag flag and txq_flags */
+   /* primary process has set the ftag flag and offloads */
txq = dev->data->tx_queues[0];
if (fm10k_tx_vec_condition_check(txq)) {
dev->tx_pkt_burst = fm10k_xmit_pkts;
-- 
2.13.6



[dpdk-dev] [PATCH 2/3] net/e1000: remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
Since we move to new offload APIs, txq_flags is no long needed.
This patch remove the dependence on that.

Fixes: e5c05e6590ea ("net/e1000: convert to new Tx offloads API")

Signed-off-by: Qi Zhang 
---
 drivers/net/e1000/igb_ethdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 140334772..04d34bdf6 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -2228,7 +2228,6 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.hthresh = IGB_DEFAULT_TX_HTHRESH,
.wthresh = IGB_DEFAULT_TX_WTHRESH,
},
-   .txq_flags = 0,
.offloads = 0,
};
 
@@ -2319,7 +2318,6 @@ eth_igbvf_infos_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.hthresh = IGB_DEFAULT_TX_HTHRESH,
.wthresh = IGB_DEFAULT_TX_WTHRESH,
},
-   .txq_flags = 0,
.offloads = 0,
};
 
-- 
2.13.6



[dpdk-dev] [PATCH v2 2/2] net/i40e: remove dependence on Tx queue flags

2018-05-01 Thread Qi Zhang
Since we move to new offload APIs, txq_flags is no long needed.
This patch remove the dependence on that.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")

Signed-off-by: Qi Zhang 
---

v2:
- remove wrong fixes line.

 drivers/net/i40e/i40e_ethdev.c | 2 --
 drivers/net/i40e/i40e_ethdev_vf.c  | 2 --
 drivers/net/i40e/i40e_rxtx.c   | 4 +---
 drivers/net/i40e/i40e_rxtx.h   | 1 -
 drivers/net/i40e/i40e_vf_representor.c | 2 --
 5 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index a001d5b99..92ee6c5ae 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3343,8 +3343,6 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index de5f460e9..b9dea2e5b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2236,8 +2236,6 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 755109ee5..62985c3a9 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1237,7 +1237,7 @@ i40e_tx_free_bufs(struct i40e_tx_queue *txq)
for (i = 0; i < txq->tx_rs_thresh; i++)
rte_prefetch0((txep + i)->mbuf);
 
-   if (txq->txq_flags & (uint32_t)ETH_TXQ_FLAGS_NOREFCOUNT) {
+   if (txq->offloads & DEV_TX_OFFLOAD_MBUF_FAST_FREE) {
for (i = 0; i < txq->tx_rs_thresh; ++i, ++txep) {
rte_mempool_put(txep->mbuf->pool, txep->mbuf);
txep->mbuf = NULL;
@@ -2297,7 +2297,6 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->queue_id = queue_idx;
txq->reg_idx = reg_idx;
txq->port_id = dev->data->port_id;
-   txq->txq_flags = tx_conf->txq_flags;
txq->offloads = tx_conf->offloads;
txq->vsi = vsi;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
@@ -2951,7 +2950,6 @@ i40e_txq_info_get(struct rte_eth_dev *dev, uint16_t 
queue_id,
 
qinfo->conf.tx_free_thresh = txq->tx_free_thresh;
qinfo->conf.tx_rs_thresh = txq->tx_rs_thresh;
-   qinfo->conf.txq_flags = txq->txq_flags;
qinfo->conf.tx_deferred_start = txq->tx_deferred_start;
 }
 
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 10feec4a2..ea73a8a1b 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -142,7 +142,6 @@ struct i40e_tx_queue {
uint16_t port_id; /**< Device port identifier. */
uint16_t queue_id; /**< TX queue index. */
uint16_t reg_idx;
-   uint32_t txq_flags;
struct i40e_vsi *vsi; /**< the VSI this queue belongs to */
uint16_t tx_next_dd;
uint16_t tx_next_rs;
diff --git a/drivers/net/i40e/i40e_vf_representor.c 
b/drivers/net/i40e/i40e_vf_representor.c
index 95c6696b8..96b378792 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -80,8 +80,6 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev *ethdev,
},
.tx_free_thresh = I40E_DEFAULT_TX_FREE_THRESH,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
-   .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
-   ETH_TXQ_FLAGS_NOOFFLOADS,
.offloads = 0,
};
 
-- 
2.13.6



[dpdk-dev] [PATCH v2 1/2] net/i40e: fix queue offload initialize

2018-05-01 Thread Qi Zhang
Add missing queue offload initialization.

Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
Fixes: c3ac7c5b0b8a ("net/i40e: convert to new Rx offloads API")

Signed-off-by: Qi Zhang 
---

v2: 
- add missing part in i40e_vf_represent.

 drivers/net/i40e/i40e_ethdev.c | 1 +
 drivers/net/i40e/i40e_ethdev_vf.c  | 1 +
 drivers/net/i40e/i40e_rxtx.c   | 2 ++
 drivers/net/i40e/i40e_vf_representor.c | 2 ++
 4 files changed, 6 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 284e9cb64..a001d5b99 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3345,6 +3345,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 48e7ac21e..de5f460e9 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2238,6 +2238,7 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 006f5b846..755109ee5 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -1857,6 +1857,7 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->drop_en = rx_conf->rx_drop_en;
rxq->vsi = vsi;
rxq->rx_deferred_start = rx_conf->rx_deferred_start;
+   rxq->offloads = rx_conf->offloads;
 
/* Allocate the maximun number of RX ring hardware descriptor. */
len = I40E_MAX_RING_DESC;
@@ -2297,6 +2298,7 @@ i40e_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->reg_idx = reg_idx;
txq->port_id = dev->data->port_id;
txq->txq_flags = tx_conf->txq_flags;
+   txq->offloads = tx_conf->offloads;
txq->vsi = vsi;
txq->tx_deferred_start = tx_conf->tx_deferred_start;
 
diff --git a/drivers/net/i40e/i40e_vf_representor.c 
b/drivers/net/i40e/i40e_vf_representor.c
index a8aa0115d..95c6696b8 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -69,6 +69,7 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev *ethdev,
},
.rx_free_thresh = I40E_DEFAULT_RX_FREE_THRESH,
.rx_drop_en = 0,
+   .offloads = 0,
};
 
dev_info->default_txconf = (struct rte_eth_txconf) {
@@ -81,6 +82,7 @@ i40e_vf_representor_dev_infos_get(struct rte_eth_dev *ethdev,
.tx_rs_thresh = I40E_DEFAULT_TX_RSBIT_THRESH,
.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
ETH_TXQ_FLAGS_NOOFFLOADS,
+   .offloads = 0,
};
 
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
-- 
2.13.6



Re: [dpdk-dev] [PATCH 00/12] Vhost: CVE-2018-1059 fixes

2018-05-01 Thread Yao, Lei A
Hi, Maxime

During the 18.05-rc1 performance testing, I find this patch set will bring
slightly performance drop on mergeable and normal path, and big performance
drop on vector path. Could you have a check on this? I know this patch is 
important for security. Not sure if there is any way to improve the performance.

Mergebale   
packet size 
64  0.80%
128 -2.75%
260 -2.93%
520 -2.72%
1024-1.18%
1500-0.65%

Normal  
packet size 
64  -1.47%
128 -7.43%
260 -3.66%
520 -2.52%
1024-1.19%
1500-0.78%

Vector  
packet size 
64  -8.60%
128 -3.54%
260 -2.63%
520 -6.12%
1024-1.05%
1500-1.20% 

CPU info: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
OS: Ubuntu 16.04

BRs
Lei

> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Maxime Coquelin
> Sent: Monday, April 23, 2018 11:58 PM
> To: dev@dpdk.org
> Cc: Maxime Coquelin 
> Subject: [dpdk-dev] [PATCH 00/12] Vhost: CVE-2018-1059 fixes
> 
> This series fixes the security vulnerability referenced
> as CVE-2018-1059.
> 
> Patches are already applied to the branch, but reviews
> are encouraged. Any issues spotted would be fixed on top.
> 
> Maxime Coquelin (12):
>   vhost: fix indirect descriptors table translation size
>   vhost: check all range is mapped when translating GPAs
>   vhost: introduce safe API for GPA translation
>   vhost: ensure all range is mapped when translating QVAs
>   vhost: add support for non-contiguous indirect descs tables
>   vhost: handle virtually non-contiguous buffers in Tx
>   vhost: handle virtually non-contiguous buffers in Rx
>   vhost: handle virtually non-contiguous buffers in Rx-mrg
>   examples/vhost: move to safe GPA translation API
>   examples/vhost_scsi: move to safe GPA translation API
>   vhost/crypto: move to safe GPA translation API
>   vhost: deprecate unsafe GPA translation API
> 
>  examples/vhost/virtio_net.c|  94 +++-
>  examples/vhost_scsi/vhost_scsi.c   |  56 -
>  lib/librte_vhost/rte_vhost.h   |  46 
>  lib/librte_vhost/rte_vhost_version.map |   4 +-
>  lib/librte_vhost/vhost.c   |  39 ++--
>  lib/librte_vhost/vhost.h   |   8 +-
>  lib/librte_vhost/vhost_crypto.c|  65 --
>  lib/librte_vhost/vhost_user.c  |  58 +++--
>  lib/librte_vhost/virtio_net.c  | 411 -
> 
>  9 files changed, 650 insertions(+), 131 deletions(-)
> 
> --
> 2.14.3



Re: [dpdk-dev] [PATCH] use SPDX license tag in Mellanox copyrighted files

2018-05-01 Thread Hemant Agrawal
>Some files were left with full license and wrong copyright format.
>They are switched to this format:
>   SPDX-License-Identifier: BSD-3-Clause
>   Copyright 2017 Mellanox Technologies, Ltd
>
>Fixes: 5feecc57d90b ("align SPDX Mellanox copyrights")

Acked-by: Hemant Agrawal 



Re: [dpdk-dev] ethdev flags and capabilities

2018-05-01 Thread Shahaf Shuler
Tuesday, May 1, 2018 11:41 PM, Thomas Monjalon:
> Subject: [dpdk-dev] ethdev flags and capabilities
> 
> Since DPDK 18.05-rc1, we have 2 new fields in rte_eth_dev_info:
>   const uint32_t *dev_flags;
>   uint64_t dev_capa;
> 
> The field dev_flags
> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> dk.org%2Fcommit%2F736b30ebf2&data=02%7C01%7Cshahafs%40mellanox.c
> om%7C16eef57203764ae7fc2208d5afa3e448%7Ca652971c7d2e4d9ba6a4d149
> 256f461b%7C0%7C0%7C636608040838595097&sdata=u6Vxc6hK6cdWprool%2
> FtZZN6GuVi72gg0Uvxenf6d5r0%3D&reserved=0)
> is a pointer to rte_eth_dev_data.dev_flags for these bits:
>   RTE_ETH_DEV_INTR_LSC
>   RTE_ETH_DEV_BONDED_SLAVE
>   RTE_ETH_DEV_INTR_RMV
>   RTE_ETH_DEV_REPRESENTOR
> 
> The field dev_capa
> (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdp
> dk.org%2Fcommit%2Fcac923cfea&data=02%7C01%7Cshahafs%40mellanox.c
> om%7C16eef57203764ae7fc2208d5afa3e448%7Ca652971c7d2e4d9ba6a4d149
> 256f461b%7C0%7C0%7C636608040838595097&sdata=YyB0S2vzSQgXpU4XP5H
> YEBb%2B35jUnGGOEbyWR4tsfxs%3D&reserved=0)
> is an integer for these bits:
>   RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP
>   RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP
> 
> How can we merge them?
> Should we move the capabilities in rte_eth_dev_data.dev_flags?
> Or do we want to keep the capabilities in rte_eth_dev_info?
> Is it OK to use pointers in rte_eth_dev_info or should we make a copy of
> rte_eth_dev_data fields?
> 
> We need to take a decision before RC3. Thanks

As I wrote on the comments on one of the series[1]

I think the first stage is to distinguish between an attribute of a port and 
capability of a port. 
e.g. REPRESENTOR is port attribute, while supporting interrupts is capability. 

So I think we still need the two fields, but need to make some order.

1. Capabilities should have RTE_ETH_DEV_CAPA prefix and attributes should have 
RTE_ETH_DEV_ATTR prefix. 
2. dev_flags is not a good name. flags is too generic word.
3. RTE_ETH_DEV_BONDED_SLAVE should not be exposed to application. 


[1] http://dpdk.org/ml/archives/dev/2018-March/094146.html




> 



Re: [dpdk-dev] ethdev new offloading API switch in PMDs

2018-05-01 Thread Shahaf Shuler
Tuesday, May 1, 2018 5:01 PM, Ferruh Yigit:
> Subject: ethdev new offloading API switch in PMDs
> 
> Hi,
> 
> Following PMDs still has .txq_flags in use, after basic grep, no in-dept
> investigation done.
> 
> With PMDs switch to new API, that flag no longer should be needed.
> 
> Old applications still use it but ethdev converts them to the offloads, so 
> that
> PMDs can only concern about offloads.
> 

Full removal of txq_flags can be done only after we will mitigate the "queue 
offloads must match port offload" constrain. 

> Can maintainer of following PMDs please check their offloading API
> implementation:
> 
> axgbe
> bnxt
> e1000
> ena
> failsafe
> fm10k
> i40e
> ixgbe
> mlx4
> mlx5
> octeontx
> qede
> sfc
> tap
> thunderx
> virtio
> vmxnet3


Re: [dpdk-dev] [PATCH v2] net/i40e: fix missing some offload capabilities

2018-05-01 Thread Zhang, Qi Z
> -Original Message-
> From: Wu, Yanglong
> Sent: Saturday, April 28, 2018 5:37 PM
> To: dev@dpdk.org
> Cc: Zhang, Helin ; Zhang, Qi Z
> ; Dai, Wei ; Wu, Yanglong
> 
> Subject: [PATCH v2] net/i40e: fix missing some offload capabilities
> 
> MULTI_SEGS and JUMBO_FRAME offload capability should be exposed both
> VF and PF since i40e does support it.
> 
> Fixes: c3ac7c5b0b8a ("net/i40e: convert to new Rx offloads API")
> Fixes: 7497d3e2f777 ("net/i40e: convert to new Tx offloads API")
> Signed-off-by: Yanglong Wu 

Acked-by: Qi Zhang 



[dpdk-dev] [PATCH] net/mlx5: fix device reference in secondary process

2018-05-01 Thread Yongseok Koh
rte_eth_devices[] is not shared between primary and secondary process, but
a static array to each process. The backward pointer of device (priv->dev)
must be reset when a secondary process attaches to a device.

Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file descriptor")
Cc: sta...@dpdk.org

Signed-off-by: Yongseok Koh 
---
 drivers/net/mlx5/mlx5.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 8f983061a..f606e3dd4 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -799,6 +799,12 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
}
eth_dev->device = &pci_dev->device;
eth_dev->dev_ops = &mlx5_dev_sec_ops;
+   /*
+* rte_eth_devices[] is not shared but static to each
+* process. The backward pointer should be reset.
+*/
+   priv = eth_dev->data->dev_private;
+   priv->dev = eth_dev;
err = mlx5_uar_init_secondary(eth_dev);
if (err)
goto error;
-- 
2.11.0



Re: [dpdk-dev] [PATCH v2 2/2] net/mlx5: add Rx and Tx tuning parameters

2018-05-01 Thread Nélio Laranjeiro
On Tue, May 01, 2018 at 12:58:49PM +0300, Shahaf Shuler wrote:
> A new ethdev API was exposed by
> commit 3be82f5cc5e3 ("ethdev: support PMD-tuned Tx/Rx parameters")
> 
> Enabling the PMD to provide default parameters in case no strict request
> from application in order to improve the out of the box experience.
> 
> While the current API lacks the means for the PMD to provide the best
> possible value, providing the best default the PMD can guess.
> The values are based on Mellanox performance report and depends on the
> underlying NIC capabilities.
> 
> Cc: ere...@mellanox.com
> Cc: am...@mellanox.com
> Cc: ol...@mellanox.com
> 
> Signed-off-by: Shahaf Shuler 

Acked-by: Nelio Laranjeiro 

> ---
> 
> On v2:
>  - refactor the code to ease the maintenance.
> 
> ---
>  drivers/net/mlx5/mlx5_ethdev.c | 40 
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index 588d4ba627..3fad199a60 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -417,6 +417,45 @@ mlx5_dev_configure(struct rte_eth_dev *dev)
>  }
>  
>  /**
> + * Sets default tuning parameters.
> + *
> + * @param dev
> + *   Pointer to Ethernet device.
> + * @param[out] info
> + *   Info structure output buffer.
> + */
> +static void
> +mlx5_set_default_params(struct rte_eth_dev *dev, struct rte_eth_dev_info 
> *info)
> +{
> + struct priv *priv = dev->data->dev_private;
> +
> + /* Minimum CPU utilization. */
> + info->default_rxportconf.ring_size = 256;
> + info->default_txportconf.ring_size = 256;
> + info->default_rxportconf.burst_size = 64;
> + info->default_txportconf.burst_size = 64;
> + if (priv->link_speed_capa & ETH_LINK_SPEED_100G) {
> + info->default_rxportconf.nb_queues = 16;
> + info->default_txportconf.nb_queues = 16;
> + if (dev->data->nb_rx_queues > 2 ||
> + dev->data->nb_tx_queues > 2) {
> + /* Max Throughput. */
> + info->default_rxportconf.ring_size = 2048;
> + info->default_txportconf.ring_size = 2048;
> + }
> + } else {
> + info->default_rxportconf.nb_queues = 8;
> + info->default_txportconf.nb_queues = 8;
> + if (dev->data->nb_rx_queues > 2 ||
> + dev->data->nb_tx_queues > 2) {
> + /* Max Throughput. */
> + info->default_rxportconf.ring_size = 4096;
> + info->default_txportconf.ring_size = 4096;
> + }
> + }
> +}
> +
> +/**
>   * DPDK callback to get information about the device.
>   *
>   * @param dev
> @@ -458,6 +497,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct 
> rte_eth_dev_info *info)
>   info->hash_key_size = rss_hash_default_key_len;
>   info->speed_capa = priv->link_speed_capa;
>   info->flow_type_rss_offloads = ~MLX5_RSS_HF_MASK;
> + mlx5_set_default_params(dev, info);
>  }
>  
>  /**
> -- 
> 2.12.0
> 

Thanks,

-- 
Nélio Laranjeiro
6WIND


Re: [dpdk-dev] [PATCH 2/2] net/mlx5: fix probe return value polarity

2018-05-01 Thread Nélio Laranjeiro
On Wed, May 02, 2018 at 01:54:37AM +, Yongseok Koh wrote:
> 
> > On May 1, 2018, at 4:18 AM, Shahaf Shuler  wrote:
> > 
> > mlx5 prefixed function returns a negative errno value.
> > the error handler on mlx5_pci_probe is doing the same.
> > 
> > Fixes: a6d83b6a9209 ("net/mlx5: standardize on negative errno values")
> > Cc: nelio.laranje...@6wind.com
> > 
> > Signed-off-by: Shahaf Shuler 
> > ---
> > drivers/net/mlx5/mlx5.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> > index 46cb370a29..ab860b5985 100644
> > --- a/drivers/net/mlx5/mlx5.c
> > +++ b/drivers/net/mlx5/mlx5.c
> > @@ -804,12 +804,16 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> > __rte_unused,
> > goto error;
> 
> Shouldn't you do the same for mlx5_uar_init_secondary()?
> Looks like a few more. E.g. mlx5_args(), mlx5_get_mtu() and 
> mlx5_uar_init_primary().
> What about ibv_query_port() and mlx5_flow_create_drop_queue()? 
> 
> Thanks
> 
> > /* Receive command fd from primary process */
> > err = mlx5_socket_connect(eth_dev);
> > -   if (err < 0)
> > +   if (err < 0) {
> > +   err = -err;
> 
> Instead of changing sign, how about 'err = rte_errno;' ?

+1

> However, err looks redundant to me because mlx5_* funcs set rte_errno.

Not it is not, rte_errno is the strict equivalent of errno but instead
of being global to the process, it is global per logical core, its
cannot be determined nor modified at the beginning of the function thus
the function must track any failure and report it accordingly.

> Here, err is used to set rte_errno at the end.

It is just a optimization to avoid a lot of rte_errno sets among the
function, it must only be set if err != 0.

> Thanks,
> Yongseok
> 
> > goto error;
> > +   }
> > /* Remap UAR for Tx queues. */
> > err = mlx5_tx_uar_remap(eth_dev, err);
> > -   if (err)
> > +   if (err) {
> > +   err = -err;
> > goto error;
> > +   }
> > /*
> >  * Ethdev pointer is still required as input since
> >  * the primary device is not accessible from the
> > -- 
> > 2.12.0
> > 
 
Regards,

-- 
Nélio Laranjeiro
6WIND


Re: [dpdk-dev] [PATCH 1/2] net/mlx5: fix socket connection return value

2018-05-01 Thread Nélio Laranjeiro
On Tue, May 01, 2018 at 02:18:05PM +0300, Shahaf Shuler wrote:
> Upon success, mlx5_socket_connect should return the fd descriptor of the
> primary process
> 
> Fixes: a6d83b6a9209 ("net/mlx5: standardize on negative errno values")
> Cc: nelio.laranje...@6wind.com
> 
> Signed-off-by: Yongseok Koh 
> Signed-off-by: Shahaf Shuler 

Acked-by: Nelio Laranjeiro 

> ---
>  drivers/net/mlx5/mlx5.c| 2 +-
>  drivers/net/mlx5/mlx5_socket.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 8f983061a0..46cb370a29 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -804,7 +804,7 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   goto error;
>   /* Receive command fd from primary process */
>   err = mlx5_socket_connect(eth_dev);
> - if (err)
> + if (err < 0)
>   goto error;
>   /* Remap UAR for Tx queues. */
>   err = mlx5_tx_uar_remap(eth_dev, err);
> diff --git a/drivers/net/mlx5/mlx5_socket.c b/drivers/net/mlx5/mlx5_socket.c
> index e12c4cb2e1..99297d5c43 100644
> --- a/drivers/net/mlx5/mlx5_socket.c
> +++ b/drivers/net/mlx5/mlx5_socket.c
> @@ -294,7 +294,7 @@ mlx5_socket_connect(struct rte_eth_dev *dev)
>   }
>   ret = *fd;
>   close(socket_fd);
> - return 0;
> + return ret;
>  error:
>   if (socket_fd != -1)
>   close(socket_fd);
> -- 
> 2.12.0
> 

-- 
Nélio Laranjeiro
6WIND


Re: [dpdk-dev] [PATCH] net/mlx5: fix device reference in secondary process

2018-05-01 Thread Nélio Laranjeiro
On Tue, May 01, 2018 at 11:13:20PM -0700, Yongseok Koh wrote:
> rte_eth_devices[] is not shared between primary and secondary process, but
> a static array to each process. The backward pointer of device (priv->dev)
> must be reset when a secondary process attaches to a device.
> 
> Fixes: f8b9a3bad467 ("net/mlx5: install a socket to exchange a file 
> descriptor")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Yongseok Koh 
Acked-by: Nelio Laranjeiro 
> ---
>  drivers/net/mlx5/mlx5.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
> index 8f983061a..f606e3dd4 100644
> --- a/drivers/net/mlx5/mlx5.c
> +++ b/drivers/net/mlx5/mlx5.c
> @@ -799,6 +799,12 @@ mlx5_pci_probe(struct rte_pci_driver *pci_drv 
> __rte_unused,
>   }
>   eth_dev->device = &pci_dev->device;
>   eth_dev->dev_ops = &mlx5_dev_sec_ops;
> + /*
> +  * rte_eth_devices[] is not shared but static to each
> +  * process. The backward pointer should be reset.
> +  */
> + priv = eth_dev->data->dev_private;
> + priv->dev = eth_dev;
>   err = mlx5_uar_init_secondary(eth_dev);
>   if (err)
>   goto error;
> -- 
> 2.11.0
> 

-- 
Nélio Laranjeiro
6WIND