Re: [dpdk-dev] [dpdk-stable] [PATCH v4] net/bonding: per-slave intermediate rx ring

2018-09-02 Thread Matan Azrad
Hi Luca\Chas

From: Luca Boccassi
> On Wed, 2018-08-29 at 15:20 +, Matan Azrad wrote:
> >
> > From: Chas Williams
> > > On Tue, Aug 28, 2018 at 5:51 AM Matan Azrad  > > com> wrote:
> > >
> > >
> > > From: Chas Williams
> > > > On Mon, Aug 27, 2018 at 11:30 AM Matan Azrad  > > > @mellanox.com> wrote:
> > >
> > > 
> > > > > > Because rings are generally quite efficient.
> > > > >
> > > > > But you are using a ring in addition to regular array
> > > > > management, it must hurt performance of the bonding PMD (means
> > > > > the bonding itself - not the slaves PMDs which are called from
> > > > > the bonding)
> > > >
> > > > It adds latency.
> > >
> > > And by that hurts the application performance because it takes more
> > > CPU time in the bonding PMD.
> > >
> > > No, as I said before it takes _less_ CPU time in the bonding PMD
> > > because we use a more optimal read from the slaves.
> >
> > Each packet pointer should be copied more 2 times because of this
> > patch + some management(the ring overhead) So in the bonding code you
> > lose performance.
> >
> > >
> > > > It increases performance because we spend less CPU time reading
> > > > from the PMDs.
> > >
> > > So, it's hack in the bonding PMD to improve some slaves code
> > > performance but hurt the bonding code performance, Over all the
> > > performance we gain for those slaves improves the application
> > > performance only when working with those slaves.
> > > But may hurt the application performance when working with other
> > > slaves.
> > >
> > > What is your evidence that is hurts bonding performance?  Your
> > > argument is purely theoretical.
> >
> > Yes, we cannot test all the scenarios cross the PMDs.
> 
> Chas has evidence that this helps, a _lot_, in some very common cases.
> We haven't seen evidence of negative impact anywhere in 2 years. Given
> this, surely it's not unreasonable to ask to substantiate theoretical 
> arguments
> with some testing?

What is the common cases of the bond usage?
Do you really know all the variance of the bond usages spreading all over the 
world?

I’m saying that using a hack in the bond code which helps for some slaves 
PMDs\application scenarios (your common cases) but hurting
the bond code performance and latency is not the right thing to do because it 
may hurt other scenarios\PMDs  using the bond.





[dpdk-dev] [PATCH] net/mlx5: add bluefield vf support

2018-09-02 Thread Ori Kam
Signed-off-by: Ori Kam 
---
 drivers/net/mlx5/mlx5.c | 4 
 drivers/net/mlx5/mlx5.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 30d4e70..fd89e2a 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -1489,6 +1489,10 @@ struct mlx5_dev_spawn_data {
   PCI_DEVICE_ID_MELLANOX_CONNECTX5BF)
},
{
+   RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX,
+  PCI_DEVICE_ID_MELLANOX_CONNECTX5BFVF)
+   },
+   {
.vendor_id = 0
}
 };
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 35a196e..4d3e9f3 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -51,6 +51,7 @@ enum {
PCI_DEVICE_ID_MELLANOX_CONNECTX5EX = 0x1019,
PCI_DEVICE_ID_MELLANOX_CONNECTX5EXVF = 0x101a,
PCI_DEVICE_ID_MELLANOX_CONNECTX5BF = 0xa2d2,
+   PCI_DEVICE_ID_MELLANOX_CONNECTX5BFVF = 0xa2d3,
 };
 
 /** Switch information returned by mlx5_nl_switch_info(). */
-- 
1.8.3.1



Re: [dpdk-dev] [dpdk-stable] [PATCH 17.11] mem: fix max DMA maskbit size

2018-09-02 Thread Yongseok Koh


> On Aug 31, 2018, at 7:53 AM, Alejandro Lucero 
>  wrote:
> 
> The sanity check inside rte_eal_check_dma_mask is using 47 bits as
> the maximum size. It turns out there are some IOMMU hardware reporting
> 48 bits precluding the IOVA VA mode to be enabled.
> 
> It is harmless to raise the maximum mask size to 63 bits.
> 
> This patch also removes any reference to unused X86_VA_WIDTH.
> 
> Fixes: 3a80bc50c949 ("mem: add function for checking memsegs IOVAs addresses")
> 
> Signed-off-by: Alejandro Lucero 
> ---

Applied to stable/17.11.

Thanks,
Yongseok

[dpdk-dev] [PATCH v2] build: enable Arm NEON flags when __aarch64__ is defined

2018-09-02 Thread Honnappa Nagarahalli
GCC version 4.8.5 does not pre-define __ARM_NEON. NEON is not
optional for ArmV8. Hence NEON related code can be enabled
when __aarch64__ is defined.

Bugzilla ID: 82
Cc: sta...@dpdk.org

Reported-by: Raslan Darawsheh 
Reported-by: Thomas F Herbert 
Signed-off-by: Honnappa Nagarahalli 
Reviewed-by: Phil Yang 
Reviewed-by: Gavin Hu 
Acked-by: Gavin Hu 
Acked-by: Jerin Jacob 
---
V2:
* Corrected the order of contribution tags
* Added Jerin's Ack

 config/arm/meson.build | 3 ++-
 mk/rte.cpuflags.mk | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/config/arm/meson.build b/config/arm/meson.build
index 40dbc87..94cca49 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -157,7 +157,8 @@ else
 endif
 message(machine_args)
 
-if cc.get_define('__ARM_NEON', args: machine_args) != ''
+if (cc.get_define('__ARM_NEON', args: machine_args) != '' or
+cc.get_define('__aarch64__', args: machine_args) != '')
dpdk_conf.set('RTE_MACHINE_CPUFLAG_NEON', 1)
compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
 endif
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index 6071313..43ed841 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -89,7 +89,7 @@ CPUFLAGS += VSX
 endif
 
 # ARM flags
-ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_NEON),)
+ifneq ($(filter __ARM_NEON __aarch64__,$(AUTO_CPUFLAGS)),)
 CPUFLAGS += NEON
 endif
 
-- 
2.7.4



Re: [dpdk-dev] [PATCH v3] hash table: add an iterator over conflicting entries

2018-09-02 Thread Honnappa Nagarahalli
Hi Qiaobin,
Thank you for the patch. Please see few comments inline.

-Original Message-
From: Qiaobin Fu  
Sent: Friday, August 31, 2018 11:51 AM
To: bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com
Cc: dev@dpdk.org; douce...@bu.edu; keith.wi...@intel.com; 
sameh.gobr...@intel.com; charlie@intel.com; step...@networkplumber.org; nd 
; Honnappa Nagarahalli ; 
yipeng1.w...@intel.com; mic...@digirati.com.br; qiaob...@bu.edu
Subject: [PATCH v3] hash table: add an iterator over conflicting entries

Function rte_hash_iterate_conflict_entries() iterates over the entries that 
conflict with an incoming entry.

Iterating over conflicting entries enables one to decide if the incoming entry 
is more valuable than the entries already in the hash table. This is 
particularly useful after an insertion failure.

v3:
* Make the rte_hash_iterate() API similar to
  rte_hash_iterate_conflict_entries()

v2:
* Fix the style issue

* Make the API more universal

Signed-off-by: Qiaobin Fu 
Reviewed-by: Cody Doucette 
Reviewed-by: Michel Machado 
Reviewed-by: Keith Wiles 
Reviewed-by: Yipeng Wang 
Reviewed-by: Honnappa Nagarahalli 
---
 lib/librte_hash/Makefile |   1 +
 lib/librte_hash/rte_cuckoo_hash.c| 132 +++
 lib/librte_hash/rte_hash.h   |  80 ++--
 lib/librte_hash/rte_hash_version.map |   8 ++
 test/test/test_hash.c|   7 +-
 test/test/test_hash_multiwriter.c|   8 +-
 test/test/test_hash_readwrite.c  |  16 ++--
 7 files changed, 219 insertions(+), 33 deletions(-)

diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile index 
c8c435dfd..9be58a205 100644
--- a/lib/librte_hash/Makefile
+++ b/lib/librte_hash/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk  # library name  LIB = 
librte_hash.a
 
+CFLAGS += -DALLOW_EXPERIMENTAL_API
 CFLAGS += -O3
 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
 LDLIBS += -lrte_eal -lrte_ring
diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index f7b86c8c9..cf5b28196 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -1300,45 +1300,143 @@ rte_hash_lookup_bulk_data(const struct rte_hash *h, 
const void **keys,
return __builtin_popcountl(*hit_mask);  }
 
+/* istate stands for internal state. */ struct rte_hash_iterator_istate 
+{
+   const struct rte_hash *h;
This can be outside of this structure. This will help keep the API definitions 
consistent with existing APIs. Please see further comments below.

+   uint32_t  next;
+   uint32_t  total_entries;
+};
This structure can be moved to rte_cuckoo_hash.h file.

+

+int32_t
+rte_hash_iterator_init(const struct rte_hash *h,
+   struct rte_hash_iterator_state *state) {
+   struct rte_hash_iterator_istate *__state;
'__state' can be replaced by 's'.

+
+   RETURN_IF_TRUE(((h == NULL) || (state == NULL)), -EINVAL);
+
+   __state = (struct rte_hash_iterator_istate *)state;
+   __state->h = h;
+   __state->next = 0;
+   __state->total_entries = h->num_buckets * RTE_HASH_BUCKET_ENTRIES;
+
+   return 0;
+}
IMO, creating this API can be avoided if the initialization is handled in 
'rte_hash_iterate' function. The cost of doing this is very trivial (one extra 
'if' statement) in 'rte_hash_iterate' function. It will help keep the number of 
APIs to minimal.

+
 int32_t
-rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, 
uint32_t *next)
+rte_hash_iterate(
+   struct rte_hash_iterator_state *state, const void **key, void **data)

IMO, as suggested above, do not store 'struct rte_hash *h' in 'struct 
rte_hash_iterator_state'. Instead, change the API definition as follows:
rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, 
struct rte_hash_iterator_state *state)

This will help keep the API signature consistent with existing APIs.

This is an ABI change. Please take a look at 
https://doc.dpdk.org/guides/contributing/versioning.html.

 {
+   struct rte_hash_iterator_istate *__state;
'__state' can be replaced with 's'.

uint32_t bucket_idx, idx, position;
struct rte_hash_key *next_key;
 
-   RETURN_IF_TRUE(((h == NULL) || (next == NULL)), -EINVAL);
+   RETURN_IF_TRUE(((state == NULL) || (key == NULL) ||
+   (data == NULL)), -EINVAL);
+
+   __state = (struct rte_hash_iterator_istate *)state;
 
-   const uint32_t total_entries = h->num_buckets * RTE_HASH_BUCKET_ENTRIES;
/* Out of bounds */
-   if (*next >= total_entries)
+   if (__state->next >= __state->total_entries)
return -ENOENT;
 
'if (__state->next == 0)' is required to avoid creating 
'rte_hash_iterator_init' API.

/* Calculate bucket and index of current iterator */
-   bucket_idx = *next / RTE_HASH_BUCKET_ENTRIES;
-   idx = *next % RTE_HASH_BUCKET_ENTRIES;
+   bucket_idx = __state->next / RTE_

[dpdk-dev] [dpdk-announce] DPDK 17.11.4 released

2018-09-02 Thread Yongseok Koh
Hi all,

Here is a new stable release:
https://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz

The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=17.11

Thanks,
Yongseok

---
 MAINTAINERS|  12 +-
 app/test-crypto-perf/cperf_ops.c   |   3 +
 app/test-pmd/cmdline_tm.c  |  16 +-
 app/test-pmd/testpmd.c |  15 +-
 buildtools/pmdinfogen/Makefile |   2 +-
 doc/guides/nics/enic.rst   |  44 +++-
 doc/guides/nics/qede.rst   |  13 +-
 doc/guides/rel_notes/release_17_11.rst | 157 ++
 doc/guides/testpmd_app_ug/testpmd_funcs.rst|   2 +-
 drivers/bus/dpaa/base/fman/fman_hw.c   |  20 +-
 drivers/bus/dpaa/base/fman/of.c|   5 +
 drivers/bus/dpaa/include/compat.h  |   6 +
 drivers/bus/pci/linux/pci.c|  16 +-
 drivers/bus/pci/linux/pci_vfio.c   |   2 +-
 drivers/crypto/qat/qat_crypto.c|  10 +-
 drivers/event/octeontx/ssovf_evdev.c   |  14 +-
 drivers/net/bnx2x/bnx2x.c  |  24 +--
 drivers/net/bnx2x/bnx2x.h  |   1 +
 drivers/net/bnx2x/bnx2x_ethdev.c   | 214 ++-
 drivers/net/bnx2x/bnx2x_ethdev.h   |   3 +-
 drivers/net/bnxt/bnxt_ethdev.c |  35 +++-
 drivers/net/bnxt/bnxt_filter.c |   6 +-
 drivers/net/bnxt/bnxt_hwrm.c   |  51 +++--
 drivers/net/bnxt/bnxt_stats.c  |   3 +
 drivers/net/bnxt/bnxt_txr.c|  51 -
 drivers/net/bnxt/bnxt_txr.h|  10 +
 drivers/net/bnxt/bnxt_vnic.c   |   5 +-
 drivers/net/bnxt/bnxt_vnic.h   |   6 +-
 drivers/net/bonding/rte_eth_bond_api.c |  14 +-
 drivers/net/bonding/rte_eth_bond_pmd.c |  24 +--
 drivers/net/cxgbe/base/t4_hw.c |  97 +++--
 drivers/net/cxgbe/base/t4fw_interface.h|   8 +
 drivers/net/cxgbe/cxgbe_compat.h   |   9 -
 drivers/net/cxgbe/sge.c|  15 +-
 drivers/net/dpaa2/mc/dpni.c|   2 +-
 drivers/net/ena/base/ena_plat_dpdk.h   |  34 +--
 drivers/net/ena/ena_ethdev.c   |   4 +-
 drivers/net/enic/enic.h|   1 +
 drivers/net/enic/enic_ethdev.c |  67 ++
 drivers/net/enic/enic_main.c   |  34 +--
 drivers/net/i40e/i40e_ethdev.c | 149 ++
 drivers/net/i40e/rte_pmd_i40e.c|   1 +
 drivers/net/ixgbe/ixgbe_ethdev.h   |   5 +
 drivers/net/ixgbe/ixgbe_fdir.c |  30 ++-
 drivers/net/ixgbe/ixgbe_flow.c |  12 +-
 drivers/net/mlx4/mlx4.c|  44 ++--
 drivers/net/mlx4/mlx4.h|   1 +
 drivers/net/mlx4/mlx4_rxq.c|   6 +
 drivers/net/mlx5/Makefile  |  47 -
 drivers/net/mlx5/mlx5.c|   6 +-
 drivers/net/mlx5/mlx5_defs.h   |  10 +-
 drivers/net/mlx5/mlx5_ethdev.c |  26 +++
 drivers/net/mlx5/mlx5_flow.c   |  40 ++--
 drivers/net/mlx5/mlx5_rxmode.c |  16 ++
 drivers/net/mlx5/mlx5_rxtx.c   |  11 +-
 drivers/net/mlx5/mlx5_rxtx.h   |   2 +
 drivers/net/mlx5/mlx5_rxtx_vec.h   |   4 +-
 drivers/net/mlx5/mlx5_rxtx_vec_neon.h  |   8 +-
 drivers/net/mlx5/mlx5_rxtx_vec_sse.h   |   8 +-
 drivers/net/mlx5/mlx5_socket.c |   6 +
 drivers/net/mlx5/mlx5_trigger.c|  37 ++--
 drivers/net/mlx5/mlx5_txq.c|   2 +
 drivers/net/mrvl/mrvl_ethdev.c |   5 +-
 drivers/net/nfp/nfp_net.c  |  26 ++-
 drivers/net/octeontx/octeontx_ethdev.c |   6 +-
 drivers/net/pcap/rte_eth_pcap.c|  86 
 drivers/net/qede/base/ecore_dev.c  |  10 +-
 drivers/net/qede/base/ecore_int.c  |  14 +-
 drivers/net/qede/base/ecore_sriov.c|  44 
 drivers/net/qede/base/ecore_vf.c   |  33 +++
 drivers/net/qede/base/ecore_vf.h   |   9 +
 drivers/net/qede/base/ecore_vfpf_if.h  |  16 ++
 drivers/net/qede/qede_ethdev.c | 228 ++---
 drivers/net/qede/qede_ethdev.h |   1 +
 drivers/net/qede/qede_fdir.c   |   3 +
 drivers/net/qede/qede_main.c   |   7 +-
 drivers/net/sfc/sfc_ef10_rx.c  |   2 +
 drivers/net/sfc/sfc_ethde

Re: [dpdk-dev] [PATCH 1/4] mk: use script to generate examples.dox

2018-09-02 Thread Thomas Monjalon
31/08/2018 20:20, Luca Boccassi:
> +# SC2129 - avoid multiple individual redirects

What is SC2129 ?

> +{ \
> +printf '/**\n'; \
> +printf '@page examples DPDK Example Programs\n\n'; \
> +find "${EXAMPLES_DIR}" -type f -name '*.c' -printf '@example 
> examples/%P\n' | LC_ALL=C sort; \
> +printf '*/\n'; \
> +} > "${API_EXAMPLES}"

Why using backslashes (continuation lines)?





Re: [dpdk-dev] [PATCH 2/4] mk: use templated doxygen config, modified on the fly

2018-09-02 Thread Thomas Monjalon
Good idea.
While at putting all in the same file (template),
we can re-organize the template a bit.

31/08/2018 20:20, Luca Boccassi:
> --- /dev/null
> +++ b/doc/api/doxy-api.conf.in
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright 2013-2017 6WIND S.A.
> +
> +PROJECT_NAME= DPDK
> +INPUT   = @TOPDIR@/doc/api/doxy-api-index.md \
> +  @TOPDIR@/drivers/crypto/scheduler \
> +  @TOPDIR@/drivers/mempool/dpaa2 \
> +  @TOPDIR@/drivers/net/bnxt \
> +  @TOPDIR@/drivers/net/bonding \
> +  @TOPDIR@/drivers/net/dpaa \
> +  @TOPDIR@/drivers/net/i40e \
> +  @TOPDIR@/drivers/net/ixgbe \
> +  @TOPDIR@/drivers/net/softnic \
> +  @TOPDIR@/drivers/raw/dpaa2_cmdif \
> +  @TOPDIR@/drivers/raw/dpaa2_qdma \
> +  @TOPDIR@/lib/librte_eal/common/include \
> +  @TOPDIR@/lib/librte_eal/common/include/generic \
> +  @TOPDIR@/lib/librte_acl \
> +  @TOPDIR@/lib/librte_bbdev \
> +  @TOPDIR@/lib/librte_bitratestats \
> +  @TOPDIR@/lib/librte_bpf \
> +  @TOPDIR@/lib/librte_cfgfile \
> +  @TOPDIR@/lib/librte_cmdline \
> +  @TOPDIR@/lib/librte_compat \
> +  @TOPDIR@/lib/librte_compressdev \
> +  @TOPDIR@/lib/librte_cryptodev \
> +  @TOPDIR@/lib/librte_distributor \
> +  @TOPDIR@/lib/librte_efd \
> +  @TOPDIR@/lib/librte_ethdev \
> +  @TOPDIR@/lib/librte_eventdev \
> +  @TOPDIR@/lib/librte_flow_classify \
> +  @TOPDIR@/lib/librte_gro \
> +  @TOPDIR@/lib/librte_gso \
> +  @TOPDIR@/lib/librte_hash \
> +  @TOPDIR@/lib/librte_ip_frag \
> +  @TOPDIR@/lib/librte_jobstats \
> +  @TOPDIR@/lib/librte_kni \
> +  @TOPDIR@/lib/librte_kvargs \
> +  @TOPDIR@/lib/librte_latencystats \
> +  @TOPDIR@/lib/librte_lpm \
> +  @TOPDIR@/lib/librte_mbuf \
> +  @TOPDIR@/lib/librte_member \
> +  @TOPDIR@/lib/librte_mempool \
> +  @TOPDIR@/lib/librte_meter \
> +  @TOPDIR@/lib/librte_metrics \
> +  @TOPDIR@/lib/librte_net \
> +  @TOPDIR@/lib/librte_pci \
> +  @TOPDIR@/lib/librte_pdump \
> +  @TOPDIR@/lib/librte_pipeline \
> +  @TOPDIR@/lib/librte_port \
> +  @TOPDIR@/lib/librte_power \
> +  @TOPDIR@/lib/librte_rawdev \
> +  @TOPDIR@/lib/librte_reorder \
> +  @TOPDIR@/lib/librte_ring \
> +  @TOPDIR@/lib/librte_sched \
> +  @TOPDIR@/lib/librte_security \
> +  @TOPDIR@/lib/librte_table \
> +  @TOPDIR@/lib/librte_timer \
> +  @TOPDIR@/lib/librte_vhost
> +FILE_PATTERNS   = rte_*.h \
> +  cmdline.h
> +PREDEFINED  = __DOXYGEN__ \
> +VFIO_PRESENT \
> +  __attribute__(x)=
> +
> +OPTIMIZE_OUTPUT_FOR_C   = YES
> +ENABLE_PREPROCESSING= YES
> +MACRO_EXPANSION = YES
> +EXPAND_ONLY_PREDEF  = YES
> +EXTRACT_STATIC  = YES
> +DISTRIBUTE_GROUP_DOC= YES
> +HIDE_UNDOC_MEMBERS  = YES
> +HIDE_UNDOC_CLASSES  = YES
> +HIDE_SCOPE_NAMES= YES
> +GENERATE_DEPRECATEDLIST = NO
> +VERBATIM_HEADERS= NO
> +ALPHABETICAL_INDEX  = NO
> +
> +HTML_TIMESTAMP  = NO
> +HTML_DYNAMIC_SECTIONS   = YES
> +SEARCHENGINE= NO
> +SORT_MEMBER_DOCS= NO
> +SOURCE_BROWSER  = YES
> +
> +EXAMPLE_PATH= @TOPDIR@/examples
> +EXAMPLE_PATTERNS= *.c
> +EXAMPLE_RECURSIVE   = YES
> +
> +PROJECT_NUMBER  = @VERSION@

could be below PROJECT_NAME

> +INPUT   += @API_EXAMPLES@

can be at the end of INPUT list

> +OUTPUT_DIRECTORY= @OUTPUT@
> +HTML_OUTPUT = @HTML_OUTPUT@

can be below GENERATE_HTML

> +STRIP_FROM_PATH = @STRIP_FROM_PATH@
> +GENERATE_HTML   = YES
> +GENERATE_LATEX  = NO
> +GENERATE_MAN= NO





Re: [dpdk-dev] [PATCH 3/4] build: use same version as make showversion in Meson

2018-09-02 Thread Thomas Monjalon
31/08/2018 20:20, Luca Boccassi:
> make showversion will print 18.11.0-rc0 but Meson sets 18.11-rc0,
> causing among other things a difference in the generated documentation.
> 
> Fixes: 76b9d9de5c7d ("version: 18.11-rc0")
> 
> Signed-off-by: Luca Boccassi 

Acked-by: Thomas Monjalon 




Re: [dpdk-dev] [PATCH 4/4] build: generate API documentation with Meson

2018-09-02 Thread Thomas Monjalon
31/08/2018 20:20, Luca Boccassi:
> Both a configuration-time "enable_docs" boolean option and an optional
> 'ninja doc' target are available. Note that due to a Meson bug for now
> the latter will only build, but not install the files.
> 
> Signed-off-by: Luca Boccassi 
> ---
>  doc/api/generate_doxygen.sh | 10 
>  doc/api/meson.build | 51 +
>  doc/build-sdk-meson.txt |  2 ++
>  doc/meson.build |  4 +++
>  meson.build |  3 +++
>  meson_options.txt   |  2 ++
>  6 files changed, 72 insertions(+)

You use generate_doxygen.sh only with meson?
Shouldn't we use the same in mk/rte.sdkdoc.mk?




Re: [dpdk-dev] [PATCH] vhost: fix crash if set vring num handling failed

2018-09-02 Thread Tiwei Bie
On Thu, Aug 30, 2018 at 09:54:50AM +0300, Ilya Maximets wrote:
> On 30.08.2018 09:06, Tiwei Bie wrote:
> > On Wed, Aug 29, 2018 at 05:00:47PM +0300, Ilya Maximets wrote:
> >> Any thoughts on this?
> > 
> > Hi Ilya,
> > 
> > Currently, the errors happened during messages handling
> > aren't handled properly. E.g. in vhost_user_set_mem_table(),
> > similar issues [1] may happen too. We might want to find
> > a way to fix this once and for all.
> > 
> > [1]
> > https://github.com/DPDK/dpdk/blob/3605968c2fa7/lib/librte_vhost/vhost_user.c#L826
> > https://github.com/DPDK/dpdk/blob/3605968c2fa7/lib/librte_vhost/vhost_user.c#L837
> > https://github.com/DPDK/dpdk/blob/3605968c2fa7/lib/librte_vhost/vhost_user.c#L887
> > 
> > Thanks
> 
> Hi. I understand your position position and, actually, I looked at
> other functions while preparing this fix. There is one difference
> between vhost_user_set_mem_table() and vhost_user_set_vring_num().
> The first one is able to reply bad status.
> But yes, you're right that we should handle all the errors.
> What about following patch (compile tested only):
> 
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> index 9aa1ce118..63d145b2d 100644
> --- a/lib/librte_vhost/vhost_user.c
> +++ b/lib/librte_vhost/vhost_user.c
> @@ -1014,7 +1014,7 @@ vhost_user_set_vring_call(struct virtio_net *dev, 
> struct VhostUserMsg *pmsg)
>   vq->callfd = file.fd;
>  }
>  
> -static void
> +static int
>  vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg 
> *pmsg)
>  {
>   struct vhost_vring_file file;
> @@ -1032,7 +1032,7 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, 
> struct VhostUserMsg *pmsg)
>   /* Interpret ring addresses only when ring is started. */
>   dev = translate_ring_addresses(dev, file.index);
>   if (!dev)
> - return;
> + return -1;
>  
>   *pdev = dev;
>  
> @@ -1049,6 +1049,7 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, 
> struct VhostUserMsg *pmsg)
>   if (vq->kickfd >= 0)
>   close(vq->kickfd);
>   vq->kickfd = file.fd;
> + return 0;
>  }
>  
>  static void
> @@ -1172,14 +1173,19 @@ vhost_user_get_protocol_features(struct virtio_net 
> *dev,
>   msg->size = sizeof(msg->payload.u64);
>  }
>  
> -static void
> +static int
>  vhost_user_set_protocol_features(struct virtio_net *dev,
>uint64_t protocol_features)
>  {
> - if (protocol_features & ~VHOST_USER_PROTOCOL_FEATURES)
> - return;
> + if (protocol_features & ~VHOST_USER_PROTOCOL_FEATURES) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "(%d) received invalid protocol features.\n",
> + dev->vid);
> + return -1;
> + }
>  
>   dev->protocol_features = protocol_features;
> + return 0;
>  }
>  
>  static int
> @@ -1657,8 +1663,6 @@ vhost_user_msg_handler(int vid, int fd)
>   break;
>   case VHOST_USER_SET_FEATURES:
>   ret = vhost_user_set_features(dev, msg.payload.u64);
> - if (ret)
> - return -1;
>   break;
>  
>   case VHOST_USER_GET_PROTOCOL_FEATURES:
> @@ -1666,14 +1670,14 @@ vhost_user_msg_handler(int vid, int fd)
>   send_vhost_reply(fd, &msg);
>   break;
>   case VHOST_USER_SET_PROTOCOL_FEATURES:
> - vhost_user_set_protocol_features(dev, msg.payload.u64);
> + ret = vhost_user_set_protocol_features(dev, msg.payload.u64);
>   break;
>  
>   case VHOST_USER_SET_OWNER:
> - vhost_user_set_owner();
> + ret = vhost_user_set_owner();
>   break;
>   case VHOST_USER_RESET_OWNER:
> - vhost_user_reset_owner(dev);
> + ret = vhost_user_reset_owner(dev);
>   break;
>  
>   case VHOST_USER_SET_MEM_TABLE:
> @@ -1681,8 +1685,9 @@ vhost_user_msg_handler(int vid, int fd)
>   break;
>  
>   case VHOST_USER_SET_LOG_BASE:
> - vhost_user_set_log_base(dev, &msg);
> -
> + ret = vhost_user_set_log_base(dev, &msg);
> + if (ret)
> + goto skip_to_reply;
>   /* it needs a reply */
>   msg.size = sizeof(msg.payload.u64);
>   send_vhost_reply(fd, &msg);
> @@ -1693,23 +1698,25 @@ vhost_user_msg_handler(int vid, int fd)
>   break;
>  
>   case VHOST_USER_SET_VRING_NUM:
> - vhost_user_set_vring_num(dev, &msg);
> + ret = vhost_user_set_vring_num(dev, &msg);
>   break;
>   case VHOST_USER_SET_VRING_ADDR:
> - vhost_user_set_vring_addr(&dev, &msg);
> + ret = vhost_user_set_vring_addr(&dev, &msg);
>   break;
>   case VHOST_USER_SET_VRING_BASE:
> - vhost_user_set_vring_base(dev, &msg);
> + ret = vhost_user_set_vring_base(dev, &msg);
>   break;
>  
>

[dpdk-dev] [PATCH] doc: update for GTPv1 package release

2018-09-02 Thread Beilei Xing
Add link of GTPv1 package release.

Signed-off-by: Beilei Xing 
---
 doc/guides/nics/i40e.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 65d87f8..5d8500c 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -421,6 +421,9 @@ functionality requires a NIC firmware version of 6.0 or 
greater.
 Current implementation supports GTP-C/GTP-U/PPPoE/PPPoL2TP,
 steering can be used with rte_flow API.
 
+GTPv1 package is released, and it can be downloaded from
+https://downloadcenter.intel.com/download/27587.
+
 Load a profile which supports GTP and store backup profile:
 
 .. code-block:: console
-- 
2.5.5



Re: [dpdk-dev] [PATCH 2/2] net/failsafe: support multicast address list set

2018-09-02 Thread Andrew Rybchenko

On 08/31/2018 06:53 PM, Andrew Rybchenko wrote:

From: Evgeny Im 

Signed-off-by: Evgeny Im 
Signed-off-by: Andrew Rybchenko 


<...>



diff --git a/drivers/net/failsafe/failsafe_ops.c 
b/drivers/net/failsafe/failsafe_ops.c
index 24e91c931..2583cff58 100644
--- a/drivers/net/failsafe/failsafe_ops.c
+++ b/drivers/net/failsafe/failsafe_ops.c
@@ -952,6 +952,53 @@ fs_mac_addr_set(struct rte_eth_dev *dev, struct ether_addr 
*mac_addr)
return 0;
  }
  
+static int

+fs_set_mc_addr_list(struct rte_eth_dev *dev,
+   struct ether_addr *mc_addr_set, uint32_t nb_mc_addr)
+{
+   struct sub_device *sdev;
+   uint8_t i;
+   int ret;
+
+   fs_lock(dev, 0);
+   FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
+   ret = rte_eth_dev_set_mc_addr_list(PORT_ID(sdev),
+  mc_addr_set, nb_mc_addr);
+   if (ret != 0) {
+   ERROR("Operation rte_eth_dev_set_mc_addr_list failed for 
sub_device %d with error %d",
+ i, ret);
+   goto rollback;
+   }
+   }
+   /* Do not reallocate/save if the method is called from sync */
+   if (mc_addr_set != PRIV(dev)->mcast_addrs) {
+   void *mcast_addrs = rte_realloc(PRIV(dev)->mcast_addrs,
+   nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]), 0);
+   if (mcast_addrs == NULL) {
+   ret = -ENOMEM;


Self-NACK since it fails for empty list set since rte_realloc() returns 
NULL.

Will fix in v2.


+   goto rollback;
+   }
+   PRIV(dev)->mcast_addrs = mcast_addrs;
+   rte_memcpy(PRIV(dev)->mcast_addrs, mc_addr_set,
+  nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]));
+   }
+   PRIV(dev)->nb_mcast_addr = nb_mc_addr;
+   fs_unlock(dev, 0);
+   return 0;
+
+rollback:
+   FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
+   int rc = rte_eth_dev_set_mc_addr_list(PORT_ID(sdev),
+   PRIV(dev)->mcast_addrs,  PRIV(dev)->nb_mcast_addr);
+   if (rc != 0) {
+   ERROR("Multicast MAC address list rollback for sub_device %d 
failed with error %d",
+ i, rc);
+   }
+   }
+   fs_unlock(dev, 0);
+   return ret;
+}
+
  static int
  fs_rss_hash_update(struct rte_eth_dev *dev,
struct rte_eth_rss_conf *rss_conf)


<...>


[dpdk-dev] [PATCH v2 1/2] net/failsafe: remove not supported multicast MAC filter

2018-09-02 Thread Andrew Rybchenko
From: Evgeny Im 

set_mc_addr_list method is not implemented by the driver yet.

Fixes: a46f8d584eb8 ("net/failsafe: add fail-safe PMD")
Cc: sta...@dpdk.org

Signed-off-by: Evgeny Im 
Signed-off-by: Andrew Rybchenko 
---
 doc/guides/nics/features/failsafe.ini | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/guides/nics/features/failsafe.ini 
b/doc/guides/nics/features/failsafe.ini
index 39ee57965..83cc99d19 100644
--- a/doc/guides/nics/features/failsafe.ini
+++ b/doc/guides/nics/features/failsafe.ini
@@ -12,7 +12,6 @@ Jumbo frame  = Y
 Promiscuous mode = Y
 Allmulticast mode= Y
 Unicast MAC filter   = Y
-Multicast MAC filter = Y
 VLAN filter  = Y
 Flow control = Y
 Flow API = Y
-- 
2.17.1



[dpdk-dev] [PATCH v2 0/2] net/failsafe: support multicast MAC address set

2018-09-02 Thread Andrew Rybchenko
Evgeny Im (2):
  net/failsafe: remove not supported multicast MAC filter
  net/failsafe: support multicast address list set

 doc/guides/rel_notes/release_18_11.rst  |  6 
 drivers/net/failsafe/failsafe.c |  1 +
 drivers/net/failsafe/failsafe_ether.c   | 17 +
 drivers/net/failsafe/failsafe_ops.c | 48 +
 drivers/net/failsafe/failsafe_private.h |  2 ++
 5 files changed, 74 insertions(+)

-- 
2.17.1



[dpdk-dev] [PATCH v2 2/2] net/failsafe: support multicast address list set

2018-09-02 Thread Andrew Rybchenko
From: Evgeny Im 

Signed-off-by: Evgeny Im 
Signed-off-by: Andrew Rybchenko 
---
 doc/guides/nics/features/failsafe.ini   |  1 +
 doc/guides/rel_notes/release_18_11.rst  |  6 
 drivers/net/failsafe/failsafe.c |  1 +
 drivers/net/failsafe/failsafe_ether.c   | 17 +
 drivers/net/failsafe/failsafe_ops.c | 48 +
 drivers/net/failsafe/failsafe_private.h |  2 ++
 6 files changed, 75 insertions(+)

diff --git a/doc/guides/nics/features/failsafe.ini 
b/doc/guides/nics/features/failsafe.ini
index 83cc99d19..39ee57965 100644
--- a/doc/guides/nics/features/failsafe.ini
+++ b/doc/guides/nics/features/failsafe.ini
@@ -12,6 +12,7 @@ Jumbo frame  = Y
 Promiscuous mode = Y
 Allmulticast mode= Y
 Unicast MAC filter   = Y
+Multicast MAC filter = Y
 VLAN filter  = Y
 Flow control = Y
 Flow API = Y
diff --git a/doc/guides/rel_notes/release_18_11.rst 
b/doc/guides/rel_notes/release_18_11.rst
index 24204e67b..54e0e4ee4 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -54,6 +54,12 @@ New Features
  Also, make sure to start the actual text at the margin.
  =
 
+* **Updated failsafe driver.**
+
+  Updated the failsafe driver including the following changes:
+
+  * Support multicast MAC address set.
+
 
 API Changes
 ---
diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c
index 657919f93..c3999f026 100644
--- a/drivers/net/failsafe/failsafe.c
+++ b/drivers/net/failsafe/failsafe.c
@@ -304,6 +304,7 @@ fs_rte_eth_free(const char *name)
ret = pthread_mutex_destroy(&PRIV(dev)->hotplug_mutex);
if (ret)
ERROR("Error while destroying hotplug mutex");
+   rte_free(PRIV(dev)->mcast_addrs);
rte_free(PRIV(dev));
rte_eth_dev_release_port(dev);
return ret;
diff --git a/drivers/net/failsafe/failsafe_ether.c 
b/drivers/net/failsafe/failsafe_ether.c
index 5b5cb3b49..5078feabe 100644
--- a/drivers/net/failsafe/failsafe_ether.c
+++ b/drivers/net/failsafe/failsafe_ether.c
@@ -424,6 +424,23 @@ failsafe_eth_dev_state_sync(struct rte_eth_dev *dev)
ret = dev->dev_ops->dev_start(dev);
if (ret)
goto err_remove;
+   /*
+* Propagate multicast MAC addresses to sub-devices,
+* if non zero number of addresses is set.
+* The condition is required to avoid breakage of failsafe
+* for sub-devices which do not support the operation
+* if the feature is really not used.
+*/
+   if (PRIV(dev)->nb_mcast_addr > 0) {
+   ret = dev->dev_ops->set_mc_addr_list(dev,
+PRIV(dev)->mcast_addrs,
+PRIV(dev)->nb_mcast_addr);
+   if (ret) {
+   ERROR("Could not set list of multicast addresses to 
sub_device %d",
+ i);
+   goto err_remove;
+   }
+   }
return 0;
 err_remove:
FOREACH_SUBDEV(sdev, i, dev)
diff --git a/drivers/net/failsafe/failsafe_ops.c 
b/drivers/net/failsafe/failsafe_ops.c
index 24e91c931..082685bb1 100644
--- a/drivers/net/failsafe/failsafe_ops.c
+++ b/drivers/net/failsafe/failsafe_ops.c
@@ -952,6 +952,53 @@ fs_mac_addr_set(struct rte_eth_dev *dev, struct ether_addr 
*mac_addr)
return 0;
 }
 
+static int
+fs_set_mc_addr_list(struct rte_eth_dev *dev,
+   struct ether_addr *mc_addr_set, uint32_t nb_mc_addr)
+{
+   struct sub_device *sdev;
+   uint8_t i;
+   int ret;
+
+   fs_lock(dev, 0);
+   FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
+   ret = rte_eth_dev_set_mc_addr_list(PORT_ID(sdev),
+  mc_addr_set, nb_mc_addr);
+   if (ret != 0) {
+   ERROR("Operation rte_eth_dev_set_mc_addr_list failed 
for sub_device %d with error %d",
+ i, ret);
+   goto rollback;
+   }
+   }
+   /* Do not reallocate/save if the method is called from sync */
+   if (mc_addr_set != PRIV(dev)->mcast_addrs) {
+   void *mcast_addrs = rte_realloc(PRIV(dev)->mcast_addrs,
+   nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]), 0);
+   if (mcast_addrs == NULL && nb_mc_addr > 0) {
+   ret = -ENOMEM;
+   goto rollback;
+   }
+   PRIV(dev)->mcast_addrs = mcast_addrs;
+   rte_memcpy(PRIV(dev)->mcast_addrs, mc_addr_set,
+  nb_mc_addr * sizeof(PRIV(dev)->mcast_addrs[0]));
+   }
+   PRIV(dev)->nb_mcast_addr = nb_mc_addr;
+   fs_unlock(dev, 0);
+   return 0;
+
+rollback:
+   FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
+