Re: [dpdk-dev] [PATCH] mbuf: remove deprecated segment free functions
Hi Thomas, On Sun, Sep 16, 2018 at 11:39:29AM +0200, Thomas Monjalon wrote: > 10/09/2018 10:06, Andrew Rybchenko: > > On 09/10/2018 08:18 AM, David Marchand wrote: > > > __rte_mbuf_raw_free and __rte_pktmbuf_prefree_seg have been deprecated for > > > a long time now (early 17.05), are not part of the abi and are easily > > > replaced with existing api. > > > > > > Signed-off-by: David Marchand > > > > Acked-by: Andrew Rybchenko > > I think we need to bump the library version and update the API section > in the release notes. I don't think bumping the lib version is required here, the patch removes two functions that are static inline. But updating the API section would be nice, yes. Thanks, Olivier
Re: [dpdk-dev] [PATCH v5] net/i40e: add interface to choose latest vector path
Will send new version later. Thanks.
> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, September 13, 2018 21:27
> To: Li, Xiaoyun ; Xing, Beilei ;
> Zhang, Qi Z
> Cc: dev@dpdk.org; Yang, Zhiyong
> Subject: Re: [dpdk-dev] [PATCH v5] net/i40e: add interface to choose latest
> vector path
>
> On 9/12/2018 11:12 AM, Xiaoyun Li wrote:
> > Right now, vector path is limited to only use on later platform.
>
> i40e supports vector instructions for intel, arm and powerpc, this behavior is
> only for Intel vector drivers, can be good to clarify, also it can better to
> explain a little more what "limited to only use on later platform" means.
OK. Will update the commit log.
>
> > This patch adds a devarg use-latest-vec to allow the users to use the
> > latest vector path that the platform supported. Namely, using AVX2
> > vector path on broadwell is possible.
>
> Again, this is for intel only, and can you put a matrix to clarify what is
> supported:
>
> no devarg:
> Machine PMD
> avx512avx2
> avx2 sse4.2
> sse4.2sse4.2
> < sse4.2 not supported
>
> with devarg:
> Machine PMD
> avx512avx2
> avx2 avx2
> sse4.2sse4.2
> < sse4.2 not supported
OK.
>
>
> And I am not sure about name of the devarg "use-latest-vec", I can see it has
> been discussed already.
> What about "use-latest-supported-vec"? Too verbose?
> Do you have any other suggestion?
OK. Will take that name.
>
> <...>
>
> > @@ -163,6 +163,14 @@ Runtime Config Options
> >Currently hot-plugging of representor ports is not supported so all
> required
> >representors must be specified on the creation of the PF.
> >
> > +- ``Use latest vector`` (default ``disable``)
> > +
> > + Vector path was limited to use only on later platform. But users
> > + may want the latest vector path. For example, VPP users may want to
> > + use AVX2 vector path on HSW/BDW because it can get better perf. So
> > + ``devargs`` parameter ``use-latest-vec`` is introduced, for example::
> > +-w 84:00.0,use-latest-vec=1
>
> Do we need to name a specific consumer of DPDK on i40e document? Why
> not say any application?
OK. Will generalize it to users not VPP users.
>
> > +
> > Driver compilation and testing
> > --
> >
> > diff --git a/doc/guides/rel_notes/release_18_11.rst
> > b/doc/guides/rel_notes/release_18_11.rst
> > index 3ae6b3f58..34af591a2 100644
> > --- a/doc/guides/rel_notes/release_18_11.rst
> > +++ b/doc/guides/rel_notes/release_18_11.rst
> > @@ -54,6 +54,10 @@ New Features
> > Also, make sure to start the actual text at the margin.
> > =
> >
> > +* **Added a devarg to use the latest vector path.**
> > + A new devarg ``use-latest-vec`` was introduced to allow users to
> > +choose
> > + the latest vector path that the platform supported. For example,
> > +VPP users
> > + can use AVX2 vector path on BDW/HSW to get better performance.
>
> Same, do we need to name a specific consumer of DPDK on release notes?
>
> <...>
>
> > @@ -1201,6 +1203,46 @@ i40e_aq_debug_write_global_register(struct
> i40e_hw *hw,
> > return i40e_aq_debug_write_register(hw, reg_addr, reg_val,
> > cmd_details); }
> >
> > +static int
> > +i40e_parse_latest_vec(struct rte_eth_dev *dev) {
> > + struct i40e_adapter *ad =
> > + I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> > + int kvargs_count, use_latest_vec;
> > + struct rte_kvargs *kvlist;
> > +
> > + ad->use_latest_vec = false;
> > +
> > + if (!dev->device->devargs)
> > + return 0;
> > +
> > + kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
> > + if (!kvlist)
> > + return -EINVAL;
>
> Agree with Qi to prevent rte_kvargs_parse() call for each devarg, in the
> future.
OK. I am preparing patch about that.
>
> > +
> > + kvargs_count = rte_kvargs_count(kvlist, ETH_I40E_USE_LATEST_VEC);
> > + if (!kvargs_count) {
> > + rte_kvargs_free(kvlist);
> > + return 0;
> > + }
> > +
> > + if (kvargs_count > 1)
> > + PMD_DRV_LOG(WARNING, "More than one argument \"%s\"
> and only "
> > + "the first one is used !",
> > + ETH_I40E_USE_LATEST_VEC);
> > +
> > + use_latest_vec = atoi((&kvlist->pairs[0])->value);
>
> Instead of accessing directly kvlist internals, please use
> rte_kvargs_process()
OK.
>
> <...>
>
> > @@ -12527,4 +12570,5 @@
> RTE_PMD_REGISTER_PARAM_STRING(net_i40e,
> > ETH_I40E_FLOATING_VEB_ARG "=1"
> > ETH_I40E_FLOATING_VEB_LIST_ARG "="
> > ETH_I40E_QUEUE_NUM_PER_VF_ARG
> "=1|2|4|8|16"
> > - ETH_I40E_SUPPORT_MULTI_DRIVER "=1");
> > + ETH_I40E_SUPPORT_MULTI_DRIVER "=1"
> > + ETH_I40E_USE_LA
Re: [dpdk-dev] [PATCH] net/e1000: correct queue number in RSS configuration
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhao1, Wei
> Sent: Friday, September 14, 2018 2:50 PM
> To: Xing, Beilei ; Lu, Wenzhuo
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/e1000: correct queue number in RSS
> configuration
>
> > -Original Message-
> > From: Xing, Beilei
> > Sent: Thursday, September 13, 2018 3:06 PM
> > To: Zhao1, Wei ; Lu, Wenzhuo
> >
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: [PATCH] net/e1000: correct queue number in RSS configuration
> >
> > RSS configuration works for all e1000 NICs except 82576.
> > This patch fixes this issue by correcting queue number in RSS configuration.
> >
> > Fixes: 424ae915baf0 ("net/e1000: move RSS to flow API")
> > Fixes: ac8d22de2394 ("ethdev: flatten RSS configuration in flow API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Beilei Xing
> Acked-by: Wei Zhao
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH] net/avf: remove unused variables and label
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Luca Boccassi > Sent: Friday, September 14, 2018 12:26 AM > To: Richardson, Bruce ; Wu, Jingjing > ; Lu, Wenzhuo > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/avf: remove unused variables and label > > On Thu, 2018-09-13 at 15:44 +0100, Bruce Richardson wrote: > > Compiling with all warnings turned on causes errors about unused > > variables and an unused label. Remove these to allow building without > > having to disable those warnings. > > > > Signed-off-by: Bruce Richardson > > --- > > drivers/net/avf/avf_ethdev.c | 15 +-- > > drivers/net/avf/avf_rxtx.c | 17 + > > drivers/net/avf/avf_vchnl.c | 2 -- > > 3 files changed, 6 insertions(+), 28 deletions(-) > > Acked-by: Luca Boccassi > > -- > Kind regards, > Luca Boccassi Applied to dpdk-next-net-intel. Thanks Qi
[dpdk-dev] [PATCH] config: remove unused macro
RTE_LIBRTE_I40E_ITR_INTERVAL is not used. So it should also be removed
in config/rte_config.h for meson+ninjia build.
Fixes: 864a800d706d ("net/i40e: remove VF interrupt handler")
Cc: sta...@dpdk.org
Signed-off-by: Qi Zhang
---
config/rte_config.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/config/rte_config.h b/config/rte_config.h
index a8e479774..f03c526ba 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -106,8 +106,6 @@
#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF 64
#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM 4
-/* interval up to 8160 us, aligned to 2 (or default value) */
-#define RTE_LIBRTE_I40E_ITR_INTERVAL -1
/* Ring net PMD settings */
#define RTE_PMD_RING_MAX_RX_RINGS 16
--
2.13.6
[dpdk-dev] [PATCH] vmxnet3: stats_reset implementation
'stats_reset()' callback was missing.
This commit implements the callback by taking a snapshot of the stats
(SNAPSHOT) each time 'stats_reset()' is called.
When getting stats with 'stats_get()', hw stats which always increase reduce
SNAPSHOT stats. That's how we get the "real" stats since the last
'stats_reset()'.
Signed-off-by: yogev ch
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 78 ++--
drivers/net/vmxnet3/vmxnet3_ethdev.h | 3 ++
2 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 2613cd1..2348300 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -78,6 +78,7 @@ static int vmxnet3_dev_link_update(struct rte_eth_dev *dev,
static void vmxnet3_hw_stats_save(struct vmxnet3_hw *hw);
static int vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
+static void vmxnet3_dev_stats_reset(struct rte_eth_dev *dev);
static int vmxnet3_dev_xstats_get_names(struct rte_eth_dev *dev,
struct rte_eth_xstat_name *xstats,
unsigned int n);
@@ -120,6 +121,7 @@ static int vmxnet3_mac_addr_set(struct rte_eth_dev *dev,
.stats_get= vmxnet3_dev_stats_get,
.xstats_get_names = vmxnet3_dev_xstats_get_names,
.xstats_get = vmxnet3_dev_xstats_get,
+ .stats_reset = vmxnet3_dev_stats_reset,
.mac_addr_set = vmxnet3_mac_addr_set,
.dev_infos_get= vmxnet3_dev_info_get,
.dev_supported_ptypes_get = vmxnet3_dev_supported_ptypes_get,
@@ -335,6 +337,10 @@ struct vmxnet3_xstats_name_off {
memset(hw->saved_tx_stats, 0, sizeof(hw->saved_tx_stats));
memset(hw->saved_rx_stats, 0, sizeof(hw->saved_rx_stats));
+ /* clear snapshot stats */
+ memset(hw->snapshot_tx_stats, 0, sizeof(hw->snapshot_tx_stats));
+ memset(hw->snapshot_rx_stats, 0, sizeof(hw->snapshot_rx_stats));
+
/* set the initial link status */
memset(&link, 0, sizeof(link));
link.link_duplex = ETH_LINK_FULL_DUPLEX;
@@ -890,7 +896,49 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device
*pci_dev)
VMXNET3_UPDATE_RX_STAT(hw, q, pktsRxError, res);
VMXNET3_UPDATE_RX_STAT(hw, q, pktsRxOutOfBuf, res);
-#undef VMXNET3_UPDATE_RX_STATS
+#undef VMXNET3_UPDATE_RX_STAT
+}
+
+static void
+vmxnet3_tx_stats_get(struct vmxnet3_hw *hw, unsigned int q,
+ struct UPT1_TxStats *res)
+{
+ vmxnet3_hw_tx_stats_get(hw, q, res);
+
+#define VMXNET3_REDUCE_SNAPSHOT_TX_STAT(h, i, f, r)\
+ ((r)->f -= (h)->snapshot_tx_stats[(i)].f)
+
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, ucastPktsTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, mcastPktsTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, bcastPktsTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, ucastBytesTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, mcastBytesTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, bcastBytesTxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, pktsTxError, res);
+ VMXNET3_REDUCE_SNAPSHOT_TX_STAT(hw, q, pktsTxDiscard, res);
+
+#undef VMXNET3_REDUCE_SNAPSHOT_TX_STAT
+}
+
+static void
+vmxnet3_rx_stats_get(struct vmxnet3_hw *hw, unsigned int q,
+ struct UPT1_RxStats *res)
+{
+ vmxnet3_hw_rx_stats_get(hw, q, res);
+
+#define VMXNET3_REDUCE_SNAPSHOT_RX_STAT(h, i, f, r)\
+ ((r)->f -= (h)->snapshot_rx_stats[(i)].f)
+
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, ucastPktsRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, mcastPktsRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, bcastPktsRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, ucastBytesRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, mcastBytesRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, bcastBytesRxOK, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, pktsRxError, res);
+ VMXNET3_REDUCE_SNAPSHOT_RX_STAT(hw, q, pktsRxOutOfBuf, res);
+
+#undef VMXNET3_REDUCE_SNAPSHOT_RX_STAT
}
static void
@@ -1005,7 +1053,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device
*pci_dev)
RTE_BUILD_BUG_ON(RTE_ETHDEV_QUEUE_STAT_CNTRS < VMXNET3_MAX_TX_QUEUES);
for (i = 0; i < hw->num_tx_queues; i++) {
- vmxnet3_hw_tx_stats_get(hw, i, &txStats);
+ vmxnet3_tx_stats_get(hw, i, &txStats);
stats->q_opackets[i] = txStats.ucastPktsTxOK +
txStats.mcastPktsTxOK +
@@ -1022,7 +1070,7 @@ static int eth_vmxnet3_pci_remove(struct rte_pci_device
*pci_dev)
RTE_BUILD_BUG_ON(RTE_ETHDEV_QUEUE_STAT_CNTRS < VMXNET3_MAX_RX_QUEUES);
for (i = 0; i < hw->num_rx_
[dpdk-dev] [PATCH v3 1/3] app/testpmd: show errno along with flow API errors
From: Adrien Mazarguil
Signed-off-by: Adrien Mazarguil
Reviewed-by: Ferruh Yigit
---
app/test-pmd/config.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 92686a05f..a0f934932 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1346,11 +1346,12 @@ port_flow_complain(struct rte_flow_error *error)
errstr = "unknown type";
else
errstr = errstrlist[error->type];
- printf("Caught error type %d (%s): %s%s\n",
+ printf("Caught error type %d (%s): %s%s: %s\n",
error->type, errstr,
error->cause ? (snprintf(buf, sizeof(buf), "cause: %p, ",
error->cause), buf) : "",
- error->message ? error->message : "(no stated reason)");
+ error->message ? error->message : "(no stated reason)",
+ rte_strerror(err));
return -err;
}
--
2.11.0
[dpdk-dev] [PATCH v3 2/3] net/i40e: remove invalid comment
From: Ferruh Yigit Comments says "no csum error report support" but there is no check related csum offloads. Removing the comment. Signed-off-by: Ferruh Yigit Acked-by: Qi Zhang --- drivers/net/i40e/i40e_rxtx_vec_common.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/i40e/i40e_rxtx_vec_common.h b/drivers/net/i40e/i40e_rxtx_vec_common.h index 63cb17742..f00f6d648 100644 --- a/drivers/net/i40e/i40e_rxtx_vec_common.h +++ b/drivers/net/i40e/i40e_rxtx_vec_common.h @@ -199,9 +199,7 @@ i40e_rx_vec_dev_conf_condition_check_default(struct rte_eth_dev *dev) if (fconf->mode != RTE_FDIR_MODE_NONE) return -1; -/* - no csum error report support -* - no header split support -*/ +/* no header split support */ if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT) return -1; -- 2.11.0
[dpdk-dev] [PATCH v3 3/3] doc: add cross compile part for sample applications
Fixes: 7cacb05655 ("doc: add generic build instructions for sample apps")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
---
doc/guides/sample_app_ug/compiling.rst | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/compiling.rst
b/doc/guides/sample_app_ug/compiling.rst
index a2d75ed22..6f04743c8 100644
--- a/doc/guides/sample_app_ug/compiling.rst
+++ b/doc/guides/sample_app_ug/compiling.rst
@@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
applications.
To compile all the sample applications
--
-
Set the path to DPDK source code if its not set:
.. code-block:: console
@@ -93,3 +92,17 @@ Build the application:
export RTE_TARGET=build
make
+
+To cross compile the sample application(s)
+--
+
+For cross compiling the sample application(s), please append
'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
+In example of AARCH64 cross compiling:
+
+.. code-block:: console
+
+export RTE_TARGET=build
+export RTE_SDK=/path/to/rte_sdk
+make -C examples CROSS=aarch64-linux-gnu-
+ or
+make CROSS=aarch64-linux-gnu-
--
2.11.0
Re: [dpdk-dev] [PATCH] crypto/qat: fix typo
Hi, 10/08/2018 17:20, Trahe, Fiona: > > -/**< Intel(R) QAT Symmetric Crypto PMD device name */ > > +/**< Intel(R) QAT Symmetric Crypto PMD driver name */ > > #define CRYPTODEV_NAME_QAT_SYM_PMD crypto_qat The comment is above, so the syntax should be /**, not /**< Do you want me to fix it when pulling in master?
[dpdk-dev] [PATCH v4 1/4] bus/fslmc: fix undefined reference of memsegs
From: Hemant Agrawal
This patch fix the undefined reference issue with rte_dpaa2_memsegs
when compiled in shared lib mode with EXTRA_CFLAGS="-g -O0"
Bugzilla ID: 61
Fixes: 365fb925d3b3 ("bus/fslmc: optimize physical to virtual address search")
Cc: sta...@dpdk.org
Reported-by: Keith Wiles
Signed-off-by: Hemant Agrawal
Acked-by: Shreyansh Jain
---
drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c| 7 +++
drivers/bus/fslmc/rte_bus_fslmc_version.map | 1 +
drivers/mempool/dpaa2/dpaa2_hw_mempool.c| 7 ---
drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map | 1 -
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
index 39c5adf..db49d63 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpbp.c
@@ -28,6 +28,13 @@
#include "portal/dpaa2_hw_pvt.h"
#include "portal/dpaa2_hw_dpio.h"
+/* List of all the memseg information locally maintained in dpaa2 driver. This
+ * is to optimize the PA_to_VA searches until a better mechanism (algo) is
+ * available.
+ */
+struct dpaa2_memseg_list rte_dpaa2_memsegs
+ = TAILQ_HEAD_INITIALIZER(rte_dpaa2_memsegs);
+
TAILQ_HEAD(dpbp_dev_list, dpaa2_dpbp_dev);
static struct dpbp_dev_list dpbp_dev_list
= TAILQ_HEAD_INITIALIZER(dpbp_dev_list); /*!< DPBP device list */
diff --git a/drivers/bus/fslmc/rte_bus_fslmc_version.map
b/drivers/bus/fslmc/rte_bus_fslmc_version.map
index fe45a11..b4a8817 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;
rte_dpaa2_free_dpci_dev;
+ rte_dpaa2_memsegs;
} DPDK_18.02;
diff --git a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
index 7d0435f..84ff128 100644
--- a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
+++ b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
@@ -33,13 +33,6 @@
struct dpaa2_bp_info rte_dpaa2_bpid_info[MAX_BPID];
static struct dpaa2_bp_list *h_bp_list;
-/* List of all the memseg information locally maintained in dpaa2 driver. This
- * is to optimize the PA_to_VA searches until a better mechanism (algo) is
- * available.
- */
-struct dpaa2_memseg_list rte_dpaa2_memsegs
- = TAILQ_HEAD_INITIALIZER(rte_dpaa2_memsegs);
-
/* Dynamic logging identified for mempool */
int dpaa2_logtype_mempool;
diff --git a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
index b9d996a..b45e7a9 100644
--- a/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
+++ b/drivers/mempool/dpaa2/rte_mempool_dpaa2_version.map
@@ -3,7 +3,6 @@ DPDK_17.05 {
rte_dpaa2_bpid_info;
rte_dpaa2_mbuf_alloc_bulk;
- rte_dpaa2_memsegs;
local: *;
};
--
2.7.4
[dpdk-dev] [PATCH v4 2/4] ring: read tail using atomic load
In update_tail, read ht->tail using __atomic_load.Although the
compiler currently seems to be doing the right thing even without
_atomic_load, we don't want to give the compiler freedom to optimise
what should be an atomic load, it should not be arbitarily moved
around.
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 94df3c4..234fea0 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -21,7 +21,8 @@ update_tail(struct rte_ring_headtail *ht, uint32_t old_val,
uint32_t new_val,
* we need to wait for them to complete
*/
if (!single)
- while (unlikely(ht->tail != old_val))
+ while (unlikely(old_val != __atomic_load_n(&ht->tail,
+ __ATOMIC_RELAXED)))
rte_pause();
__atomic_store_n(&ht->tail, new_val, __ATOMIC_RELEASE);
--
2.7.4
[dpdk-dev] [PATCH v4 3/4] ring: synchronize the load and store of the tail
Synchronize the load-acquire of the tail and the store-release
within update_tail, the store release ensures all the ring operations,
enqueue or dequeue, are seen by the observers on the other side as soon
as they see the updated tail. The load-acquire is needed here as the
data dependency is not a reliable way for ordering as the compiler might
break it by saving to temporary values to boost performance.
When computing the free_entries and avail_entries, use atomic semantics
to load the heads and tails instead.
The patch was benchmarked with test/ring_perf_autotest and it decreases
the enqueue/dequeue latency by 5% ~ 27.6% with two lcores, the real gains
are dependent on the number of lcores, depth of the ring, SPSC or MPMC.
For 1 lcore, it also improves a little, about 3 ~ 4%.
It is a big improvement, in case of MPMC, with two lcores and ring size
of 32, it saves latency up to (3.26-2.36)/3.26 = 27.6%.
This patch is a bug fix, while the improvement is a bonus. In our analysis
the improvement comes from the cacheline pre-filling after hoisting load-
acquire from _atomic_compare_exchange_n up above.
The test command:
$sudo ./test/test/test -l 16-19,44-47,72-75,100-103 -n 4 --socket-mem=\
1024 -- -i
Test result with this patch(two cores):
SP/SC bulk enq/dequeue (size: 8): 5.86
MP/MC bulk enq/dequeue (size: 8): 10.15
SP/SC bulk enq/dequeue (size: 32): 1.94
MP/MC bulk enq/dequeue (size: 32): 2.36
In comparison of the test result without this patch:
SP/SC bulk enq/dequeue (size: 8): 6.67
MP/MC bulk enq/dequeue (size: 8): 13.12
SP/SC bulk enq/dequeue (size: 32): 2.04
MP/MC bulk enq/dequeue (size: 32): 3.26
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 234fea0..0eae3b3 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -68,13 +68,18 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
*old_head = __atomic_load_n(&r->prod.head,
__ATOMIC_ACQUIRE);
- /*
-* The subtraction is done between two unsigned 32bits value
+ /* load-acquire synchronize with store-release of ht->tail
+* in update_tail.
+*/
+ const uint32_t cons_tail = __atomic_load_n(&r->cons.tail,
+ __ATOMIC_ACQUIRE);
+
+ /* The subtraction is done between two unsigned 32bits value
* (the result is always modulo 32 bits even if we have
* *old_head > cons_tail). So 'free_entries' is always between 0
* and capacity (which is < size).
*/
- *free_entries = (capacity + r->cons.tail - *old_head);
+ *free_entries = (capacity + cons_tail - *old_head);
/* check that we have enough room in ring */
if (unlikely(n > *free_entries))
@@ -132,15 +137,22 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
do {
/* Restore n as it may change every loop */
n = max;
+
*old_head = __atomic_load_n(&r->cons.head,
__ATOMIC_ACQUIRE);
+ /* this load-acquire synchronize with store-release of ht->tail
+* in update_tail.
+*/
+ const uint32_t prod_tail = __atomic_load_n(&r->prod.tail,
+ __ATOMIC_ACQUIRE);
+
/* The subtraction is done between two unsigned 32bits value
* (the result is always modulo 32 bits even if we have
* cons_head > prod_tail). So 'entries' is always between 0
* and size(ring)-1.
*/
- *entries = (r->prod.tail - *old_head);
+ *entries = (prod_tail - *old_head);
/* Set the actual entries for dequeue */
if (n > *entries)
--
2.7.4
[dpdk-dev] [PATCH v4 4/4] ring: move the atomic load of head above the loop
In __rte_ring_move_prod_head, move the __atomic_load_n up and out of
the do {} while loop as upon failure the old_head will be updated,
another load is costly and not necessary.
This helps a little on the latency,about 1~5%.
Test result with the patch(two cores):
SP/SC bulk enq/dequeue (size: 8): 5.64
MP/MC bulk enq/dequeue (size: 8): 9.58
SP/SC bulk enq/dequeue (size: 32): 1.98
MP/MC bulk enq/dequeue (size: 32): 2.30
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 0eae3b3..95cc508 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -61,13 +61,11 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
unsigned int max = n;
int success;
+ *old_head = __atomic_load_n(&r->prod.head, __ATOMIC_ACQUIRE);
do {
/* Reset n to the initial burst count */
n = max;
- *old_head = __atomic_load_n(&r->prod.head,
- __ATOMIC_ACQUIRE);
-
/* load-acquire synchronize with store-release of ht->tail
* in update_tail.
*/
@@ -93,6 +91,7 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
if (is_sp)
r->prod.head = *new_head, success = 1;
else
+ /* on failure, *old_head is updated */
success = __atomic_compare_exchange_n(&r->prod.head,
old_head, *new_head,
0, __ATOMIC_ACQUIRE,
@@ -134,13 +133,11 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
int success;
/* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons.head, __ATOMIC_ACQUIRE);
do {
/* Restore n as it may change every loop */
n = max;
- *old_head = __atomic_load_n(&r->cons.head,
- __ATOMIC_ACQUIRE);
-
/* this load-acquire synchronize with store-release of ht->tail
* in update_tail.
*/
@@ -165,6 +162,7 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
if (is_sc)
r->cons.head = *new_head, success = 1;
else
+ /* on failure, *old_head will be updated */
success = __atomic_compare_exchange_n(&r->cons.head,
old_head, *new_head,
0, __ATOMIC_ACQUIRE,
--
2.7.4
Re: [dpdk-dev] [PATCH] compat: fix symbol version support with meson
On Sun, Sep 16, 2018 at 11:14:10AM +0200, Thomas Monjalon wrote:
> 30/08/2018 19:31, Luca Boccassi:
> > On Thu, 2018-08-30 at 18:07 +0100, Bruce Richardson wrote:
> > > For meson builds, the define to enable the symbol version
> > > macros in rte_compat.h was missing. This led to symbols being
> > > omitted from shared objects. For example, checking rte_distributor.so
> > > with objdump and comparing make and meson built versions:
> > >
> > > $ objdump -T make-build/lib/librte_distributor.so | grep _flush
> > > 1b60 gDF .text 00a7
> > > (DPDK_2.0) rte_distributor_flush
> > > 3f10 gDF .text 0434 DPDK_17.05
> > > rte_distributor_flush
> > > $ objdump -T meson-build/lib/librte_distributor.so | grep _flush
> > > 1d50 gDF .text 00fb DPDK_2.0
> > > rte_distributor_flush
> > >
> > > Adding in the missing define fixes this.
> > >
> > > Fixes: 5b9656b157d3 ("lib: build with meson")
> > >
> > > Reported-by: Luca Boccassi
> > > Signed-off-by: Bruce Richardson
> >
> > Tested-by: Luca Boccassi
>
> Cc stable?
>
Yes, will add on a V2.
[dpdk-dev] [PATCH v3 1/3] ring: read tail using atomic load
In update_tail, read ht->tail using __atomic_load.Although the
compiler currently seems to be doing the right thing even without
_atomic_load, we don't want to give the compiler freedom to optimise
what should be an atomic load, it should not be arbitarily moved
around.
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 94df3c4..234fea0 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -21,7 +21,8 @@ update_tail(struct rte_ring_headtail *ht, uint32_t old_val,
uint32_t new_val,
* we need to wait for them to complete
*/
if (!single)
- while (unlikely(ht->tail != old_val))
+ while (unlikely(old_val != __atomic_load_n(&ht->tail,
+ __ATOMIC_RELAXED)))
rte_pause();
__atomic_store_n(&ht->tail, new_val, __ATOMIC_RELEASE);
--
2.7.4
[dpdk-dev] [PATCH v3 3/3] ring: move the atomic load of head above the loop
In __rte_ring_move_prod_head, move the __atomic_load_n up and out of
the do {} while loop as upon failure the old_head will be updated,
another load is costly and not necessary.
This helps a little on the latency,about 1~5%.
Test result with the patch(two cores):
SP/SC bulk enq/dequeue (size: 8): 5.64
MP/MC bulk enq/dequeue (size: 8): 9.58
SP/SC bulk enq/dequeue (size: 32): 1.98
MP/MC bulk enq/dequeue (size: 32): 2.30
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 0eae3b3..95cc508 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -61,13 +61,11 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
unsigned int max = n;
int success;
+ *old_head = __atomic_load_n(&r->prod.head, __ATOMIC_ACQUIRE);
do {
/* Reset n to the initial burst count */
n = max;
- *old_head = __atomic_load_n(&r->prod.head,
- __ATOMIC_ACQUIRE);
-
/* load-acquire synchronize with store-release of ht->tail
* in update_tail.
*/
@@ -93,6 +91,7 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
if (is_sp)
r->prod.head = *new_head, success = 1;
else
+ /* on failure, *old_head is updated */
success = __atomic_compare_exchange_n(&r->prod.head,
old_head, *new_head,
0, __ATOMIC_ACQUIRE,
@@ -134,13 +133,11 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
int success;
/* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons.head, __ATOMIC_ACQUIRE);
do {
/* Restore n as it may change every loop */
n = max;
- *old_head = __atomic_load_n(&r->cons.head,
- __ATOMIC_ACQUIRE);
-
/* this load-acquire synchronize with store-release of ht->tail
* in update_tail.
*/
@@ -165,6 +162,7 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
if (is_sc)
r->cons.head = *new_head, success = 1;
else
+ /* on failure, *old_head will be updated */
success = __atomic_compare_exchange_n(&r->cons.head,
old_head, *new_head,
0, __ATOMIC_ACQUIRE,
--
2.7.4
[dpdk-dev] [PATCH v3 2/3] ring: synchronize the load and store of the tail
Synchronize the load-acquire of the tail and the store-release
within update_tail, the store release ensures all the ring operations,
enqueue or dequeue, are seen by the observers on the other side as soon
as they see the updated tail. The load-acquire is needed here as the
data dependency is not a reliable way for ordering as the compiler might
break it by saving to temporary values to boost performance.
When computing the free_entries and avail_entries, use atomic semantics
to load the heads and tails instead.
The patch was benchmarked with test/ring_perf_autotest and it decreases
the enqueue/dequeue latency by 5% ~ 27.6% with two lcores, the real gains
are dependent on the number of lcores, depth of the ring, SPSC or MPMC.
For 1 lcore, it also improves a little, about 3 ~ 4%.
It is a big improvement, in case of MPMC, with two lcores and ring size
of 32, it saves latency up to (3.26-2.36)/3.26 = 27.6%.
This patch is a bug fix, while the improvement is a bonus. In our analysis
the improvement comes from the cacheline pre-filling after hoisting load-
acquire from _atomic_compare_exchange_n up above.
The test command:
$sudo ./test/test/test -l 16-19,44-47,72-75,100-103 -n 4 --socket-mem=\
1024 -- -i
Test result with this patch(two cores):
SP/SC bulk enq/dequeue (size: 8): 5.86
MP/MC bulk enq/dequeue (size: 8): 10.15
SP/SC bulk enq/dequeue (size: 32): 1.94
MP/MC bulk enq/dequeue (size: 32): 2.36
In comparison of the test result without this patch:
SP/SC bulk enq/dequeue (size: 8): 6.67
MP/MC bulk enq/dequeue (size: 8): 13.12
SP/SC bulk enq/dequeue (size: 32): 2.04
MP/MC bulk enq/dequeue (size: 32): 3.26
Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
Reviewed-by: Steve Capper
Reviewed-by: Ola Liljedahl
---
lib/librte_ring/rte_ring_c11_mem.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/lib/librte_ring/rte_ring_c11_mem.h
b/lib/librte_ring/rte_ring_c11_mem.h
index 234fea0..0eae3b3 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -68,13 +68,18 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int
is_sp,
*old_head = __atomic_load_n(&r->prod.head,
__ATOMIC_ACQUIRE);
- /*
-* The subtraction is done between two unsigned 32bits value
+ /* load-acquire synchronize with store-release of ht->tail
+* in update_tail.
+*/
+ const uint32_t cons_tail = __atomic_load_n(&r->cons.tail,
+ __ATOMIC_ACQUIRE);
+
+ /* The subtraction is done between two unsigned 32bits value
* (the result is always modulo 32 bits even if we have
* *old_head > cons_tail). So 'free_entries' is always between 0
* and capacity (which is < size).
*/
- *free_entries = (capacity + r->cons.tail - *old_head);
+ *free_entries = (capacity + cons_tail - *old_head);
/* check that we have enough room in ring */
if (unlikely(n > *free_entries))
@@ -132,15 +137,22 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
do {
/* Restore n as it may change every loop */
n = max;
+
*old_head = __atomic_load_n(&r->cons.head,
__ATOMIC_ACQUIRE);
+ /* this load-acquire synchronize with store-release of ht->tail
+* in update_tail.
+*/
+ const uint32_t prod_tail = __atomic_load_n(&r->prod.tail,
+ __ATOMIC_ACQUIRE);
+
/* The subtraction is done between two unsigned 32bits value
* (the result is always modulo 32 bits even if we have
* cons_head > prod_tail). So 'entries' is always between 0
* and size(ring)-1.
*/
- *entries = (r->prod.tail - *old_head);
+ *entries = (prod_tail - *old_head);
/* Set the actual entries for dequeue */
if (n > *entries)
--
2.7.4
[dpdk-dev] [PATCH v2] compat: fix symbol version support with meson
For meson builds, the define to enable the symbol version
macros in rte_compat.h was missing. This led to symbols being
omitted from shared objects. For example, checking rte_distributor.so
with objdump and comparing make and meson built versions:
$ objdump -T make-build/lib/librte_distributor.so | grep _flush
1b60 gDF .text 00a7 (DPDK_2.0)
rte_distributor_flush
3f10 gDF .text 0434 DPDK_17.05
rte_distributor_flush
$ objdump -T meson-build/lib/librte_distributor.so | grep _flush
1d50 gDF .text 00fb DPDK_2.0
rte_distributor_flush
Adding in the missing define fixes this.
Fixes: 5b9656b157d3 ("lib: build with meson")
CC: sta...@dpdk.org
Reported-by: Luca Boccassi
Signed-off-by: Bruce Richardson
Tested-by: Luca Boccassi
---
config/rte_config.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/config/rte_config.h b/config/rte_config.h
index a8e479774..46775a841 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -20,6 +20,9 @@
/** library defines /
+/* compat defines */
+#define RTE_BUILD_SHARED_LIB
+
/* EAL defines */
#define RTE_MAX_MEMSEG_LISTS 128
#define RTE_MAX_MEMSEG_PER_LIST 8192
--
2.17.1
Re: [dpdk-dev] [PATCH v2 1/4] build: include missing hypervisor files in Meson build
On Sun, Sep 16, 2018 at 11:00:24AM +0200, Thomas Monjalon wrote:
> 31/08/2018 13:00, Bruce Richardson:
> > On Fri, Aug 31, 2018 at 11:41:51AM +0100, Luca Boccassi wrote:
> > > They are built by the legacy makefiles but not by Meson.
> > >
> > > Fixes: 8f40ee0734c8 ("eal/x86: get hypervisor name")
> > >
> > > Signed-off-by: Luca Boccassi
> >
> > Acked-by: Bruce Richardson
>
> Should we add "Cc: sta...@dpdk.org" for the whole series?
>
Yes, it wouldn't hurt to do so.
Re: [dpdk-dev] [PATCH] config: remove unused macro
On Mon, Sep 17, 2018 at 03:39:32PM +0800, Qi Zhang wrote:
> RTE_LIBRTE_I40E_ITR_INTERVAL is not used. So it should also be removed
> in config/rte_config.h for meson+ninjia build.
>
> Fixes: 864a800d706d ("net/i40e: remove VF interrupt handler")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
I like code removal.
Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH v3 2/3] net/i40e: remove invalid comment
Hi All, I am really sorry I made a mistake by submitting patches from a wrong branch and tried to rescue quickly and made another mistake(submitted one more patch not mine). Please skip these wrong patches(I already superseded them) and help review the new 3 patches for rte ring. Really sorry again for the confusion and inconveniences! Best Regards, Gavin > -Original Message- > From: Gavin Hu > Sent: Monday, September 17, 2018 3:48 PM > To: dev@dpdk.org > Cc: Gavin Hu (Arm Technology China) ; Honnappa > Nagarahalli ; Steve Capper > ; Ola Liljedahl ; > jerin.ja...@caviumnetworks.com; nd ; Ferruh Yigit > > Subject: [PATCH v3 2/3] net/i40e: remove invalid comment > > From: Ferruh Yigit > > Comments says "no csum error report support" but there is no check related > csum offloads. Removing the comment. > > Signed-off-by: Ferruh Yigit > Acked-by: Qi Zhang > --- > drivers/net/i40e/i40e_rxtx_vec_common.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/i40e/i40e_rxtx_vec_common.h > b/drivers/net/i40e/i40e_rxtx_vec_common.h > index 63cb17742..f00f6d648 100644 > --- a/drivers/net/i40e/i40e_rxtx_vec_common.h > +++ b/drivers/net/i40e/i40e_rxtx_vec_common.h > @@ -199,9 +199,7 @@ > i40e_rx_vec_dev_conf_condition_check_default(struct rte_eth_dev *dev) > if (fconf->mode != RTE_FDIR_MODE_NONE) > return -1; > > - /* - no csum error report support > - * - no header split support > - */ > + /* no header split support */ > if (rxmode->offloads & DEV_RX_OFFLOAD_HEADER_SPLIT) > return -1; > > -- > 2.11.0
Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical
Hi, A little bit of self-advertising: I recently pushed patches that will make DPDK default to RTE_IOVA_VA when physical addresses were not explicitly requested and are not available, e.g. when running as a non-privileged user. It shouldn't cause any conflicts with the changes you're proposing here, but any review is welcome. pci/linux: use RTE_IOVA_VA whenever possible http://patches.dpdk.org/patch/44392/ [v2] eal/bus: use RTE_IOVA_PA only if phys addresses are available http://patches.dpdk.org/patch/44420/ As for the --iova-mode=, I agree it could help DPDK use cases where most drivers or devices are hotplugged/hotattached at runtime - e.g. SPDK, it could certainly make use of such param. D. > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Eric Zhang > Sent: Tuesday, September 11, 2018 7:22 PM > To: Burakov, Anatoly ; Jerin Jacob > > Cc: santosh ; > hemant.agra...@nxp.com; Gaëtan Rivet ; > Richardson, Bruce ; dev@dpdk.org; > allain.leg...@windriver.com; matt.pet...@windriver.com > Subject: Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical > > > > On 09/07/2018 04:13 PM, Eric Zhang wrote: > > > > > > On 09/07/2018 05:26 AM, Burakov, Anatoly wrote: > >> On 06-Sep-18 8:34 AM, Jerin Jacob wrote: > >>> -Original Message- > Date: Tue, 4 Sep 2018 23:40:36 -0400 > From: Eric Zhang > To: santosh , > hemant.agra...@nxp.com, > Gaëtan Rivet , "Burakov, Anatoly" > > CC: bruce.richard...@intel.com, dev@dpdk.org, > allain.leg...@windriver.com, > matt.pet...@windriver.com > Subject: Re: [dpdk-dev] [PATCH] eal: force IOVA mode to physical > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Thunderbird/52.9.1 > > On 08/30/2018 08:59 AM, santosh wrote: > > On Thursday 30 August 2018 05:43 PM, Hemant wrote: > >> External Email > >> > >> Hi, > >> > >> On 8/30/2018 3:13 PM, Gaëtan Rivet wrote: > >>> Hi, > >>> > >>> On Thu, Aug 30, 2018 at 10:09:04AM +0100, Burakov, Anatoly wrote: > On 29-Aug-18 4:58 PM, eric zhang wrote: > > This patch adds a configuration option to force the IOVA mode > > to physical address (PA). There exists virtual devices that > > are not directly attached to the PCI bus, and therefore the > > auto detection of the IOVA mode based on probing the PCI bus > > and IOMMU configuration may not report the required > addressing > > mode. Having the configuration option permits the mode to be > > explicitly configured in this scenario. > > > > Signed-off-by: eric zhang > > --- > Defining this at compile-time seems like an overkill. Wouldn't > it be better to just add an EAL command-line option to force > IOVA mode to a particular value? > >> That is a good suggestion. > -- > Thanks, > Anatoly > >>> What is the bus of these devices and why not implement > >>> get_iommu_class in it? > >> There are cases, where you are using dpdk libraries with external > >> libraries and you need to change the default behavior DPDK lib to > >> use physical address instead of virtual address. > >> Providing an option to user will help. > >> > >> > > More appropriate solution could be: > > * Either fix it at bus layer .. i.e.. get_iommu_class().. > > * Or introduce something like [1] --iova-mode= param. > > > > Former is better solution than latter if autodetection is a key > > criteria. > > Thanks. > > > > [1] http://patchwork.dpdk.org/patch/25192/ > > > It's not generic which couldn't be fixed at bus layer. > So what's the preference of EAL option or compile time solution? > Adding --iova-mode as patch [1] will overrivde auto-detection > rte_bus_get_iommu_class() > make it no use; compile time solution will align with upstream and > keep new atuodetection solution in #ifndef. > >>> > >>> If it is for vdev devices, why not introduce something like > >>> RTE_PCI_DRV_IOVA_AS_VA and let vdev device describe its personality. > >>> And based on the devices(flags) on vdev bus, > >>> rte_bus_get_iommu_class() of vdev can decide the mode just like PCI > bus. > >>> > >> > >> That seems like a better option to me, +1. As far as i know, at the > >> moment if there are no devices attached at all, or if there are only > >> vdev devices attached, DPDK will default to IOVA as PA mode for no > >> good reason; such a change would certainly fix this. > > Thanks for the suggestions however our virtual device doesn't run dpdk > > vdev code so we can't use the flag. > > Notice that in eal.c there is one workaround that force iova to be PA > > per virtual device is not directly attached to pci. That case is > > checking kni module. Ours is a similar case that virtual device not > > attach pci directly. > > So
Re: [dpdk-dev] [PATCH v2] compat: fix symbol version support with meson
17/09/2018 10:18, Bruce Richardson:
> For meson builds, the define to enable the symbol version
> macros in rte_compat.h was missing. This led to symbols being
> omitted from shared objects. For example, checking rte_distributor.so
> with objdump and comparing make and meson built versions:
>
> $ objdump -T make-build/lib/librte_distributor.so | grep _flush
> 1b60 gDF .text 00a7 (DPDK_2.0)
> rte_distributor_flush
> 3f10 gDF .text 0434 DPDK_17.05
> rte_distributor_flush
> $ objdump -T meson-build/lib/librte_distributor.so | grep _flush
> 1d50 gDF .text 00fb DPDK_2.0
> rte_distributor_flush
>
> Adding in the missing define fixes this.
>
> Fixes: 5b9656b157d3 ("lib: build with meson")
>
> CC: sta...@dpdk.org
> Reported-by: Luca Boccassi
> Signed-off-by: Bruce Richardson
> Tested-by: Luca Boccassi
Applied, thanks
[dpdk-dev] [PATCH v3 3/4] build: use -Wno-error=format-security for Meson i40e build
This PMD is built with -Wno-format, which means GCC errors out if
-Wformat-security is used.
Fixes: e940646b20fa ("drivers/net: build Intel NIC PMDs with meson")
Cc: sta...@dpdk.org
Signed-off-by: Luca Boccassi
Acked-by: Bruce Richardson
---
v2: re-arranged flags
v3: added acked-by and cc stable
drivers/net/i40e/base/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/base/meson.build
b/drivers/net/i40e/base/meson.build
index 401a1477fa..e6163eaa6c 100644
--- a/drivers/net/i40e/base/meson.build
+++ b/drivers/net/i40e/base/meson.build
@@ -12,8 +12,8 @@ sources = [
]
error_cflags = ['-Wno-sign-compare', '-Wno-unused-value',
- '-Wno-format', '-Wno-unused-but-set-variable',
- '-Wno-strict-aliasing'
+ '-Wno-format', '-Wno-error=format-security',
+ '-Wno-strict-aliasing', '-Wno-unused-but-set-variable'
]
c_args = cflags
foreach flag: error_cflags
--
2.18.0
[dpdk-dev] [PATCH v3 1/4] build: include missing hypervisor files in Meson build
They are built by the legacy makefiles but not by Meson.
Fixes: 8f40ee0734c8 ("eal/x86: get hypervisor name")
Cc: sta...@dpdk.org
Signed-off-by: Luca Boccassi
Acked-by: Bruce Richardson
---
v3: added acked-by and cc stable
lib/librte_eal/common/arch/arm/meson.build | 2 +-
lib/librte_eal/common/arch/x86/meson.build | 2 +-
lib/librte_eal/common/meson.build | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/arch/arm/meson.build
b/lib/librte_eal/common/arch/arm/meson.build
index c6bd92272b..79731e1a2c 100644
--- a/lib/librte_eal/common/arch/arm/meson.build
+++ b/lib/librte_eal/common/arch/arm/meson.build
@@ -2,4 +2,4 @@
# Copyright(c) 2017 Intel Corporation.
eal_common_arch_sources = files('rte_cpuflags.c',
- 'rte_cycles.c')
+ 'rte_cycles.c', 'rte_hypervisor.c')
diff --git a/lib/librte_eal/common/arch/x86/meson.build
b/lib/librte_eal/common/arch/x86/meson.build
index 4e0f77900a..14bf204c6f 100644
--- a/lib/librte_eal/common/arch/x86/meson.build
+++ b/lib/librte_eal/common/arch/x86/meson.build
@@ -2,4 +2,4 @@
# Copyright(c) 2017 Intel Corporation
eal_common_arch_sources = files('rte_spinlock.c', 'rte_cpuflags.c',
- 'rte_cycles.c')
+ 'rte_cycles.c', 'rte_hypervisor.c')
diff --git a/lib/librte_eal/common/meson.build
b/lib/librte_eal/common/meson.build
index 56005bea80..b7fc984997 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -14,6 +14,7 @@ common_sources = files(
'eal_common_errno.c',
'eal_common_fbarray.c',
'eal_common_hexdump.c',
+ 'eal_common_hypervisor.c',
'eal_common_launch.c',
'eal_common_lcore.c',
'eal_common_log.c',
@@ -59,6 +60,7 @@ common_headers = files(
'include/rte_errno.h',
'include/rte_fbarray.h',
'include/rte_hexdump.h',
+ 'include/rte_hypervisor.h',
'include/rte_interrupts.h',
'include/rte_keepalive.h',
'include/rte_launch.h',
--
2.18.0
[dpdk-dev] [PATCH v3 2/4] build: use -Wno-error=format-security for Meson ifpga_rawdev build
This PMD is built with -Wno-format, which means GCC errors out if
-Wformat-security is used.
Fixes: 56bb54ea1bdf ("raw/ifpga/base: add Intel FPGA OPAE share code")
Cc: sta...@dpdk.org
Signed-off-by: Luca Boccassi
Acked-by: Bruce Richardson
---
v2: re-arranged flags
v3: added acked-by and cc stable
drivers/raw/ifpga_rawdev/base/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/meson.build
b/drivers/raw/ifpga_rawdev/base/meson.build
index cb6553521d..03f5112caa 100644
--- a/drivers/raw/ifpga_rawdev/base/meson.build
+++ b/drivers/raw/ifpga_rawdev/base/meson.build
@@ -18,8 +18,8 @@ sources = [
]
error_cflags = ['-Wno-sign-compare', '-Wno-unused-value',
- '-Wno-format', '-Wno-unused-but-set-variable',
- '-Wno-strict-aliasing'
+ '-Wno-format', '-Wno-error=format-security',
+ '-Wno-strict-aliasing', '-Wno-unused-but-set-variable'
]
c_args = cflags
foreach flag: error_cflags
--
2.18.0
[dpdk-dev] [PATCH v3 4/4] build: install igb_uio kernel module when building with Meson
Install in $kerneldir/../extra/dpdk. Usually $kerneldir should something
like: /lib/modules/$kver/build, so this directory will match the default
one used by legacy makefiles.
Fixes: a52f4574f798 ("igb_uio: build with meson")
Cc: sta...@dpdk.org
Signed-off-by: Luca Boccassi
Acked-by: Bruce Richardson
---
v2: fixed DEST_DIR in option help text
v3: added acked-by and cc stable
kernel/linux/igb_uio/meson.build | 2 ++
meson_options.txt| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/linux/igb_uio/meson.build b/kernel/linux/igb_uio/meson.build
index 71ed2e7a85..f5a9d5ccf3 100644
--- a/kernel/linux/igb_uio/meson.build
+++ b/kernel/linux/igb_uio/meson.build
@@ -15,4 +15,6 @@ custom_target('igb_uio',
'/../../../lib/librte_eal/common/include',
'modules'],
depends: mkfile,
+ install: true,
+ install_dir: kernel_dir + '/../extra/dpdk',
build_by_default: get_option('enable_kmods'))
diff --git a/meson_options.txt b/meson_options.txt
index c843278587..f20887212a 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -7,7 +7,7 @@ option('examples', type: 'string', value: '',
option('include_subdir_arch', type: 'string', value: '',
description: 'subdirectory where to install arch-dependent headers')
option('kernel_dir', type: 'string', value: '',
- description: 'path to the kernel for building kernel modules')
+ description: 'path to the kernel for building kernel modules, they will
be installed in $DEST_DIR/$kernel_dir/../extra/dpdk')
option('lib_musdk_dir', type: 'string', value: '',
description: 'path to the MUSDK library installation directory')
option('machine', type: 'string', value: 'native',
--
2.18.0
Re: [dpdk-dev] [PATCH] crypto/qat: fix typo
> -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, September 17, 2018 8:56 AM > To: Trahe, Fiona ; akhil.go...@nxp.com > Cc: dev@dpdk.org; De Lara Guarch, Pablo ; > Jozwiak, TomaszX > > Subject: Re: [dpdk-dev] [PATCH] crypto/qat: fix typo > > Hi, > > 10/08/2018 17:20, Trahe, Fiona: > > > -/**< Intel(R) QAT Symmetric Crypto PMD device name */ > > > +/**< Intel(R) QAT Symmetric Crypto PMD driver name */ > > > #define CRYPTODEV_NAME_QAT_SYM_PMD crypto_qat > > The comment is above, so the syntax should be /**, not /**< > Do you want me to fix it when pulling in master? > That would be great thanks.
Re: [dpdk-dev] [PATCH v2 1/4] build: include missing hypervisor files in Meson build
On Mon, 2018-09-17 at 09:20 +0100, Bruce Richardson wrote:
> On Sun, Sep 16, 2018 at 11:00:24AM +0200, Thomas Monjalon wrote:
> > 31/08/2018 13:00, Bruce Richardson:
> > > On Fri, Aug 31, 2018 at 11:41:51AM +0100, Luca Boccassi wrote:
> > > > They are built by the legacy makefiles but not by Meson.
> > > >
> > > > Fixes: 8f40ee0734c8 ("eal/x86: get hypervisor name")
> > > >
> > > > Signed-off-by: Luca Boccassi
> > >
> > > Acked-by: Bruce Richardson
> >
> > Should we add "Cc: sta...@dpdk.org" for the whole series?
> >
>
> Yes, it wouldn't hurt to do so.
Done in v3, thanks
--
Kind regards,
Luca Boccassi
Re: [dpdk-dev] [PATCH v5 09/11] net/virtio: disable ctrl virtqueue for packed rings
On Fri, Sep 14, 2018 at 01:32:36PM +0800, Tiwei Bie wrote:
On Thu, Sep 06, 2018 at 07:19:45PM +0100, Jens Freimann wrote:
Signed-off-by: Jens Freiman
---
drivers/net/virtio/virtio_ethdev.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index a2bb726ba..b02c65598 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1161,6 +1161,15 @@ virtio_negotiate_features(struct virtio_hw *hw, uint64_t
req_features)
req_features &= ~(1ULL << VIRTIO_NET_F_MTU);
}
+#ifdef RTE_LIBRTE_VIRTIO_PQ
+ if (req_features & (1ULL << VIRTIO_F_RING_PACKED)) {
+ req_features &= ~(1ull << VIRTIO_NET_F_CTRL_MAC_ADDR);
+ req_features &= ~(1ull << VIRTIO_NET_F_CTRL_VQ);
+ req_features &= ~(1ull << VIRTIO_NET_F_CTRL_RX);
+ req_features &= ~(1ull << VIRTIO_NET_F_CTRL_VLAN);
+ }
+#endif
I think we need to support ctrl vq.
I will add it to the next version.
And in performance test, we need to use more cores on vhost
side to make sure that we can get the max performance of the
virtio PMD. Otherwise, it's likely that the performance gain
we get is the gain in vhost.
ok.
thanks!
regards,
Jens
[dpdk-dev] Patches in need of some attention
On behalf of Tomasz (who is out of office) I'd like to attract some attention of DPDK community to the following list of patch sets: crypto/mvsam: add new features and fixes http://patches.dpdk.org/project/dpdk/list/?series=1048 https://mails.dpdk.org/archives/dev/2018-August/thread.html#110133 crypto/mvsam: yet another round of features http://patches.dpdk.org/project/dpdk/list/?series=1063 https://mails.dpdk.org/archives/dev/2018-August/thread.html#110217 net/mvpp2: add new features http://patches.dpdk.org/project/dpdk/list/?series=1171 https://mails.dpdk.org/archives/dev/2018-September/thread.html#110812 crypto/mvsam: align with MUSDK 18.09 http://patches.dpdk.org/project/dpdk/list/?series=1172 https://mails.dpdk.org/archives/dev/2018-September/thread.html#110871 Thank you in advance. Best regards Andrzej
[dpdk-dev] [PATCH v2 0/7] update ixgbe base code
Update the ixgbe base code to version cid-ixgbe.2018.08.28.tar.gz. Xiaoyun Li (7): net/ixgbe/base: update the license net/ixgbe/base: cleanup codes net/ixgbe/base: add FW recovery mode check net/ixgbe/base: relpace an operation in X550 setup net/ixgbe/base: update X550 SFP identification net/ixgbe/base: add support for DCB registers dump net/ixgbe/base: update README file drivers/net/ixgbe/base/README| 4 +- drivers/net/ixgbe/base/ixgbe_82598.c | 35 ++ drivers/net/ixgbe/base/ixgbe_82598.h | 35 ++ drivers/net/ixgbe/base/ixgbe_82599.c | 45 ++ drivers/net/ixgbe/base/ixgbe_82599.h | 35 ++ drivers/net/ixgbe/base/ixgbe_api.c | 50 ++-- drivers/net/ixgbe/base/ixgbe_api.h | 36 ++- drivers/net/ixgbe/base/ixgbe_common.c| 41 ++-- drivers/net/ixgbe/base/ixgbe_common.h| 35 ++ drivers/net/ixgbe/base/ixgbe_dcb.c | 35 ++ drivers/net/ixgbe/base/ixgbe_dcb.h | 35 ++ drivers/net/ixgbe/base/ixgbe_dcb_82598.c | 35 ++ drivers/net/ixgbe/base/ixgbe_dcb_82598.h | 35 ++ drivers/net/ixgbe/base/ixgbe_dcb_82599.c | 35 ++ drivers/net/ixgbe/base/ixgbe_dcb_82599.h | 35 ++ drivers/net/ixgbe/base/ixgbe_hv_vf.c | 35 ++ drivers/net/ixgbe/base/ixgbe_hv_vf.h | 35 ++ drivers/net/ixgbe/base/ixgbe_mbx.c | 35 ++ drivers/net/ixgbe/base/ixgbe_mbx.h | 35 ++ drivers/net/ixgbe/base/ixgbe_osdep.h | 36 ++- drivers/net/ixgbe/base/ixgbe_phy.c | 36 ++- drivers/net/ixgbe/base/ixgbe_phy.h | 35 ++ drivers/net/ixgbe/base/ixgbe_type.h | 53 ++--- drivers/net/ixgbe/base/ixgbe_vf.c| 35 ++ drivers/net/ixgbe/base/ixgbe_vf.h| 35 ++ drivers/net/ixgbe/base/ixgbe_x540.c | 35 ++ drivers/net/ixgbe/base/ixgbe_x540.h | 35 ++ drivers/net/ixgbe/base/ixgbe_x550.c | 59 +--- drivers/net/ixgbe/base/ixgbe_x550.h | 36 ++- drivers/net/ixgbe/ixgbe_ethdev.c | 1 - 30 files changed, 131 insertions(+), 931 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v2 2/7] net/ixgbe/base: cleanup codes
Cleanup UNREFERENCED_1PARAMETER() macro because "hw" is used.
And remove Light Spring codes because the device was never
productised. And cleanup unused bypass codes.
Signed-off-by: Xiaoyun Li
---
v2:
* Merge base code change and ethdev fix into 1 patch to avoid in
* between build issue.
---
drivers/net/ixgbe/base/ixgbe_82599.c | 10 --
drivers/net/ixgbe/base/ixgbe_api.c| 3 ---
drivers/net/ixgbe/base/ixgbe_common.c | 6 --
drivers/net/ixgbe/base/ixgbe_phy.c| 1 -
drivers/net/ixgbe/base/ixgbe_type.h | 9 ++---
drivers/net/ixgbe/ixgbe_ethdev.c | 1 -
6 files changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_82599.c
b/drivers/net/ixgbe/base/ixgbe_82599.c
index 33d8c4a31..7de753fd3 100644
--- a/drivers/net/ixgbe/base/ixgbe_82599.c
+++ b/drivers/net/ixgbe/base/ixgbe_82599.c
@@ -58,9 +58,6 @@ void ixgbe_init_mac_link_ops_82599(struct ixgbe_hw *hw)
mac->ops.setup_mac_link = ixgbe_setup_mac_link_82599;
mac->ops.set_rate_select_speed =
ixgbe_set_hard_rate_select_speed;
- if (ixgbe_get_media_type(hw) == ixgbe_media_type_fiber_fixed)
- mac->ops.set_rate_select_speed =
- ixgbe_set_soft_rate_select_speed;
} else {
if ((ixgbe_get_media_type(hw) == ixgbe_media_type_backplane) &&
(hw->phy.smart_speed == ixgbe_smart_speed_auto ||
@@ -532,16 +529,9 @@ enum ixgbe_media_type ixgbe_get_media_type_82599(struct
ixgbe_hw *hw)
case IXGBE_DEV_ID_82599_T3_LOM:
media_type = ixgbe_media_type_copper;
break;
- case IXGBE_DEV_ID_82599_LS:
- media_type = ixgbe_media_type_fiber_lco;
- break;
case IXGBE_DEV_ID_82599_QSFP_SF_QP:
media_type = ixgbe_media_type_fiber_qsfp;
break;
- case IXGBE_DEV_ID_82599_BYPASS:
- media_type = ixgbe_media_type_fiber_fixed;
- hw->phy.multispeed_fiber = true;
- break;
default:
media_type = ixgbe_media_type_unknown;
break;
diff --git a/drivers/net/ixgbe/base/ixgbe_api.c
b/drivers/net/ixgbe/base/ixgbe_api.c
index a2eab1361..3450d401f 100644
--- a/drivers/net/ixgbe/base/ixgbe_api.c
+++ b/drivers/net/ixgbe/base/ixgbe_api.c
@@ -148,8 +148,6 @@ s32 ixgbe_set_mac_type(struct ixgbe_hw *hw)
case IXGBE_DEV_ID_82599_QSFP_SF_QP:
case IXGBE_DEV_ID_82599EN_SFP:
case IXGBE_DEV_ID_82599_CX4:
- case IXGBE_DEV_ID_82599_LS:
- case IXGBE_DEV_ID_82599_BYPASS:
case IXGBE_DEV_ID_82599_T3_LOM:
hw->mac.type = ixgbe_mac_82599EB;
break;
@@ -164,7 +162,6 @@ s32 ixgbe_set_mac_type(struct ixgbe_hw *hw)
break;
case IXGBE_DEV_ID_X540T:
case IXGBE_DEV_ID_X540T1:
- case IXGBE_DEV_ID_X540_BYPASS:
hw->mac.type = ixgbe_mac_X540;
hw->mvals = ixgbe_mvals_X540;
break;
diff --git a/drivers/net/ixgbe/base/ixgbe_common.c
b/drivers/net/ixgbe/base/ixgbe_common.c
index d7b63c656..b4a0d7003 100644
--- a/drivers/net/ixgbe/base/ixgbe_common.c
+++ b/drivers/net/ixgbe/base/ixgbe_common.c
@@ -138,7 +138,6 @@ bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw)
DEBUGFUNC("ixgbe_device_supports_autoneg_fc");
switch (hw->phy.media_type) {
- case ixgbe_media_type_fiber_fixed:
case ixgbe_media_type_fiber_qsfp:
case ixgbe_media_type_fiber:
/* flow control autoneg black list */
@@ -172,7 +171,6 @@ bool ixgbe_device_supports_autoneg_fc(struct ixgbe_hw *hw)
case IXGBE_DEV_ID_82599_T3_LOM:
case IXGBE_DEV_ID_X540T:
case IXGBE_DEV_ID_X540T1:
- case IXGBE_DEV_ID_X540_BYPASS:
case IXGBE_DEV_ID_X550T:
case IXGBE_DEV_ID_X550T1:
case IXGBE_DEV_ID_X550EM_X_10G_T:
@@ -238,7 +236,6 @@ s32 ixgbe_setup_fc_generic(struct ixgbe_hw *hw)
goto out;
/* fall through - only backplane uses autoc */
- case ixgbe_media_type_fiber_fixed:
case ixgbe_media_type_fiber_qsfp:
case ixgbe_media_type_fiber:
reg = IXGBE_READ_REG(hw, IXGBE_PCS1GANA);
@@ -3098,7 +3095,6 @@ void ixgbe_fc_autoneg(struct ixgbe_hw *hw)
switch (hw->phy.media_type) {
/* Autoneg flow control on fiber adapters */
- case ixgbe_media_type_fiber_fixed:
case ixgbe_media_type_fiber_qsfp:
case ixgbe_media_type_fiber:
if (speed == IXGBE_LINK_SPEED_1GB_FULL)
@@ -5238,7 +5234,6 @@ s32 ixgbe_setup_mac_link_multispeed_fiber(struct ixgbe_hw
*hw,
/* Set the module link speed */
switch (hw->phy.media_type) {
- case ixgbe_media_type_fiber_fixed:
[dpdk-dev] [PATCH v2 1/7] net/ixgbe/base: update the license
Update the GPL and BSD license headers to use the SPDX License Identifier instead. Signed-off-by: Xiaoyun Li --- drivers/net/ixgbe/base/ixgbe_82598.c | 35 ++- drivers/net/ixgbe/base/ixgbe_82598.h | 35 ++- drivers/net/ixgbe/base/ixgbe_82599.c | 35 ++- drivers/net/ixgbe/base/ixgbe_82599.h | 35 ++- drivers/net/ixgbe/base/ixgbe_api.c | 35 ++- drivers/net/ixgbe/base/ixgbe_api.h | 35 ++- drivers/net/ixgbe/base/ixgbe_common.c| 35 ++- drivers/net/ixgbe/base/ixgbe_common.h| 35 ++- drivers/net/ixgbe/base/ixgbe_dcb.c | 35 ++- drivers/net/ixgbe/base/ixgbe_dcb.h | 35 ++- drivers/net/ixgbe/base/ixgbe_dcb_82598.c | 35 ++- drivers/net/ixgbe/base/ixgbe_dcb_82598.h | 35 ++- drivers/net/ixgbe/base/ixgbe_dcb_82599.c | 35 ++- drivers/net/ixgbe/base/ixgbe_dcb_82599.h | 35 ++- drivers/net/ixgbe/base/ixgbe_hv_vf.c | 35 ++- drivers/net/ixgbe/base/ixgbe_hv_vf.h | 35 ++- drivers/net/ixgbe/base/ixgbe_mbx.c | 35 ++- drivers/net/ixgbe/base/ixgbe_mbx.h | 35 ++- drivers/net/ixgbe/base/ixgbe_osdep.h | 36 ++-- drivers/net/ixgbe/base/ixgbe_phy.c | 35 ++- drivers/net/ixgbe/base/ixgbe_phy.h | 35 ++- drivers/net/ixgbe/base/ixgbe_type.h | 35 ++- drivers/net/ixgbe/base/ixgbe_vf.c| 35 ++- drivers/net/ixgbe/base/ixgbe_vf.h| 35 ++- drivers/net/ixgbe/base/ixgbe_x540.c | 35 ++- drivers/net/ixgbe/base/ixgbe_x540.h | 35 ++- drivers/net/ixgbe/base/ixgbe_x550.c | 35 ++- drivers/net/ixgbe/base/ixgbe_x550.h | 35 ++- 28 files changed, 84 insertions(+), 897 deletions(-) diff --git a/drivers/net/ixgbe/base/ixgbe_82598.c b/drivers/net/ixgbe/base/ixgbe_82598.c index ee7ce2e9b..245ff75d5 100644 --- a/drivers/net/ixgbe/base/ixgbe_82598.c +++ b/drivers/net/ixgbe/base/ixgbe_82598.c @@ -1,35 +1,6 @@ -/*** - -Copyright (c) 2001-2015, Intel Corporation -All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are met: - - 1. Redistributions of source code must retain the above copyright notice, -this list of conditions and the following disclaimer. - - 2. 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. - - 3. Neither the name of the Intel 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(c) 2001-2018 + */ #include "ixgbe_type.h" #include "ixgbe_82598.h" diff --git a/drivers/net/ixgbe/base/ixgbe_82598.h b/drivers/net/ixgbe/base/ixgbe_82598.h index 20aab9fc2..8013f495e 100644 --- a/drivers/net/ixgbe/base/ixgbe_82598.h +++ b/drivers/net/ixgbe/base/ixgbe_82598.h @@ -1,35 +1,6 @@ -/*** - -Copyright (c) 2001-2015, Intel Corporation -All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are met: - - 1. Redistributions of source code must retain the above copyright notice, -this list of conditions and the following disclaimer. - - 2. Redistributions in binary form must reproduce the above copyright -notice, this list of conditions and the
[dpdk-dev] [PATCH v2 4/7] net/ixgbe/base: relpace an operation in X550 setup
Replace "=" operation with "|=" operation to only set the intended register bits. Signed-off-by: Xiaoyun Li --- drivers/net/ixgbe/base/ixgbe_x550.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c index c9f1563a9..d5bbfadd4 100644 --- a/drivers/net/ixgbe/base/ixgbe_x550.c +++ b/drivers/net/ixgbe/base/ixgbe_x550.c @@ -2780,9 +2780,9 @@ s32 ixgbe_setup_mac_link_sfp_x550a(struct ixgbe_hw *hw, (IXGBE_CS4227_EDC_MODE_SR << 1)); if (setup_linear) - reg_phy_ext = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1; + reg_phy_ext |= (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1; else - reg_phy_ext = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1; + reg_phy_ext |= (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1; ret_val = hw->phy.ops.write_reg(hw, reg_slice, IXGBE_MDIO_ZERO_DEV_TYPE, reg_phy_ext); -- 2.17.1
[dpdk-dev] [PATCH v2 6/7] net/ixgbe/base: add support for DCB registers dump
Add support for DCB registers dump.
Signed-off-by: Xiaoyun Li
---
drivers/net/ixgbe/base/ixgbe_type.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ixgbe/base/ixgbe_type.h
b/drivers/net/ixgbe/base/ixgbe_type.h
index ea34bb979..cee6ba2e0 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -850,6 +850,10 @@ struct ixgbe_dmac_config {
#define IXGBE_RTTDQSEL 0x04904
#define IXGBE_RTTDT1C 0x04908
#define IXGBE_RTTDT1S 0x0490C
+#define IXGBE_RTTQCNCR 0x08B00
+#define IXGBE_RTTQCNTG 0x04A90
+#define IXGBE_RTTBCNRD 0x0498C
+#define IXGBE_RTTQCNRR 0x0498C
#define IXGBE_RTTDTECC 0x04990
#define IXGBE_RTTDTECC_NO_BCN 0x0100
@@ -860,6 +864,7 @@ struct ixgbe_dmac_config {
#define IXGBE_RTTBCNRC_RF_INT_MASK \
(IXGBE_RTTBCNRC_RF_DEC_MASK << IXGBE_RTTBCNRC_RF_INT_SHIFT)
#define IXGBE_RTTBCNRM 0x04980
+#define IXGBE_RTTQCNRM 0x04980
/* BCN (for DCB) Registers */
#define IXGBE_RTTBCNRS 0x04988
--
2.17.1
[dpdk-dev] [PATCH v2 5/7] net/ixgbe/base: update X550 SFP identification
Use ixgbe_identify_sfp_module_X550em to update SFP identification
flow. ixgbe_identify_sfp_module_X550em includes specific checks for
X550 about supported SFP modules.
Signed-off-by: Xiaoyun Li
---
drivers/net/ixgbe/base/ixgbe_x550.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c
b/drivers/net/ixgbe/base/ixgbe_x550.c
index d5bbfadd4..f7b98af52 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -321,7 +321,7 @@ STATIC s32 ixgbe_identify_phy_x550em(struct ixgbe_hw *hw)
switch (hw->device_id) {
case IXGBE_DEV_ID_X550EM_A_SFP:
- return ixgbe_identify_module_generic(hw);
+ return ixgbe_identify_sfp_module_X550em(hw);
case IXGBE_DEV_ID_X550EM_X_SFP:
/* set up for CS4227 usage */
ixgbe_setup_mux_ctl(hw);
@@ -329,7 +329,7 @@ STATIC s32 ixgbe_identify_phy_x550em(struct ixgbe_hw *hw)
/* Fallthrough */
case IXGBE_DEV_ID_X550EM_A_SFP_N:
- return ixgbe_identify_module_generic(hw);
+ return ixgbe_identify_sfp_module_X550em(hw);
break;
case IXGBE_DEV_ID_X550EM_X_KX4:
hw->phy.type = ixgbe_phy_x550em_kx4;
--
2.17.1
[dpdk-dev] [PATCH v2 3/7] net/ixgbe/base: add FW recovery mode check
Add FM NVM recovery mode check. Allow the software to detect this.
Signed-off-by: Xiaoyun Li
---
drivers/net/ixgbe/base/ixgbe_api.c | 12
drivers/net/ixgbe/base/ixgbe_api.h | 1 +
drivers/net/ixgbe/base/ixgbe_type.h | 4
drivers/net/ixgbe/base/ixgbe_x550.c | 16
drivers/net/ixgbe/base/ixgbe_x550.h | 1 +
5 files changed, 34 insertions(+)
diff --git a/drivers/net/ixgbe/base/ixgbe_api.c
b/drivers/net/ixgbe/base/ixgbe_api.c
index 3450d401f..873c07999 100644
--- a/drivers/net/ixgbe/base/ixgbe_api.c
+++ b/drivers/net/ixgbe/base/ixgbe_api.c
@@ -1327,6 +1327,18 @@ void ixgbe_restore_mdd_vf(struct ixgbe_hw *hw, u32 vf)
hw->mac.ops.restore_mdd_vf(hw, vf);
}
+/**
+ * ixgbe_fw_recovery_mode - Check if in FW NVM recovery mode
+ * @hw: pointer to hardware structure
+ *
+ **/
+bool ixgbe_fw_recovery_mode(struct ixgbe_hw *hw)
+{
+ if (hw->mac.ops.fw_recovery_mode)
+ return hw->mac.ops.fw_recovery_mode(hw);
+ return false;
+}
+
/**
* ixgbe_enter_lplu - Transition to low power states
* @hw: pointer to hardware structure
diff --git a/drivers/net/ixgbe/base/ixgbe_api.h
b/drivers/net/ixgbe/base/ixgbe_api.h
index 8ec951e60..ff8f7b261 100644
--- a/drivers/net/ixgbe/base/ixgbe_api.h
+++ b/drivers/net/ixgbe/base/ixgbe_api.h
@@ -185,6 +185,7 @@ void ixgbe_disable_mdd(struct ixgbe_hw *hw);
void ixgbe_enable_mdd(struct ixgbe_hw *hw);
void ixgbe_mdd_event(struct ixgbe_hw *hw, u32 *vf_bitmap);
void ixgbe_restore_mdd_vf(struct ixgbe_hw *hw, u32 vf);
+bool ixgbe_fw_recovery_mode(struct ixgbe_hw *hw);
s32 ixgbe_enter_lplu(struct ixgbe_hw *hw);
s32 ixgbe_handle_lasi(struct ixgbe_hw *hw);
void ixgbe_set_rate_select_speed(struct ixgbe_hw *hw, ixgbe_link_speed speed);
diff --git a/drivers/net/ixgbe/base/ixgbe_type.h
b/drivers/net/ixgbe/base/ixgbe_type.h
index ff3546ece..ea34bb979 100644
--- a/drivers/net/ixgbe/base/ixgbe_type.h
+++ b/drivers/net/ixgbe/base/ixgbe_type.h
@@ -1067,6 +1067,9 @@ struct ixgbe_dmac_config {
#define IXGBE_FWSM_MODE_MASK 0xE
#define IXGBE_FWSM_TS_ENABLED 0x1
#define IXGBE_FWSM_FW_MODE_PT 0x4
+#define IXGBE_FWSM_FW_NVM_RECOVERY_MODE (1 << 5)
+#define IXGBE_FWSM_EXT_ERR_IND_MASK 0x01F8
+#define IXGBE_FWSM_FW_VAL_BIT (1 << 15)
/* ARC Subsystem registers */
#define IXGBE_HICR 0x15F00
@@ -4016,6 +4019,7 @@ struct ixgbe_mac_operations {
void (*enable_mdd)(struct ixgbe_hw *hw);
void (*mdd_event)(struct ixgbe_hw *hw, u32 *vf_bitmap);
void (*restore_mdd_vf)(struct ixgbe_hw *hw, u32 vf);
+ bool (*fw_recovery_mode)(struct ixgbe_hw *hw);
};
struct ixgbe_phy_operations {
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c
b/drivers/net/ixgbe/base/ixgbe_x550.c
index a44d95e95..c9f1563a9 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -53,6 +53,7 @@ s32 ixgbe_init_ops_X550(struct ixgbe_hw *hw)
mac->ops.enable_mdd = ixgbe_enable_mdd_X550;
mac->ops.mdd_event = ixgbe_mdd_event_X550;
mac->ops.restore_mdd_vf = ixgbe_restore_mdd_vf_X550;
+ mac->ops.fw_recovery_mode = ixgbe_fw_recovery_mode_X550;
mac->ops.disable_rx = ixgbe_disable_rx_x550;
/* Manageability interface */
mac->ops.set_fw_drv_ver = ixgbe_set_fw_drv_ver_x550;
@@ -4632,3 +4633,18 @@ s32 ixgbe_set_fw_drv_ver_x550(struct ixgbe_hw *hw, u8
maj, u8 min,
return ret_val;
}
+
+/**
+ * ixgbe_fw_recovery_mode_X550 - Check FW NVM recovery mode
+ * @hw: pointer t hardware structure
+ *
+ * Returns true if in FW NVM recovery mode.
+ **/
+bool ixgbe_fw_recovery_mode_X550(struct ixgbe_hw *hw)
+{
+ u32 fwsm;
+
+ fwsm = IXGBE_READ_REG(hw, IXGBE_FWSM_BY_MAC(hw));
+
+ return !!(fwsm & IXGBE_FWSM_FW_NVM_RECOVERY_MODE);
+}
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.h
b/drivers/net/ixgbe/base/ixgbe_x550.h
index f90007ce8..3bd98f243 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.h
+++ b/drivers/net/ixgbe/base/ixgbe_x550.h
@@ -92,4 +92,5 @@ s32 ixgbe_reset_phy_t_X550em(struct ixgbe_hw *hw);
s32 ixgbe_identify_sfp_module_X550em(struct ixgbe_hw *hw);
s32 ixgbe_led_on_t_X550em(struct ixgbe_hw *hw, u32 led_idx);
s32 ixgbe_led_off_t_X550em(struct ixgbe_hw *hw, u32 led_idx);
+bool ixgbe_fw_recovery_mode_X550(struct ixgbe_hw *hw);
#endif /* _IXGBE_X550_H_ */
--
2.17.1
[dpdk-dev] [PATCH v2 7/7] net/ixgbe/base: update README file
Update README file to specify the version of CID drop. Signed-off-by: Xiaoyun Li --- drivers/net/ixgbe/base/README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ixgbe/base/README b/drivers/net/ixgbe/base/README index 70fdfe7c8..431be0260 100644 --- a/drivers/net/ixgbe/base/README +++ b/drivers/net/ixgbe/base/README @@ -1,7 +1,7 @@ .. BSD LICENSE - Copyright(c) 2010-2017 Intel Corporation. All rights reserved. + Copyright(c) 2010-2018 Intel Corporation. All rights reserved. All rights reserved. Redistribution and use in source and binary forms, with or without @@ -34,7 +34,7 @@ Intel® IXGBE driver === This directory contains source code of FreeBSD ixgbe driver of version -cid-ixgbe.2018.01.02.tar.gz released by the team which develop +cid-ixgbe.2018.08.28.tar.gz released by the team which develop basic drivers for any ixgbe NIC. The sub-directory of base/ contains the original source package. This driver is valid for the product(s) listed below -- 2.17.1
Re: [dpdk-dev] [PATCH v3 3/3] doc: add cross compile part for sample applications
-Original Message-
> Date: Mon, 17 Sep 2018 15:47:35 +0800
> From: Gavin Hu
> To: dev@dpdk.org
> CC: gavin...@arm.com, honnappa.nagaraha...@arm.com, steve.cap...@arm.com,
> ola.liljed...@arm.com, jerin.ja...@caviumnetworks.com, n...@arm.com,
> sta...@dpdk.org
> Subject: [PATCH v3 3/3] doc: add cross compile part for sample applications
> X-Mailer: git-send-email 2.11.0
>
> External Email
>
> Fixes: 7cacb05655 ("doc: add generic build instructions for sample apps")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Gavin Hu
> Reviewed-by: Honnappa Nagarahalli
> ---
> doc/guides/sample_app_ug/compiling.rst | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/sample_app_ug/compiling.rst
> b/doc/guides/sample_app_ug/compiling.rst
> index a2d75ed22..6f04743c8 100644
> --- a/doc/guides/sample_app_ug/compiling.rst
> +++ b/doc/guides/sample_app_ug/compiling.rst
> @@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
> applications.
> To compile all the sample applications
> --
>
> -
> Set the path to DPDK source code if its not set:
>
> .. code-block:: console
> @@ -93,3 +92,17 @@ Build the application:
>
> export RTE_TARGET=build
> make
> +
> +To cross compile the sample application(s)
> +--
> +
> +For cross compiling the sample application(s), please append
> 'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
> +In example of AARCH64 cross compiling:
> +
> +.. code-block:: console
> +
> +export RTE_TARGET=build
> +export RTE_SDK=/path/to/rte_sdk
> +make -C examples CROSS=aarch64-linux-gnu-
> + or
> +make CROSS=aarch64-linux-gnu-
It should be make -C examples/l3fwd CROSS=aarch64-linux-gnu-, Right? as
without giving directory it builds the SDK only.
> --
> 2.11.0
>
Re: [dpdk-dev] [PATCH v3 2/9] eal: don't allow legacy mode with in-memory mode
On 13-Sep-18 2:06 PM, Maxime Coquelin wrote:
On 09/04/2018 05:15 PM, Anatoly Burakov wrote:
In-memory mode was never meant to support legacy mode, because we
cannot sort anonymous pages anyway.
Fixes: 72b49ff623c4 ("mem: support --in-memory mode")
Cc: sta...@dpdk.org
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/common/eal_common_options.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index dd5f97402..873099acc 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -1390,6 +1390,12 @@ eal_check_common_options(struct internal_config
*internal_cfg)
"--"OPT_HUGE_UNLINK"\n");
return -1;
}
+ if (internal_cfg->legacy_mem &&
+ internal_cfg->in_memory) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_LEGACY_MEM" is not compatible "
+ "with --"OPT_IN_MEMORY"\n");
This is a general comment, as it is consistent with the style of the
file. I generally prefer not splitting error strings into multiple lines
even if it is longer than 80 chars, because it makes grepping for the
error string more difficult.
I agree in general, however in this particular case the string is
ungreppable (it is a word now!) anyway because it's split into a few pieces.
+ return -1;
+ }
return 0;
}
Other than that:
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 6/9] memalloc: add EAL-internal API to get and set segment fd's
On 14-Sep-18 8:54 AM, Maxime Coquelin wrote:
On 09/04/2018 05:15 PM, Anatoly Burakov wrote:
Enable setting and retrieving segment fd's internally.
For now, retrieving fd's will not be used anywhere until we
get an external API, but it will be useful for things like
virtio, where we wish to share segment fd's.
Setting segment fd's will not be available as a public API
at this time, but internally it is needed for legacy mode,
because we're not allocating our hugepages in memalloc in
legacy mode case, and we still need to store the fd.
Another user of get segment fd API is memseg info dump, to
show which pages use which fd's.
Not supported on FreeBSD.
Signed-off-by: Anatoly Burakov
---
lib/librte_eal/bsdapp/eal/eal_memalloc.c | 12 +
lib/librte_eal/common/eal_common_memory.c | 8 +--
lib/librte_eal/common/eal_memalloc.h | 6 +++
lib/librte_eal/linuxapp/eal/eal_memalloc.c | 60 +-
lib/librte_eal/linuxapp/eal/eal_memory.c | 44 +---
5 files changed, 109 insertions(+), 21 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_memalloc.c
b/lib/librte_eal/bsdapp/eal/eal_memalloc.c
index f7f07abd6..a5fb09f71 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memalloc.c
@@ -47,6 +47,18 @@ eal_memalloc_sync_with_primary(void)
return -1;
}
+int
+eal_memalloc_get_seg_fd(int list_idx, int seg_idx)
+{
+ return -1;
Why not returning -ENOTSUPP directly here? (see patch 7).
+}
+
+int
+eal_memalloc_set_seg_fd(int list_idx, int seg_idx, int fd)
+{
+ return -1;
Ditto.
+}
+
Other than that, the patch looks good to me.
Maxime
Mainly for consistency reasons. Returning errno values but not using
them looks weird to me, but i can change this to return those at the outset.
--
Thanks,
Anatoly
[dpdk-dev] Warnings when building the doc on Ubuntu 18.04
Hello, I tried to build the documentation but it looks like the instructions about how to build it are not up to date. Currently running Ubuntu 18.04, it might be the reason. marchand@gribouille:~/git/dpdk$ make doc [...] lookup cache used 16122/65536 hits=132815 misses=16618 finished... sphinx processing guides-html... sphinx processing guides-pdf-faq... /home/marchand/git/dpdk/doc/guides/faq/faq.rst:7: WARNING: undefined label: linux_gsg (if the link has no caption the label must precede a section header) /home/marchand/git/dpdk/doc/guides/faq/faq.rst:25: WARNING: undefined label: linux_gsg (if the link has no caption the label must precede a section header) /home/marchand/git/dpdk/doc/guides/faq/faq.rst:190: WARNING: undefined label: multi_process_app (if the link has no caption the label must precede a section header) pdflatex processing guides-pdf-faq... make[2]: latexmk: Command not found Makefile:33: recipe for target 'doc.pdf' failed make[2]: *** [doc.pdf] Error 127 /home/marchand/git/dpdk/mk/rte.sdkdoc.mk:81: recipe for target 'guides-pdf-faq' failed make[1]: *** [guides-pdf-faq] Error 2 /home/marchand/git/dpdk/mk/rte.sdkroot.mk:88: recipe for target 'doc-all' failed make: *** [doc-all] Error 2 So I installed the latexmk package. Nothing in the dpdk refers to it, so it might be an external issue. After this, I still see those warnings (and actually a lot of others). The pdf generated docs have no link in them, but the html ones are fine. Is is expected ? -- David Marchand
Re: [dpdk-dev] [PATCH 00/16] Support externally allocated memory in DPDK
On 13-Sep-18 8:44 AM, Shahaf Shuler wrote: Hi Anatoly, First thanks for the patchset, it is a great enhancement. See question below. Tuesday, September 4, 2018 4:12 PM, Anatoly Burakov: Subject: [dpdk-dev] [PATCH 00/16] Support externally allocated memory in DPDK This is a proposal to enable using externally allocated memory in DPDK. In a nutshell, here is what is being done here: - Index internal malloc heaps by NUMA node index, rather than NUMA node itself (external heaps will have ID's in order of creation) - Add identifier string to malloc heap, to uniquely identify it - Each new heap will receive a unique socket ID that will be used by allocator to decide from which heap (internal or external) to allocate requested amount of memory - Allow creating named heaps and add/remove memory to/from those heaps - Allocate memseg lists at runtime, to keep track of IOVA addresses of externally allocated memory - If IOVA addresses aren't provided, use RTE_BAD_IOVA - Allow malloc and memzones to allocate from external heaps - Allow other data structures to allocate from externall heaps The responsibility to ensure memory is accessible before using it is on the shoulders of the user - there is no checking done with regards to validity of the memory (nor could there be...). That makes sense. However who should be in-charge of mapping this memory for dma access? The user or internally be the PMD when encounter the first packet or while traversing the existing mempools? Hi Shahaf, There are two ways this can be solved. The first way is to perform VFIO mapping automatically on adding/attaching memory. The second is to force user to do it manually. For now, the latter is chosen because user knows best if they intend to do DMA on that memory, but i'm open to suggestions. There is an issue with some devices and buses (i.e. bus/fslmc) bypassing EAL VFIO infrastructure and performing their own VFIO/DMA mapping magic, but solving that problem is outside the scope of this patchset. Those devices/buses should fix themselves :) When not using VFIO, it's out of our hands anyway. -- Thanks, Anatoly
[dpdk-dev] [PATCH v6] net/i40e: add interface to use latest vec path
For IA, the AVX2 vector path is only recommended to be used on later
platforms (identified by AVX512 support, like SKL etc.) This is because
performance benchmark shows downgrade when running AVX2 vector path on
early platform (BDW/HSW) in some cases. But we still observe perf gain
with some real work loading.
So this patch introduced the new devarg use-latest-supported-vec to
force the driver always selecting the latest supported vec path. Then
apps are able to take AVX2 path on early platforms. And this logic can
be re-used if we will have AVX512 vec path in future.
This patch only affects IA platforms. The selected vec path would be
like the following:
Without devarg/devarg = 0:
Machine vPMD
AVX512F AVX2
AVX2 SSE4.2
SSE4.2SSE4.2
---
v6:
* Polish the doc and commit log.
* Use rte_kvargs_process instead of directly kvlist internals.
v5:
* Simpify the rx set function.
v4:
* Polish the codes.
v3:
* Polish the doc and commit log.
v2:
* Correct the calling of the wrong function last time.
* Fix seg fault bug.
---
doc/guides/nics/i40e.rst | 8 ++
doc/guides/rel_notes/release_18_11.rst | 4 +
drivers/net/i40e/i40e_ethdev.c | 65 ++-
drivers/net/i40e/i40e_ethdev.h | 3 +
drivers/net/i40e/i40e_rxtx.c | 143 +
5 files changed, 155 insertions(+), 68 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 5d8500cef..6393baf0b 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -163,6 +163,14 @@ Runtime Config Options
Currently hot-plugging of representor ports is not supported so all required
representors must be specified on the creation of the PF.
+- ``Use latest supported vector`` (default ``disable``)
+
+ Latest supported vector path may not always get the best perf so vector path
was
+ recommended to use only on later platform. But users may want the latest
vector path
+ since it can get better perf in some real work loading cases. So ``devargs``
param
+ ``use-latest-supported-vec`` is introduced, for example::
+-w 84:00.0,use-latest-supported-vec=1
+
Driver compilation and testing
--
diff --git a/doc/guides/rel_notes/release_18_11.rst
b/doc/guides/rel_notes/release_18_11.rst
index 8c4bb5447..49fdcdfc8 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -67,6 +67,10 @@ New Features
SR-IOV option in Hyper-V and Azure. This is an alternative to the previous
vdev_netvsc, tap, and failsafe drivers combination.
+* **Added a devarg to use the latest supported vector path.**
+ A new devarg ``use-latest-supported-vec`` was introduced to allow users to
+ choose the latest vector path that the platform supported. For example, users
+ can use AVX2 vector path on BDW/HSW to get better performance.
API Changes
---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 24d73f2ff..e53ed5315 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -44,6 +44,7 @@
#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
#define ETH_I40E_SUPPORT_MULTI_DRIVER "support-multi-driver"
#define ETH_I40E_QUEUE_NUM_PER_VF_ARG "queue-num-per-vf"
+#define ETH_I40E_USE_LATEST_VEC"use-latest-supported-vec"
#define I40E_CLEAR_PXE_WAIT_MS 200
@@ -409,6 +410,7 @@ static const char *const valid_keys[] = {
ETH_I40E_FLOATING_VEB_LIST_ARG,
ETH_I40E_SUPPORT_MULTI_DRIVER,
ETH_I40E_QUEUE_NUM_PER_VF_ARG,
+ ETH_I40E_USE_LATEST_VEC,
NULL};
static const struct rte_pci_id pci_id_i40e_map[] = {
@@ -1202,6 +1204,64 @@ i40e_aq_debug_write_global_register(struct i40e_hw *hw,
return i40e_aq_debug_write_register(hw, reg_addr, reg_val, cmd_details);
}
+static int
+i40e_parse_latest_vec_handler(__rte_unused const char *key,
+ const char *value,
+ void *opaque)
+{
+ struct i40e_adapter *ad;
+ int use_latest_vec;
+
+ ad = (struct i40e_adapter *)opaque;
+
+ use_latest_vec = atoi(value);
+
+ if (use_latest_vec != 0 && use_latest_vec != 1)
+ PMD_DRV_LOG(WARNING, "Value should be 0 or 1, set it as 1!");
+
+ ad->use_latest_vec = (bool)use_latest_vec;
+
+ return 0;
+}
+
+static int
+i40e_use_latest_vec(struct rte_eth_dev *dev)
+{
+ struct i40e_adapter *ad =
+ I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
+ struct rte_kvargs *kvlist;
+ int kvargs_count;
+
+ ad->use_latest_vec = false;
+
+ if (!dev->device->devargs)
+ return 0;
+
+ kvlist = rte_kvargs_parse(dev->device->devargs->args, valid_keys);
+ if (!kvlist)
+ return -EINVAL;
+
+ kvargs_count = rte_kvargs_count(kvlist, ETH_I40E_USE_LATEST_VEC);
+ if (!kvargs_count) {
+ rte_
Re: [dpdk-dev] Warnings when building the doc on Ubuntu 18.04
17/09/2018 11:59, David Marchand: > Hello, > > I tried to build the documentation but it looks like the instructions > about how to build it are not up to date. Currently running Ubuntu > 18.04, it might be the reason. In pkg/dpdk.spec, there is this requirement (for RedHat based distro): doxygen, python-sphinx, inkscape, texlive-collection-latexextra I am not sure it is up to date though. There is also a guide listing the dependencies: doc/guides/contributing/documentation.rst Here, it is mentioned TexLive (at least TexLive-core and the extra Latex support) and # Ubuntu/Debian. sudo apt-get -y install texlive-latex-extra Is it enough? Or is there a miss? [...] > So I installed the latexmk package. > Nothing in the dpdk refers to it, so it might be an external issue. Is latexmk a dependency of texlive-latex-extra? > After this, I still see those warnings (and actually a lot of others). > The pdf generated docs have no link in them, but the html ones are fine. > Is is expected ? The warnings are about the cross-doc links. I think links are working inside a PDF but obviously not when referencing another PDF document. Do you see a different issue?
Re: [dpdk-dev] [PATCH 2/3] net/virtio-user: avoid parsing process mappings
On 10-Sep-18 4:59 AM, Tiwei Bie wrote:
On Fri, Sep 07, 2018 at 01:21:35PM +0100, Burakov, Anatoly wrote:
On 07-Sep-18 12:35 PM, Tiwei Bie wrote:
On Fri, Sep 07, 2018 at 10:39:16AM +0100, Burakov, Anatoly wrote:
On 05-Sep-18 5:28 AM, Tiwei Bie wrote:
Recently some memory APIs were introduced to allow users to
get the file descriptor and offset for each memory segment.
We can leverage those APIs to get rid of the /proc magic on
memory table preparation in vhost-user backend.
Signed-off-by: Tiwei Bie
---
- for (i = 0; i < num; ++i) {
- mr = &msg->payload.memory.regions[i];
- mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
- mr->userspace_addr = huges[i].addr;
- mr->memory_size = huges[i].size;
- mr->mmap_offset = 0;
- fds[i] = open(huges[i].path, O_RDWR);
+ if (rte_memseg_get_fd_offset_thread_unsafe(ms, &offset) < 0) {
+ PMD_DRV_LOG(ERR, "Failed to get offset, ms=%p rte_errno=%d",
+ ms, rte_errno);
+ return -1;
+ }
+
+ start_addr = (uint64_t)(uintptr_t)ms->addr;
+ end_addr = start_addr + ms->len;
+
+ for (i = 0; i < wa->region_nr; i++) {
There has to be a better way than to run this loop on every segment. Maybe
store last-used region, and only do a region look up if there's a mismatch?
Generally, in single-file segments mode, you'll get lots of segments from
one memseg list one after the other, so you will need to do a lookup once
memseg list changes, instead of on each segment.
We may have holes in one memseg list due to dynamic free.
Do you mean we just need to do rte_memseg_contig_walk()
and we can assume that fds of the contiguous memegs will
be the same?
No, i didn't mean that.
Whether or not you are in single-file segments mode, you still need to scan
each segment. However, you lose your state when you exit this function, and
thus have to look up the appropriate memory region (that matches your fd)
again, over and over. It would be good if you could store last-used memory
region somewhere, so that next time you come back into this function, if the
memseg has the same fd, you will not have to look it up.
Something like this:
struct walk_arg {
*last_used;
}
int walk_func() {
cur_region = wa->last_used; // check if it matches
if (cur->region->fd != fd) {
// fd is different - we've changed the segment
wa->last_used = cur_region
}
}
Thanks for the code. :)
So, cache last used region to not have to look it up again, because chances
are, you won't have to. That way, you will still do region lookups, but only
if you have to - not every time.
I can do it, but I'm not sure this optimization is really
necessary. Because this loop should be quite fast, as the
max number of regions permitted by vhost-user is quite
small. And actually we need to do that loop at least once
for each packet in vhost-user's dequeue and enqueue path,
i.e. the data path.
The number of regions is small, but the number of segments may be in the
thousands. Think worst case - 8K segments in the 16th region - with my
code, you will execute only 16 iterations on first segment and use "last
used" for the rest of the segments, while with your code, it'll be 8K
times 16 :)
You'll have to clarify the "for each packet" part, not sure i follow.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH 3/3] net/virtio-user: fix memory hotplug support in vhost-kernel
On 10-Sep-18 5:04 AM, Tiwei Bie wrote:
On Fri, Sep 07, 2018 at 01:24:05PM +0100, Burakov, Anatoly wrote:
On 07-Sep-18 12:37 PM, Tiwei Bie wrote:
On Fri, Sep 07, 2018 at 10:44:22AM +0100, Burakov, Anatoly wrote:
On 05-Sep-18 5:28 AM, Tiwei Bie wrote:
It's possible to have much more hugepage backed memory regions
than what vhost-kernel supports due to the memory hotplug, which
may cause problems. A better solution is to have the virtio-user
pass all the memory ranges reserved by DPDK to vhost-kernel.
Fixes: 12ecb2f63b12 ("net/virtio-user: support memory hotplug")
Cc: sta...@dpdk.org
Signed-off-by: Tiwei Bie
---
drivers/net/virtio/virtio_user/vhost_kernel.c | 38 +--
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/net/virtio/virtio_user/vhost_kernel.c
b/drivers/net/virtio/virtio_user/vhost_kernel.c
index 897fee0af..9338166d9 100644
--- a/drivers/net/virtio/virtio_user/vhost_kernel.c
+++ b/drivers/net/virtio/virtio_user/vhost_kernel.c
@@ -70,41 +70,41 @@ static uint64_t vhost_req_user_to_kernel[] = {
[VHOST_USER_SET_MEM_TABLE] = VHOST_SET_MEM_TABLE,
};
-struct walk_arg {
- struct vhost_memory_kernel *vm;
- uint32_t region_nr;
-};
static int
-add_memory_region(const struct rte_memseg_list *msl __rte_unused,
- const struct rte_memseg *ms, size_t len, void *arg)
+add_memseg_list(const struct rte_memseg_list *msl, void *arg)
{
- struct walk_arg *wa = arg;
+ struct vhost_memory_kernel *vm = arg;
struct vhost_memory_region *mr;
void *start_addr;
+ uint64_t len;
- if (wa->region_nr >= max_regions)
+ if (vm->nregions >= max_regions)
return -1;
- mr = &wa->vm->regions[wa->region_nr++];
- start_addr = ms->addr;
+ start_addr = msl->base_va;
+ len = msl->page_sz * msl->memseg_arr.len;
+
+ mr = &vm->regions[vm->nregions++];
mr->guest_phys_addr = (uint64_t)(uintptr_t)start_addr;
mr->userspace_addr = (uint64_t)(uintptr_t)start_addr;
mr->memory_size = len;
- mr->mmap_offset = 0;
+ mr->mmap_offset = 0; /* flags_padding */
+
+ PMD_DRV_LOG(DEBUG, "index=%u addr=%p len=%" PRIu64,
+ vm->nregions - 1, start_addr, len);
return 0;
}
-/* By default, vhost kernel module allows 64 regions, but DPDK allows
- * 256 segments. As a relief, below function merges those virtually
- * adjacent memsegs into one region.
+/* By default, vhost kernel module allows 64 regions, but DPDK may
+ * have much more memory regions. Below function will treat each
+ * contiguous memory space reserved by DPDK as one region.
*/
static struct vhost_memory_kernel *
prepare_vhost_memory_kernel(void)
{
struct vhost_memory_kernel *vm;
- struct walk_arg wa;
vm = malloc(sizeof(struct vhost_memory_kernel) +
max_regions *
@@ -112,20 +112,18 @@ prepare_vhost_memory_kernel(void)
if (!vm)
return NULL;
- wa.region_nr = 0;
- wa.vm = vm;
+ vm->nregions = 0;
+ vm->padding = 0;
/*
* The memory lock has already been taken by memory subsystem
* or virtio_user_start_device().
*/
- if (rte_memseg_contig_walk_thread_unsafe(add_memory_region, &wa) < 0) {
+ if (rte_memseg_list_walk_thread_unsafe(add_memseg_list, vm) < 0) {
free(vm);
return NULL;
}
- vm->nregions = wa.region_nr;
- vm->padding = 0;
return vm;
}
Doesn't that assume single file segments mode?
This is to find out the VA ranges reserved by memory subsystem.
Why does it need to assume single file segments mode?
If you are not in single-file segments mode, each individual page in a
VA-contiguous area will be behind a different fd - so it will be part of a
different region, would it not?
Above code is for vhost-kernel. Kernel doesn't need the
fds to get the access to virtio-user process's memory.
Kernel just needs to know the mappings between GPA (guest
physical address) and VA (virtio-user's virtual address).
Ah OK. Thanks for clarification!
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v3 1/4] build: include missing hypervisor files in Meson build
17/09/2018 11:01, Luca Boccassi:
> They are built by the legacy makefiles but not by Meson.
>
> Fixes: 8f40ee0734c8 ("eal/x86: get hypervisor name")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Luca Boccassi
> Acked-by: Bruce Richardson
Series applied, thanks
Re: [dpdk-dev] [PATCH v2] build: add PPC64 Meson build
10/09/2018 15:28, Bruce Richardson: > On Mon, Sep 10, 2018 at 12:32:43PM +0100, Luca Boccassi wrote: > > This has been only build-tested for now, on a native ppc64el POWER8E > > machine running Debian sid. > > > > Signed-off-by: Luca Boccassi > > --- > > v2: fix indentation, drop march_opt in ppc build file > > > LGTM > > Acked-by: Bruce Richardson Applied, thanks
Re: [dpdk-dev] [PATCH v3 3/3] doc: add cross compile part for sample applications
> -Original Message-
> From: Jerin Jacob
> Sent: Monday, September 17, 2018 5:48 PM
> To: Gavin Hu (Arm Technology China)
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> ; Steve Capper
> ; Ola Liljedahl ; nd
> ; sta...@dpdk.org
> Subject: Re: [PATCH v3 3/3] doc: add cross compile part for sample
> applications
>
> -Original Message-
> > Date: Mon, 17 Sep 2018 15:47:35 +0800
> > From: Gavin Hu
> > To: dev@dpdk.org
> > CC: gavin...@arm.com, honnappa.nagaraha...@arm.com,
> > steve.cap...@arm.com, ola.liljed...@arm.com,
> > jerin.ja...@caviumnetworks.com, n...@arm.com, sta...@dpdk.org
> > Subject: [PATCH v3 3/3] doc: add cross compile part for sample
> > applications
> > X-Mailer: git-send-email 2.11.0
> >
> > External Email
> >
> > Fixes: 7cacb05655 ("doc: add generic build instructions for sample
> > apps")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Gavin Hu
> > Reviewed-by: Honnappa Nagarahalli
> > ---
> > doc/guides/sample_app_ug/compiling.rst | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/sample_app_ug/compiling.rst
> > b/doc/guides/sample_app_ug/compiling.rst
> > index a2d75ed22..6f04743c8 100644
> > --- a/doc/guides/sample_app_ug/compiling.rst
> > +++ b/doc/guides/sample_app_ug/compiling.rst
> > @@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
> applications.
> > To compile all the sample applications
> > --
> >
> > -
> > Set the path to DPDK source code if its not set:
> >
> > .. code-block:: console
> > @@ -93,3 +92,17 @@ Build the application:
> >
> > export RTE_TARGET=build
> > make
> > +
> > +To cross compile the sample application(s)
> > +--
> > +
> > +For cross compiling the sample application(s), please append
> 'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
> > +In example of AARCH64 cross compiling:
> > +
> > +.. code-block:: console
> > +
> > +export RTE_TARGET=build
> > +export RTE_SDK=/path/to/rte_sdk
> > +make -C examples CROSS=aarch64-linux-gnu-
> > + or
> > +make CROSS=aarch64-linux-gnu-
>
> It should be make -C examples/l3fwd CROSS=aarch64-linux-gnu-, Right? as
> without giving directory it builds the SDK only.
-C examples/l3fwd can be ignored if the $(pwd) is already in there.
>
> > --
> > 2.11.0
> >
Re: [dpdk-dev] [PATCH v2] eal/bus: use RTE_IOVA_PA only if phys addresses are available
On 07-Sep-18 4:58 PM, Darek Stojaczyk wrote:
When neither RTE_IOVA_VA nor RTE_IOVA_PA was explicitly
requested, DPDK would currently fallback to the default
RTE_IOVA_PA mode and possibly encounter a failure later
on if running as a non-priviledged user. Attempting to
use RTE_IOVA_VA if no phys addresses are available may
help in this case.
Signed-off-by: Darek Stojaczyk
---
Changes since v1:
* added a missing rte_memory.h include
lib/librte_eal/common/eal_common_bus.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus.c
index 0943851cc..68c581b8a 100644
--- a/lib/librte_eal/common/eal_common_bus.c
+++ b/lib/librte_eal/common/eal_common_bus.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "eal_private.h"
@@ -236,9 +237,19 @@ rte_bus_get_iommu_class(void)
mode |= bus->get_iommu_class();
}
- if (mode != RTE_IOVA_VA) {
- /* Use default IOVA mode */
- mode = RTE_IOVA_PA;
+ if (mode == RTE_IOVA_VA)
+ return RTE_IOVA_VA;
+
+ if (mode & RTE_IOVA_PA) {
+ /* Not all buses support RTE_IOVA_VA, fallback to RTE_IOVA_PA */
+ return RTE_IOVA_PA;
+ }
+
+ if (rte_eal_using_phys_addrs()) {
+ /* Default to RTE_IOVA_PA only if it's supported */
+ return RTE_IOVA_PA;
}
- return mode;
+
+ /* Since RTE_IOVA_PA is unsupported, fallback to RTE_IOVA_VA */
+ return RTE_IOVA_VA;
}
This is a good change, however I think that this is too pessimistic. If
i don't have any devices that explictly require IOVA_PA, i should be
running in IOVA_VA mode.
This of course doesn't take hotplug into account, so a command-line
switch to force one or the other should also be available.
For example, at startup, i might have devices bound to VFIO, so IOVA_VA
mode is picked. However, even though at a time of startup none of the
devices require physical addresses, i also know that i might later
hotplug a device that requires IOVA_PA (leaving the question of hotplug
brokenness aside for now...) - currently, this scenario will not work,
as i will be forced to use IOVA_VA mode unless i happen to have a
IOVA_PA device available at startup.
Similarly, if i'm running DPDK as root but am only using virtual devices
like pcap, i should be able to force DPDK into using VA addresses [*],
yet currently i will be forced to use IOVA_PA if i don't *also* have a
few devices bound exclusively to VFIO.
[*] Do we have vdev devices that require IOVA_PA? I can't think of any...
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH v2 03/33] crypto/octeontx: add PCI probe and remove
+static struct rte_pci_driver otx_cryptodev_pmd = {
+ .id_table = pci_id_cpt_table,
+ .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+ .probe = otx_cpt_pci_probe,
+ .remove = otx_cpt_pci_remove,
+};
remove extra spaces/
Between otx_cryptodev_pmd, otx_cryptodev_drv &
RTE_INIT(otx_cpt_init_log)? Which all ones you want removed?
It looks there are 2 tabs for the elements of the above structure.. It
should be a single tab.
Re: [dpdk-dev] [PATCH v3 3/3] doc: add cross compile part for sample applications
-Original Message-
> Date: Mon, 17 Sep 2018 10:28:57 +
> From: "Gavin Hu (Arm Technology China)"
> To: Jerin Jacob
> CC: "dev@dpdk.org" , Honnappa Nagarahalli
> , Steve Capper , Ola
> Liljedahl , nd , "sta...@dpdk.org"
>
> Subject: RE: [PATCH v3 3/3] doc: add cross compile part for sample
> applications
>
> > -Original Message-
> > From: Jerin Jacob
> > Sent: Monday, September 17, 2018 5:48 PM
> > To: Gavin Hu (Arm Technology China)
> > Cc: dev@dpdk.org; Honnappa Nagarahalli
> > ; Steve Capper
> > ; Ola Liljedahl ; nd
> > ; sta...@dpdk.org
> > Subject: Re: [PATCH v3 3/3] doc: add cross compile part for sample
> > applications
> >
> > -Original Message-
> > > Date: Mon, 17 Sep 2018 15:47:35 +0800
> > > From: Gavin Hu
> > > To: dev@dpdk.org
> > > CC: gavin...@arm.com, honnappa.nagaraha...@arm.com,
> > > steve.cap...@arm.com, ola.liljed...@arm.com,
> > > jerin.ja...@caviumnetworks.com, n...@arm.com, sta...@dpdk.org
> > > Subject: [PATCH v3 3/3] doc: add cross compile part for sample
> > > applications
> > > X-Mailer: git-send-email 2.11.0
> > >
> > > External Email
> > >
> > > Fixes: 7cacb05655 ("doc: add generic build instructions for sample
> > > apps")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Gavin Hu
> > > Reviewed-by: Honnappa Nagarahalli
> > > ---
> > > doc/guides/sample_app_ug/compiling.rst | 15 ++-
> > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/doc/guides/sample_app_ug/compiling.rst
> > > b/doc/guides/sample_app_ug/compiling.rst
> > > index a2d75ed22..6f04743c8 100644
> > > --- a/doc/guides/sample_app_ug/compiling.rst
> > > +++ b/doc/guides/sample_app_ug/compiling.rst
> > > @@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
> > applications.
> > > To compile all the sample applications
> > > --
> > >
> > > -
> > > Set the path to DPDK source code if its not set:
> > >
> > > .. code-block:: console
> > > @@ -93,3 +92,17 @@ Build the application:
> > >
> > > export RTE_TARGET=build
> > > make
> > > +
> > > +To cross compile the sample application(s)
> > > +--
> > > +
> > > +For cross compiling the sample application(s), please append
> > 'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
> > > +In example of AARCH64 cross compiling:
> > > +
> > > +.. code-block:: console
> > > +
> > > +export RTE_TARGET=build
> > > +export RTE_SDK=/path/to/rte_sdk
> > > +make -C examples CROSS=aarch64-linux-gnu-
> > > + or
> > > +make CROSS=aarch64-linux-gnu-
> >
> > It should be make -C examples/l3fwd CROSS=aarch64-linux-gnu-, Right? as
> > without giving directory it builds the SDK only.
>
> -C examples/l3fwd can be ignored if the $(pwd) is already in there.
Yes. Since it mentioned as "or" it better to explicitly mentioned in it.
i.e
make -C examples CROSS=aarch64-linux-gnu-
or
cd $(pwd)/examples/
make CROSS=aarch64-linux-gnu-
or
make -C examples/ CROSS=aarch64-linux-gnu-
>
> >
> > > --
> > > 2.11.0
> > >
Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing
Hi Anoob, > > Hi Konstantin, > Please see inline. > > > This RFC introduces a new library within DPDK: librte_ipsec. > The aim is to provide DPDK native high performance library for IPsec > data-path processing. > The library is supposed to utilize existing DPDK crypto-dev and > security API to provide application with transparent IPsec processing API. > The library is concentrated on data-path protocols processing (ESP and AH), > IKE protocol(s) implementation is out of scope for that library. > Though hook/callback mechanisms will be defined to allow integrate it > with existing IKE implementations. > Due to quite complex nature of IPsec protocol suite and variety of user > requirements and usage scenarios a few API levels will be provided: > 1) Security Association (SA-level) API > Operates at SA level, provides functions to: > - initialize/teardown SA object > - process inbound/outbound ESP/AH packets associated with the given SA >(decrypt/encrypt, authenticate, check integrity, > add/remove ESP/AH related headers and data, etc.). > 2) Security Association Database (SAD) API > API to create/manage/destroy IPsec SAD. > While DPDK IPsec library plans to have its own implementation, > the intention is to keep it as independent from the other parts > of IPsec library as possible. > That is supposed to give users the ability to provide their own > implementation of the SAD compatible with the other parts of the > IPsec library. > 3) IPsec Context (CTX) API > This is supposed to be a high-level API, where each IPsec CTX is an > abstraction of 'independent copy of the IPsec stack'. > CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc. > and provides: > - de-multiplexing stream of inbound packets to particular SAs and >further IPsec related processing. > - IPsec related processing for the outbound packets. > - SA add/delete/update functionality > [Anoob]: Security Policy is an important aspect of IPsec. An IPsec > library without Security Policy API would be incomplete. For inline > protocol offload, the final SP-SA check(selector check) is the only > IPsec part being done by ipsec-secgw now. Would make sense to add that > also in the library. > > You mean here, that we need some sort of SPD implementation, correct? > [Anoob] Yes. > > Ok, I see. > Our thought was that just something based on librte_acl would be enough > here... > But if you think that a special defined SPD API (and implementation) is > needed - > we can probably discuss it along with SAD API (#2 above). > Though if you'd like to start to work on RFC for it right-away - please feel > free to do so :) > > > > > Current RFC concentrates on SA-level API only (1), > detailed discussion for 2) and 3) will be subjects for separate RFC(s). > > SA (low) level API > == > > API described below operates on SA level. > It provides functionality that allows user for given SA to process > inbound and outbound IPsec packets. > To be more specific: > - for inbound ESP/AH packets perform decryption, authentication, >integrity checking, remove ESP/AH related headers > [Anoob] Anti-replay check would also be required. > > Yep, anti-replay and ESN support is implied as part of "integrity checking". > Probably I have to be more specific here. > [Anoob] This is fine. > > > > - for outbound packets perform payload encryption, attach ICV, >update/add IP headers, add ESP/AH headers/trailers, >setup related mbuf felids (ol_flags, tx_offloads, etc.). > [Anoob] Do we have any plans to handle ESN expiry? Some means to > initiate an IKE renegotiation? I'm assuming application won't be aware > of the sequence numbers, in this case. > [Anoob] What is your plan with events like ESN expiry? IPsec spec talks about > byte and time expiry as well. > > At current moment, for SA level: > rte_ipsec_crypto_prepare()/rte_ipsec_inline_process() will set rte_errno > to special value (EOVERFLOW) to signal upper layer that limit is reached. > Upper layer can decide to start re-negotiation, or just destroy an SA. > > Future plans for IPsec Context (CTX) API (#3 above): > Introduce a special function, something like: > rte_ipsec_get_expired(rte_ipsec_ctx *ctx, rte_ipsec_sa *expired_sa[], > uint32_t num); > It would return up-to *num* of SAs for given ipsec context, that are > expired/limit reached. > Then upper layer again might decide for each SA should renegotiation be > started, > or just wipe given SA. > It would be upper layer responsibility to call this function periodically. > > > > - initialize/un-initialize given SA based on user provided parameters. > > Processed inbound/outbound packets could be grouped by user provided > flow id (opaque 64-bit number associated by user with given SA). > > SA-level API is based on top of crypto-dev/security API and relies on them > to perform actual cipher and integ
[dpdk-dev] [PATCH 01/11] bus/fslmc: upgrade mc FW APIs to 10.10.0
From: Hemant Agrawal Signed-off-by: Hemant Agrawal --- drivers/bus/fslmc/mc/dpbp.c | 10 ++ drivers/bus/fslmc/mc/dpci.c | 25 + drivers/bus/fslmc/mc/dpio.c | 9 + drivers/bus/fslmc/mc/fsl_dpbp.h | 1 + drivers/bus/fslmc/mc/fsl_dpbp_cmd.h | 16 +--- drivers/bus/fslmc/mc/fsl_dpci.h | 10 +- drivers/bus/fslmc/mc/fsl_dpci_cmd.h | 4 +++- drivers/bus/fslmc/mc/fsl_dpmng.h| 2 +- 8 files changed, 67 insertions(+), 10 deletions(-) diff --git a/drivers/bus/fslmc/mc/dpbp.c b/drivers/bus/fslmc/mc/dpbp.c index 0215d22da..d9103409c 100644 --- a/drivers/bus/fslmc/mc/dpbp.c +++ b/drivers/bus/fslmc/mc/dpbp.c @@ -248,6 +248,16 @@ int dpbp_reset(struct fsl_mc_io *mc_io, /* send command to mc*/ return mc_send_command(mc_io, &cmd); } +/** + * dpbp_get_attributes - Retrieve DPBP attributes. + * + * @mc_io: Pointer to MC portal's I/O object + * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_' + * @token: Token of DPBP object + * @attr: Returned object's attributes + * + * Return: '0' on Success; Error code otherwise. + */ int dpbp_get_attributes(struct fsl_mc_io *mc_io, uint32_t cmd_flags, uint16_t token, diff --git a/drivers/bus/fslmc/mc/dpci.c b/drivers/bus/fslmc/mc/dpci.c index ff366bfa9..ab5a123dc 100644 --- a/drivers/bus/fslmc/mc/dpci.c +++ b/drivers/bus/fslmc/mc/dpci.c @@ -265,6 +265,15 @@ int dpci_reset(struct fsl_mc_io *mc_io, return mc_send_command(mc_io, &cmd); } +/** + * dpci_get_attributes() - Retrieve DPCI attributes. + * @mc_io: Pointer to MC portal's I/O object + * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_' + * @token: Token of DPCI object + * @attr: Returned object's attributes + * + * Return: '0' on Success; Error code otherwise. + */ int dpci_get_attributes(struct fsl_mc_io *mc_io, uint32_t cmd_flags, uint16_t token, @@ -292,6 +301,19 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io, return 0; } +/** + * dpci_set_rx_queue() - Set Rx queue configuration + * @mc_io: Pointer to MC portal's I/O object + * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_' + * @token: Token of DPCI object + * @priority: Select the queue relative to number of + * priorities configured at DPCI creation; use + * DPCI_ALL_QUEUES to configure all Rx queues + * identically. + * @cfg: Rx queue configuration + * + * Return: '0' on Success; Error code otherwise. + */ int dpci_set_rx_queue(struct fsl_mc_io *mc_io, uint32_t cmd_flags, uint16_t token, @@ -314,6 +336,9 @@ int dpci_set_rx_queue(struct fsl_mc_io *mc_io, dpci_set_field(cmd_params->dest_type, DEST_TYPE, cfg->dest_cfg.dest_type); + dpci_set_field(cmd_params->dest_type, + ORDER_PRESERVATION, + cfg->order_preservation_en); /* send command to mc*/ return mc_send_command(mc_io, &cmd); diff --git a/drivers/bus/fslmc/mc/dpio.c b/drivers/bus/fslmc/mc/dpio.c index 966277cc6..a3382ed14 100644 --- a/drivers/bus/fslmc/mc/dpio.c +++ b/drivers/bus/fslmc/mc/dpio.c @@ -268,6 +268,15 @@ int dpio_reset(struct fsl_mc_io *mc_io, return mc_send_command(mc_io, &cmd); } +/** + * dpio_get_attributes() - Retrieve DPIO attributes + * @mc_io: Pointer to MC portal's I/O object + * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_' + * @token: Token of DPIO object + * @attr: Returned object's attributes + * + * Return: '0' on Success; Error code otherwise + */ int dpio_get_attributes(struct fsl_mc_io *mc_io, uint32_t cmd_flags, uint16_t token, diff --git a/drivers/bus/fslmc/mc/fsl_dpbp.h b/drivers/bus/fslmc/mc/fsl_dpbp.h index 111836261..9d405b42c 100644 --- a/drivers/bus/fslmc/mc/fsl_dpbp.h +++ b/drivers/bus/fslmc/mc/fsl_dpbp.h @@ -82,6 +82,7 @@ int dpbp_get_attributes(struct fsl_mc_io *mc_io, /** * BPSCN write will attempt to allocate into a cache (coherent write) */ +#define DPBP_NOTIF_OPT_COHERENT_WRITE 0x0001 int dpbp_get_api_version(struct fsl_mc_io *mc_io, uint32_t cmd_flags, uint16_t *major_ver, diff --git a/drivers/bus/fslmc/mc/fsl_dpbp_cmd.h b/drivers/bus/fslmc/mc/fsl_dpbp_cmd.h index 18402cedf..55c9fc9b4 100644 --- a/drivers/bus/fslmc/mc/fsl_dpbp_cmd.h +++ b/drivers/bus/fslmc/mc/fsl_dpbp_cmd.h @@ -9,13 +9,15 @@ /* DPBP Version */ #define DPBP_VER_MAJOR 3 -#define DPBP_VER_MINOR 3 +#define DPBP_VER_MINOR 4 /* Command versioning */ #define DPBP_CMD_BASE_VERSION 1 +#define DPBP_CMD_VERSION_2 2 #define DPB
[dpdk-dev] [PATCH 05/11] bus/fslmc: support memory backed portals with QBMAN 5.0
From: Nipun Gupta
Signed-off-by: Youri Querry
Signed-off-by: Roy Pledge
Signed-off-by: Nipun Gupta
---
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 180 ++---
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 4 +
drivers/bus/fslmc/qbman/include/compat.h | 3 +-
.../fslmc/qbman/include/fsl_qbman_portal.h| 31 +-
drivers/bus/fslmc/qbman/qbman_portal.c| 764 +++---
drivers/bus/fslmc/qbman/qbman_portal.h| 30 +-
drivers/bus/fslmc/qbman/qbman_sys.h | 100 ++-
drivers/bus/fslmc/qbman/qbman_sys_decl.h | 4 +
8 files changed, 867 insertions(+), 249 deletions(-)
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
index 99f70be1c..76f80b951 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
* Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
- * Copyright 2016 NXP
+ * Copyright 2016-2018 NXP
*
*/
#include
@@ -177,68 +177,6 @@ static int dpaa2_dpio_intr_init(struct dpaa2_dpio_dev
*dpio_dev)
}
#endif
-static int
-configure_dpio_qbman_swp(struct dpaa2_dpio_dev *dpio_dev)
-{
- struct qbman_swp_desc p_des;
- struct dpio_attr attr;
-
- dpio_dev->dpio = malloc(sizeof(struct fsl_mc_io));
- if (!dpio_dev->dpio) {
- DPAA2_BUS_ERR("Memory allocation failure");
- return -1;
- }
-
- dpio_dev->dpio->regs = dpio_dev->mc_portal;
- if (dpio_open(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->hw_id,
- &dpio_dev->token)) {
- DPAA2_BUS_ERR("Failed to allocate IO space");
- free(dpio_dev->dpio);
- return -1;
- }
-
- if (dpio_reset(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token)) {
- DPAA2_BUS_ERR("Failed to reset dpio");
- dpio_close(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token);
- free(dpio_dev->dpio);
- return -1;
- }
-
- if (dpio_enable(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token)) {
- DPAA2_BUS_ERR("Failed to Enable dpio");
- dpio_close(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token);
- free(dpio_dev->dpio);
- return -1;
- }
-
- if (dpio_get_attributes(dpio_dev->dpio, CMD_PRI_LOW,
- dpio_dev->token, &attr)) {
- DPAA2_BUS_ERR("DPIO Get attribute failed");
- dpio_disable(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token);
- dpio_close(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token);
- free(dpio_dev->dpio);
- return -1;
- }
-
- /* Configure & setup SW portal */
- p_des.block = NULL;
- p_des.idx = attr.qbman_portal_id;
- p_des.cena_bar = (void *)(dpio_dev->qbman_portal_ce_paddr);
- p_des.cinh_bar = (void *)(dpio_dev->qbman_portal_ci_paddr);
- p_des.irq = -1;
- p_des.qman_version = attr.qbman_version;
-
- dpio_dev->sw_portal = qbman_swp_init(&p_des);
- if (dpio_dev->sw_portal == NULL) {
- DPAA2_BUS_ERR("QBMan SW Portal Init failed");
- dpio_close(dpio_dev->dpio, CMD_PRI_LOW, dpio_dev->token);
- free(dpio_dev->dpio);
- return -1;
- }
-
- return 0;
-}
-
static int
dpaa2_configure_stashing(struct dpaa2_dpio_dev *dpio_dev, int cpu_id)
{
@@ -402,15 +340,17 @@ dpaa2_create_dpio_device(int vdev_fd,
struct vfio_device_info *obj_info,
int object_id)
{
- struct dpaa2_dpio_dev *dpio_dev;
+ struct dpaa2_dpio_dev *dpio_dev = NULL;
struct vfio_region_info reg_info = { .argsz = sizeof(reg_info)};
+ struct qbman_swp_desc p_des;
+ struct dpio_attr attr;
if (obj_info->num_regions < NUM_DPIO_REGIONS) {
DPAA2_BUS_ERR("Not sufficient number of DPIO regions");
return -1;
}
- dpio_dev = rte_malloc(NULL, sizeof(struct dpaa2_dpio_dev),
+ dpio_dev = rte_zmalloc(NULL, sizeof(struct dpaa2_dpio_dev),
RTE_CACHE_LINE_SIZE);
if (!dpio_dev) {
DPAA2_BUS_ERR("Memory allocation failed for DPIO Device");
@@ -423,45 +363,33 @@ dpaa2_create_dpio_device(int vdev_fd,
/* Using single portal for all devices */
dpio_dev->mc_portal = rte_mcp_ptr_list[MC_PORTAL_INDEX];
- reg_info.index = 0;
- if (ioctl(vdev_fd, VFIO_DEVICE_GET_REGION_INFO, ®_info)) {
- DPAA2_BUS_ERR("vfio: error getting region info");
- rte_free(dpio_dev);
- return -1;
+ dpio_dev->dpio = malloc(sizeof(struct fsl_mc_io));
+ if (!dpio_dev->dpio) {
+ DPAA2_BUS_ERR("Memory allocation failure");
+ goto err;
}
- dpio_dev->ce_size = reg_info.size;
-
[dpdk-dev] [PATCH 00/11] Upgrade DPAA2 FW and other feature/bug fixes
About the series: This series of patches upgrades the DPAA2 driver firmware to v10.10.10 (MC Firmware). As the bus/fslmc is modified, it is a dependent object for other drivers like net/crypto/qdma. Also, the changes are mostly tightly linked - thus, the patches include upgrade as well as sequential changes to driver. Once done, it would imply that DPAA2 driver won't with any MC FW lower than 10.10.10. Support for this new firmware is available in publically available LSDK (Layerscape SDK) release [1]. Besides the FW change, there are other subtle changes as well: - Support reading the MAC address from NIC device, rather than using a default MAC - Adding support for QBMan 5.0 FW APIs - Some patches for NXP's LX2 platform specific features - And some bug fixes. Dependency: * These patches are based on net-next/master 58c3b609699a8c * Series [1] is logically related to this, but has no git/patch related dependency. It is series for upgrade of DPAA. [1] https://lsdk.github.io/index.html [2] http://patches.dpdk.org/project/dpdk/list/?series=1090&state=* Hemant Agrawal (5): bus/fslmc: upgrade mc FW APIs to 10.10.0 bus/fslmc: upgrade qdma mc FW APIs to 10.10.0 net/dpaa2: upgrade dpni to mc FW APIs to 10.10.0 crypto/dpaa2_sec: upgarde mc FW APIs to 10.10.0 net/dpaa2: fix VLAN filter enablement Nipun Gupta (4): bus/fslmc: support memory backed portals with QBMAN 5.0 bus/fslmc: support 32 enq and deq for LX2 platform bus/fslmc: disable annotation prefetch for LX2 net/dpaa2: fix IOVA conversion for congestion memory Shreyansh Jain (2): net/dpaa2: read hardware provided MAC for DPNI devices net/dpaa2: add per queue stats get and reset support drivers/bus/fslmc/mc/dpbp.c | 10 + drivers/bus/fslmc/mc/dpci.c | 25 + drivers/bus/fslmc/mc/dpdmai.c | 14 + drivers/bus/fslmc/mc/dpio.c | 9 + drivers/bus/fslmc/mc/fsl_dpbp.h | 1 + drivers/bus/fslmc/mc/fsl_dpbp_cmd.h | 16 +- drivers/bus/fslmc/mc/fsl_dpci.h | 10 +- drivers/bus/fslmc/mc/fsl_dpci_cmd.h | 4 +- drivers/bus/fslmc/mc/fsl_dpdmai.h | 5 + drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h | 21 +- drivers/bus/fslmc/mc/fsl_dpmng.h | 2 +- drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 197 +++-- drivers/bus/fslmc/portal/dpaa2_hw_dpio.h | 4 + drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 26 +- drivers/bus/fslmc/qbman/include/compat.h | 3 +- .../fslmc/qbman/include/fsl_qbman_portal.h| 31 +- drivers/bus/fslmc/qbman/qbman_portal.c| 764 +++--- drivers/bus/fslmc/qbman/qbman_portal.h| 30 +- drivers/bus/fslmc/qbman/qbman_sys.h | 100 ++- drivers/bus/fslmc/qbman/qbman_sys_decl.h | 4 + drivers/bus/fslmc/rte_bus_fslmc_version.map | 8 + drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 7 +- drivers/crypto/dpaa2_sec/mc/dpseci.c | 30 +- drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h | 10 +- drivers/crypto/dpaa2_sec/mc/fsl_dpseci_cmd.h | 13 +- drivers/event/dpaa2/dpaa2_eventdev.c | 4 +- drivers/net/dpaa2/dpaa2_ethdev.c | 138 +++- drivers/net/dpaa2/dpaa2_rxtx.c| 18 +- drivers/net/dpaa2/mc/dpni.c | 22 +- drivers/net/dpaa2/mc/fsl_dpni.h | 343 drivers/net/dpaa2/mc/fsl_dpni_cmd.h | 17 +- drivers/net/dpaa2/mc/fsl_net.h| 2 +- drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 14 +- drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 6 +- 34 files changed, 1420 insertions(+), 488 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH 02/11] bus/fslmc: upgrade qdma mc FW APIs to 10.10.0
From: Hemant Agrawal
Signed-off-by: Hemant Agrawal
---
drivers/bus/fslmc/mc/dpdmai.c | 14 ++
drivers/bus/fslmc/mc/fsl_dpdmai.h | 5 +
drivers/bus/fslmc/mc/fsl_dpdmai_cmd.h | 21 +
drivers/raw/dpaa2_qdma/dpaa2_qdma.c | 14 +++---
drivers/raw/dpaa2_qdma/dpaa2_qdma.h | 6 --
5 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/bus/fslmc/mc/dpdmai.c b/drivers/bus/fslmc/mc/dpdmai.c
index 528889df3..dcb9d516a 100644
--- a/drivers/bus/fslmc/mc/dpdmai.c
+++ b/drivers/bus/fslmc/mc/dpdmai.c
@@ -113,6 +113,7 @@ int dpdmai_create(struct fsl_mc_io *mc_io,
cmd_flags,
dprc_token);
cmd_params = (struct dpdmai_cmd_create *)cmd.params;
+ cmd_params->num_queues = cfg->num_queues;
cmd_params->priorities[0] = cfg->priorities[0];
cmd_params->priorities[1] = cfg->priorities[1];
@@ -297,6 +298,7 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io,
rsp_params = (struct dpdmai_rsp_get_attr *)cmd.params;
attr->id = le32_to_cpu(rsp_params->id);
attr->num_of_priorities = rsp_params->num_of_priorities;
+ attr->num_of_queues = rsp_params->num_of_queues;
return 0;
}
@@ -306,6 +308,8 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io,
* @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
+ * @queue_idx: Rx queue index. Accepted values are form 0 to num_queues
+ * parameter provided in dpdmai_create
* @priority: Select the queue relative to number of
* priorities configured at DPDMAI creation; use
* DPDMAI_ALL_QUEUES to configure all Rx queues
@@ -317,6 +321,7 @@ int dpdmai_get_attributes(struct fsl_mc_io *mc_io,
int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
uint16_t token,
+ uint8_t queue_idx,
uint8_t priority,
const struct dpdmai_rx_queue_cfg *cfg)
{
@@ -331,6 +336,7 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io,
cmd_params->dest_id = cpu_to_le32(cfg->dest_cfg.dest_id);
cmd_params->dest_priority = cfg->dest_cfg.priority;
cmd_params->priority = priority;
+ cmd_params->queue_idx = queue_idx;
cmd_params->user_ctx = cpu_to_le64(cfg->user_ctx);
cmd_params->options = cpu_to_le32(cfg->options);
dpdmai_set_field(cmd_params->dest_type,
@@ -346,6 +352,8 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io,
* @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
+ * @queue_idx: Rx queue index. Accepted values are form 0 to num_queues
+ * parameter provided in dpdmai_create
* @priority: Select the queue relative to number of
* priorities configured at DPDMAI creation
* @attr: Returned Rx queue attributes
@@ -355,6 +363,7 @@ int dpdmai_set_rx_queue(struct fsl_mc_io *mc_io,
int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
uint16_t token,
+ uint8_t queue_idx,
uint8_t priority,
struct dpdmai_rx_queue_attr *attr)
{
@@ -369,6 +378,7 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io,
token);
cmd_params = (struct dpdmai_cmd_get_queue *)cmd.params;
cmd_params->priority = priority;
+ cmd_params->queue_idx = queue_idx;
/* send command to mc*/
err = mc_send_command(mc_io, &cmd);
@@ -392,6 +402,8 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io,
* @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
+ * @queue_idx: Tx queue index. Accepted values are form 0 to num_queues
+ * parameter provided in dpdmai_create
* @priority: Select the queue relative to number of
* priorities configured at DPDMAI creation
* @attr: Returned Tx queue attributes
@@ -401,6 +413,7 @@ int dpdmai_get_rx_queue(struct fsl_mc_io *mc_io,
int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
uint16_t token,
+ uint8_t queue_idx,
uint8_t priority,
struct dpdmai_tx_queue_attr *attr)
{
@@ -415,6 +428,7 @@ int dpdmai_get_tx_queue(struct fsl_mc_io *mc_io,
token);
cmd_params = (struct dpdmai_cmd_get_queue *)cmd.params;
cmd_params->priority = priority;
+ cmd_params->queue_idx = queue_idx;
/* send command to mc*/
err = mc_send_comman
[dpdk-dev] [PATCH 03/11] net/dpaa2: upgrade dpni to mc FW APIs to 10.10.0
From: Hemant Agrawal
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa2/dpaa2_ethdev.c| 21 +-
drivers/net/dpaa2/mc/dpni.c | 22 +-
drivers/net/dpaa2/mc/fsl_dpni.h | 343 +++-
drivers/net/dpaa2/mc/fsl_dpni_cmd.h | 17 +-
drivers/net/dpaa2/mc/fsl_net.h | 2 +-
5 files changed, 229 insertions(+), 176 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 8d3d54bfe..7ae74c65d 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -219,6 +219,7 @@ dpaa2_alloc_rx_tx_queues(struct rte_eth_dev *dev)
struct dpaa2_dev_priv *priv = dev->data->dev_private;
uint16_t dist_idx;
uint32_t vq_id;
+ uint8_t num_rxqueue_per_tc;
struct dpaa2_queue *mc_q, *mcq;
uint32_t tot_queues;
int i;
@@ -226,6 +227,7 @@ dpaa2_alloc_rx_tx_queues(struct rte_eth_dev *dev)
PMD_INIT_FUNC_TRACE();
+ num_rxqueue_per_tc = (priv->nb_rx_queues / priv->num_rx_tc);
tot_queues = priv->nb_rx_queues + priv->nb_tx_queues;
mc_q = rte_malloc(NULL, sizeof(struct dpaa2_queue) * tot_queues,
RTE_CACHE_LINE_SIZE);
@@ -264,8 +266,8 @@ dpaa2_alloc_rx_tx_queues(struct rte_eth_dev *dev)
vq_id = 0;
for (dist_idx = 0; dist_idx < priv->nb_rx_queues; dist_idx++) {
mcq = (struct dpaa2_queue *)priv->rx_vq[vq_id];
- mcq->tc_index = DPAA2_DEF_TC;
- mcq->flow_id = dist_idx;
+ mcq->tc_index = dist_idx / num_rxqueue_per_tc;
+ mcq->flow_id = dist_idx % num_rxqueue_per_tc;
vq_id++;
}
@@ -428,7 +430,7 @@ dpaa2_dev_rx_queue_setup(struct rte_eth_dev *dev,
struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
struct dpaa2_queue *dpaa2_q;
struct dpni_queue cfg;
- uint8_t options = 0;
+ uint8_t options = 0, num_rxqueue_per_tc;
uint8_t flow_id;
uint32_t bpid;
int ret;
@@ -448,8 +450,10 @@ dpaa2_dev_rx_queue_setup(struct rte_eth_dev *dev,
dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[rx_queue_id];
dpaa2_q->mb_pool = mb_pool; /**< mbuf pool to populate RX ring. */
+ num_rxqueue_per_tc = (priv->nb_rx_queues / priv->num_rx_tc);
+
/*Get the flow id from given VQ id*/
- flow_id = rx_queue_id % priv->nb_rx_queues;
+ flow_id = rx_queue_id % num_rxqueue_per_tc;
memset(&cfg, 0, sizeof(struct dpni_queue));
options = options | DPNI_QUEUE_OPT_USER_CTX;
@@ -1793,7 +1797,7 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
struct dpni_attr attr;
struct dpaa2_dev_priv *priv = eth_dev->data->dev_private;
struct dpni_buffer_layout layout;
- int ret, hw_id;
+ int ret, hw_id, i;
PMD_INIT_FUNC_TRACE();
@@ -1839,11 +1843,8 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
priv->num_rx_tc = attr.num_rx_tcs;
- /* Resetting the "num_rx_queues" to equal number of queues in first TC
-* as only one TC is supported on Rx Side. Once Multiple TCs will be
-* in use for Rx processing then this will be changed or removed.
-*/
- priv->nb_rx_queues = attr.num_queues;
+ for (i = 0; i < attr.num_rx_tcs; i++)
+ priv->nb_rx_queues += attr.num_queues;
/* Using number of TX queues as number of TX TCs */
priv->nb_tx_queues = attr.num_tx_tcs;
diff --git a/drivers/net/dpaa2/mc/dpni.c b/drivers/net/dpaa2/mc/dpni.c
index 9f228169a..6f5393f26 100644
--- a/drivers/net/dpaa2/mc/dpni.c
+++ b/drivers/net/dpaa2/mc/dpni.c
@@ -121,6 +121,7 @@ int dpni_create(struct fsl_mc_io *mc_io,
cmd_params->num_queues = cfg->num_queues;
cmd_params->num_tcs = cfg->num_tcs;
cmd_params->mac_filter_entries = cfg->mac_filter_entries;
+ cmd_params->num_rx_tcs = cfg->num_rx_tcs;
cmd_params->vlan_filter_entries = cfg->vlan_filter_entries;
cmd_params->qos_entries = cfg->qos_entries;
cmd_params->fs_entries = cpu_to_le16(cfg->fs_entries);
@@ -664,9 +665,14 @@ int dpni_get_buffer_layout(struct fsl_mc_io *mc_io,
/* retrieve response parameters */
rsp_params = (struct dpni_rsp_get_buffer_layout *)cmd.params;
- layout->pass_timestamp = dpni_get_field(rsp_params->flags, PASS_TS);
- layout->pass_parser_result = dpni_get_field(rsp_params->flags, PASS_PR);
- layout->pass_frame_status = dpni_get_field(rsp_params->flags, PASS_FS);
+ layout->pass_timestamp =
+ (int)dpni_get_field(rsp_params->flags, PASS_TS);
+ layout->pass_parser_result =
+ (int)dpni_get_field(rsp_params->flags, PASS_PR);
+ layout->pass_frame_status =
+ (int)dpni_get_field(rsp_params->flags, PASS_FS);
+ layout->pass_sw_opaque =
+ (int)dpni_get_field(rsp_params->flags, PASS_SWO);
[dpdk-dev] [PATCH 06/11] bus/fslmc: support 32 enq and deq for LX2 platform
From: Nipun Gupta
Signed-off-by: Nipun Gupta
---
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c| 17 ++--
drivers/bus/fslmc/portal/dpaa2_hw_dpio.h| 4
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 22 -
drivers/bus/fslmc/rte_bus_fslmc_version.map | 8
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 7 ---
drivers/event/dpaa2/dpaa2_eventdev.c| 4 ++--
drivers/net/dpaa2/dpaa2_rxtx.c | 8
7 files changed, 54 insertions(+), 16 deletions(-)
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
index 76f80b951..ce0699842 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.c
@@ -53,6 +53,11 @@ static uint32_t io_space_count;
/* Variable to store DPAA2 platform type */
uint32_t dpaa2_svr_family;
+/* Variable to store DPAA2 DQRR size */
+uint8_t dpaa2_dqrr_size;
+/* Variable to store DPAA2 EQCR size */
+uint8_t dpaa2_eqcr_size;
+
/*Stashing Macros default for LS208x*/
static int dpaa2_core_cluster_base = 0x04;
static int dpaa2_cluster_sz = 2;
@@ -125,7 +130,7 @@ static void
dpaa2_affine_dpio_intr_to_respective_core(int32_t dpio_id)
cpu_mask, token);
ret = system(command);
if (ret < 0)
- DPAA2_BUS_WARN(
+ DPAA2_BUS_DEBUG(
"Failed to affine interrupts on respective core");
else
DPAA2_BUS_DEBUG(" %s command is executed", command);
@@ -409,6 +414,14 @@ dpaa2_create_dpio_device(int vdev_fd,
DPAA2_BUS_DEBUG("LX2160 Platform Detected");
}
dpaa2_svr_family = (mc_plat_info.svr & 0x);
+
+ if (dpaa2_svr_family == SVR_LX2160A) {
+ dpaa2_dqrr_size = DPAA2_LX2_DQRR_RING_SIZE;
+ dpaa2_eqcr_size = DPAA2_LX2_EQCR_RING_SIZE;
+ } else {
+ dpaa2_dqrr_size = DPAA2_DQRR_RING_SIZE;
+ dpaa2_eqcr_size = DPAA2_EQCR_RING_SIZE;
+ }
}
if (dpaa2_svr_family == SVR_LX2160A)
@@ -492,7 +505,7 @@ dpaa2_alloc_dq_storage(struct queue_storage_info_t
*q_storage)
for (i = 0; i < NUM_DQS_PER_QUEUE; i++) {
q_storage->dq_storage[i] = rte_malloc(NULL,
- DPAA2_DQRR_RING_SIZE * sizeof(struct qbman_result),
+ dpaa2_dqrr_size * sizeof(struct qbman_result),
RTE_CACHE_LINE_SIZE);
if (!q_storage->dq_storage[i])
goto fail;
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.h
b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.h
index d593eea74..462501a2e 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_dpio.h
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_dpio.h
@@ -30,6 +30,10 @@ RTE_DECLARE_PER_LCORE(struct dpaa2_io_portal_t, _dpaa2_io);
/* Variable to store DPAA2 platform type */
extern uint32_t dpaa2_svr_family;
+/* Variable to store DPAA2 DQRR size */
+extern uint8_t dpaa2_dqrr_size;
+/* Variable to store DPAA2 EQCR size */
+extern uint8_t dpaa2_eqcr_size;
extern struct dpaa2_io_portal_t dpaa2_io_portal[RTE_MAX_LCORE];
diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
index f2eebe65d..ec8f42806 100644
--- a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
+++ b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
* Copyright (c) 2016 Freescale Semiconductor, Inc. All rights reserved.
- * Copyright 2016 NXP
+ * Copyright 2016-2018 NXP
*
*/
@@ -31,11 +31,23 @@
#define VLAN_TAG_SIZE 4 /** < Vlan Header Length */
#endif
-#define MAX_TX_RING_SLOTS 8
- /** > 3) = 8 for LS2/LS2 */
+#define DPAA2_EQCR_SHIFT 3
+/* EQCR shift to get EQCR size for LX2 (2 >> 5) = 32 for LX2 */
+#define DPAA2_LX2_EQCR_SHIFT 5
#define DPAA2_SWP_CENA_REGION 0
#define DPAA2_SWP_CINH_REGION 1
diff --git a/drivers/bus/fslmc/rte_bus_fslmc_version.map
b/drivers/bus/fslmc/rte_bus_fslmc_version.map
index b4a881704..a9cd80ad0 100644
--- a/drivers/bus/fslmc/rte_bus_fslmc_version.map
+++ b/drivers/bus/fslmc/rte_bus_fslmc_version.map
@@ -117,3 +117,11 @@ DPDK_18.05 {
rte_dpaa2_memsegs;
} DPDK_18.02;
+
+DPDK_18.11 {
+ global:
+
+ dpaa2_dqrr_size;
+ dpaa2_eqcr_size;
+
+} DPDK_18.05;
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 2a3c61c66..2bfe2514f 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -1172,7 +1172,8 @@ dpaa2_sec_enqueue_burst(void *qp, struct rte_crypto_op
**ops,
swp = DPAA2_PER_LCORE_PORTAL;
while (nb_ops) {
- frames_to_send = (nb_ops >> 3) ? MAX_TX_RING_SLOTS : nb_ops;
+ frames_to_send = (nb_ops > dpaa2_eqcr_
[dpdk-dev] [PATCH 04/11] crypto/dpaa2_sec: upgarde mc FW APIs to 10.10.0
From: Hemant Agrawal
Signed-off-by: Hemant Agrawal
---
drivers/crypto/dpaa2_sec/mc/dpseci.c | 30 ++--
drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h | 10 +--
drivers/crypto/dpaa2_sec/mc/fsl_dpseci_cmd.h | 13 +++--
3 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/dpaa2_sec/mc/dpseci.c
b/drivers/crypto/dpaa2_sec/mc/dpseci.c
index de8ca970c..778dc37f7 100644
--- a/drivers/crypto/dpaa2_sec/mc/dpseci.c
+++ b/drivers/crypto/dpaa2_sec/mc/dpseci.c
@@ -116,11 +116,13 @@ int dpseci_create(struct fsl_mc_io *mc_io,
cmd_flags,
dprc_token);
cmd_params = (struct dpseci_cmd_create *)cmd.params;
- for (i = 0; i < DPSECI_PRIO_NUM; i++)
+ for (i = 0; i < 8; i++)
cmd_params->priorities[i] = cfg->priorities[i];
+ for (i = 0; i < 8; i++)
+ cmd_params->priorities2[i] = cfg->priorities[8 + i];
cmd_params->num_tx_queues = cfg->num_tx_queues;
cmd_params->num_rx_queues = cfg->num_rx_queues;
- cmd_params->options = cfg->options;
+ cmd_params->options = cpu_to_le32(cfg->options);
/* send command to mc*/
err = mc_send_command(mc_io, &cmd);
@@ -302,7 +304,7 @@ int dpseci_get_attributes(struct fsl_mc_io *mc_io,
/* retrieve response parameters */
rsp_params = (struct dpseci_rsp_get_attr *)cmd.params;
attr->id = le32_to_cpu(rsp_params->id);
- attr->options = rsp_params->options;
+ attr->options = le32_to_cpu(rsp_params->options);
attr->num_tx_queues = rsp_params->num_tx_queues;
attr->num_rx_queues = rsp_params->num_rx_queues;
@@ -490,6 +492,8 @@ int dpseci_get_sec_attr(struct fsl_mc_io *mc_io,
attr->arc4_acc_num = rsp_params->arc4_acc_num;
attr->des_acc_num = rsp_params->des_acc_num;
attr->aes_acc_num = rsp_params->aes_acc_num;
+ attr->ccha_acc_num = rsp_params->ccha_acc_num;
+ attr->ptha_acc_num = rsp_params->ptha_acc_num;
return 0;
}
@@ -569,6 +573,16 @@ int dpseci_get_api_version(struct fsl_mc_io *mc_io,
return 0;
}
+/**
+ * dpseci_set_congestion_notification() - Set congestion group
+ * notification configuration
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSECI object
+ * @cfg: congestion notification configuration
+ *
+ * Return: '0' on success, error code otherwise
+ */
int dpseci_set_congestion_notification(
struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
@@ -604,6 +618,16 @@ int dpseci_set_congestion_notification(
return mc_send_command(mc_io, &cmd);
}
+/**
+ * dpseci_get_congestion_notification() - Get congestion group
+ * notification configuration
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSECI object
+ * @cfg: congestion notification configuration
+ *
+ * Return: '0' on success, error code otherwise
+ */
int dpseci_get_congestion_notification(
struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
diff --git a/drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h
b/drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h
index 12ac005ad..f4b6fe8ad 100644
--- a/drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h
+++ b/drivers/crypto/dpaa2_sec/mc/fsl_dpseci.h
@@ -20,7 +20,7 @@ struct fsl_mc_io;
/**
* Maximum number of Tx/Rx priorities per DPSECI object
*/
-#define DPSECI_PRIO_NUM8
+#define DPSECI_MAX_QUEUE_NUM 16
/**
* All queues considered; see dpseci_set_rx_queue()
@@ -58,7 +58,7 @@ struct dpseci_cfg {
uint32_t options;
uint8_t num_tx_queues;
uint8_t num_rx_queues;
- uint8_t priorities[DPSECI_PRIO_NUM];
+ uint8_t priorities[DPSECI_MAX_QUEUE_NUM];
};
int dpseci_create(struct fsl_mc_io *mc_io,
@@ -259,6 +259,10 @@ int dpseci_get_tx_queue(struct fsl_mc_io *mc_io,
* implemented in this version of SEC.
* @aes_acc_num: The number of copies of the AES module that are
* implemented in this version of SEC.
+ * @ccha_acc_num: The number of copies of the ChaCha20 module that are
+ * implemented in this version of SEC.
+ * @ptha_acc_num: The number of copies of the Poly1305 module that are
+ * implemented in this version of SEC.
**/
struct dpseci_sec_attr {
@@ -279,6 +283,8 @@ struct dpseci_sec_attr {
uint8_t arc4_acc_num;
uint8_t des_acc_num;
uint8_t aes_acc_num;
+ uint8_t ccha_acc_num;
+ uint8_t ptha_acc_num;
};
int dpseci_get_sec_attr(struct fsl_mc_io *mc_io,
diff --git a/drivers/crypto/dpaa2_sec/mc/fsl_dpseci_cmd.h
b/drivers/crypto/dpaa2_sec/mc/fsl_dpseci_cmd.h
index 26cef
[dpdk-dev] [PATCH 09/11] net/dpaa2: read hardware provided MAC for DPNI devices
Firmware would contain pre-configured devices for each DPMAC backing
a DPNI. This patch reads those MAC address when the device is
initialized and sets it. THereafter, it can be changed through API or
commands from testpmd.
Signed-off-by: Shreyansh Jain
---
drivers/net/dpaa2/dpaa2_ethdev.c | 79 +---
1 file changed, 73 insertions(+), 6 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 02cea0cd1..01b010312 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -1789,6 +1789,71 @@ static struct eth_dev_ops dpaa2_ethdev_ops = {
.rss_hash_conf_get= dpaa2_dev_rss_hash_conf_get,
};
+/* Populate the mac address from physically available (u-boot/firmware) and/or
+ * one set by higher layers like MC (restool) etc.
+ * Returns the table of MAC entries (multiple entries)
+ */
+static int
+populate_mac_addr(struct fsl_mc_io *dpni_dev, struct dpaa2_dev_priv *priv,
+ struct ether_addr *mac_entry)
+{
+ int ret;
+ struct ether_addr phy_mac = {}, prime_mac = {};
+
+ /* Get the physical device MAC address */
+ ret = dpni_get_port_mac_addr(dpni_dev, CMD_PRI_LOW, priv->token,
+phy_mac.addr_bytes);
+ if (ret) {
+ DPAA2_PMD_ERR("DPNI get physical port MAC failed: %d", ret);
+ goto cleanup;
+ }
+
+ ret = dpni_get_primary_mac_addr(dpni_dev, CMD_PRI_LOW, priv->token,
+ prime_mac.addr_bytes);
+ if (ret) {
+ DPAA2_PMD_ERR("DPNI get Prime port MAC failed: %d", ret);
+ goto cleanup;
+ }
+
+ /* Now that both MAC have been obtained, do:
+* if not_empty_mac(phy) && phy != Prime, overwrite prime with Phy
+* and return phy
+* If empty_mac(phy), return prime.
+* if both are empty, create random MAC, set as prime and return
+*/
+ if (!is_zero_ether_addr(&phy_mac)) {
+ /* If the addresses are not same, overwrite prime */
+ if (!is_same_ether_addr(&phy_mac, &prime_mac)) {
+ ret = dpni_set_primary_mac_addr(dpni_dev, CMD_PRI_LOW,
+ priv->token,
+ phy_mac.addr_bytes);
+ if (ret) {
+ DPAA2_PMD_ERR("Unable to set MAC Address: %d",
+ ret);
+ goto cleanup;
+ }
+ memcpy(&prime_mac, &phy_mac, sizeof(struct ether_addr));
+ }
+ } else if (is_zero_ether_addr(&prime_mac)) {
+ /* In case phys and prime, both are zero, create random MAC */
+ eth_random_addr(prime_mac.addr_bytes);
+ ret = dpni_set_primary_mac_addr(dpni_dev, CMD_PRI_LOW,
+ priv->token,
+ prime_mac.addr_bytes);
+ if (ret) {
+ DPAA2_PMD_ERR("Unable to set MAC Address: %d", ret);
+ goto cleanup;
+ }
+ }
+
+ /* prime_mac the final MAC address */
+ memcpy(mac_entry, &prime_mac, sizeof(struct ether_addr));
+ return 0;
+
+cleanup:
+ return -1;
+}
+
static int
dpaa2_dev_init(struct rte_eth_dev *eth_dev)
{
@@ -1868,7 +1933,10 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
goto init_err;
}
- /* Allocate memory for storing MAC addresses */
+ /* Allocate memory for storing MAC addresses.
+* Table of mac_filter_entries size is allocated so that RTE ether lib
+* can add MAC entries when rte_eth_dev_mac_addr_add is called.
+*/
eth_dev->data->mac_addrs = rte_zmalloc("dpni",
ETHER_ADDR_LEN * attr.mac_filter_entries, 0);
if (eth_dev->data->mac_addrs == NULL) {
@@ -1879,12 +1947,11 @@ dpaa2_dev_init(struct rte_eth_dev *eth_dev)
goto init_err;
}
- ret = dpni_get_primary_mac_addr(dpni_dev, CMD_PRI_LOW,
- priv->token,
- (uint8_t *)(eth_dev->data->mac_addrs[0].addr_bytes));
+ ret = populate_mac_addr(dpni_dev, priv, ð_dev->data->mac_addrs[0]);
if (ret) {
- DPAA2_PMD_ERR("DPNI get mac address failed:Err Code = %d",
-ret);
+ DPAA2_PMD_ERR("Unable to fetch MAC Address for device");
+ rte_free(eth_dev->data->mac_addrs);
+ eth_dev->data->mac_addrs = NULL;
goto init_err;
}
--
2.17.1
[dpdk-dev] [PATCH 07/11] bus/fslmc: disable annotation prefetch for LX2
From: Nipun Gupta
In case of LX2 we get parse result summary in FD. We do not need to
prefetch and read the annotation to fetch the parse results.
Signed-off-by: Nipun Gupta
DPDK-1404
---
drivers/net/dpaa2/dpaa2_rxtx.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dpaa2/dpaa2_rxtx.c b/drivers/net/dpaa2/dpaa2_rxtx.c
index 89cfd2929..953fed2ad 100644
--- a/drivers/net/dpaa2/dpaa2_rxtx.c
+++ b/drivers/net/dpaa2/dpaa2_rxtx.c
@@ -554,10 +554,12 @@ dpaa2_dev_prefetch_rx(void *queue, struct rte_mbuf
**bufs, uint16_t nb_pkts)
}
fd = qbman_result_DQ_fd(dq_storage);
- next_fd = qbman_result_DQ_fd(dq_storage + 1);
- /* Prefetch Annotation address for the parse results */
- rte_prefetch0((void *)(size_t)(DPAA2_GET_FD_ADDR(next_fd)
- + DPAA2_FD_PTA_SIZE + 16));
+ if (dpaa2_svr_family != SVR_LX2160A) {
+ next_fd = qbman_result_DQ_fd(dq_storage + 1);
+ /* Prefetch Annotation address for the parse results */
+ rte_prefetch0((void *)(size_t)(DPAA2_GET_FD_ADDR(
+ next_fd) + DPAA2_FD_PTA_SIZE + 16));
+ }
if (unlikely(DPAA2_FD_GET_FORMAT(fd) == qbman_fd_sg))
bufs[num_rx] = eth_sg_fd_to_mbuf(fd);
--
2.17.1
[dpdk-dev] [PATCH 08/11] net/dpaa2: fix IOVA conversion for congestion memory
From: Nipun Gupta
Fixes: 5ae1edff6895 ("dpaa2: prepare for 32-bit build")
Cc: sta...@dpdk.org
Signed-off-by: Nipun Gupta
---
drivers/net/dpaa2/dpaa2_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 7ae74c65d..02cea0cd1 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -572,7 +572,8 @@ dpaa2_dev_tx_queue_setup(struct rte_eth_dev *dev,
*/
cong_notif_cfg.threshold_exit = CONG_EXIT_TX_THRESHOLD;
cong_notif_cfg.message_ctx = 0;
- cong_notif_cfg.message_iova = (size_t)dpaa2_q->cscn;
+ cong_notif_cfg.message_iova =
+ (size_t)DPAA2_VADDR_TO_IOVA(dpaa2_q->cscn);
cong_notif_cfg.dest_cfg.dest_type = DPNI_DEST_NONE;
cong_notif_cfg.notification_mode =
DPNI_CONG_OPT_WRITE_MEM_ON_ENTER |
--
2.17.1
[dpdk-dev] [PATCH 10/11] net/dpaa2: add per queue stats get and reset support
For now, only the packet count stats per queue is available. This is
part of xstats output (though, per queue stats are actually part of
rte_eth_stats basic stats).
Signed-off-by: Shreyansh Jain
---
drivers/net/dpaa2/dpaa2_ethdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 01b010312..1715e9f33 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -1121,6 +1121,8 @@ int dpaa2_dev_stats_get(struct rte_eth_dev *dev,
int32_t retcode;
uint8_t page0 = 0, page1 = 1, page2 = 2;
union dpni_statistics value;
+ int i;
+ struct dpaa2_queue *dpaa2_rxq, *dpaa2_txq;
memset(&value, 0, sizeof(union dpni_statistics));
@@ -1168,6 +1170,21 @@ int dpaa2_dev_stats_get(struct rte_eth_dev *dev,
stats->oerrors = value.page_2.egress_discarded_frames;
stats->imissed = value.page_2.ingress_nobuffer_discards;
+ /* Fill in per queue stats */
+ for (i = 0; (i < RTE_ETHDEV_QUEUE_STAT_CNTRS) &&
+ (i < priv->nb_rx_queues || i < priv->nb_tx_queues); ++i) {
+ dpaa2_rxq = (struct dpaa2_queue *)priv->rx_vq[i];
+ dpaa2_txq = (struct dpaa2_queue *)priv->tx_vq[i];
+ if (dpaa2_rxq)
+ stats->q_ipackets[i] = dpaa2_rxq->rx_pkts;
+ if (dpaa2_txq)
+ stats->q_opackets[i] = dpaa2_txq->tx_pkts;
+
+ /* Byte counting is not implemented */
+ stats->q_ibytes[i] = 0;
+ stats->q_obytes[i] = 0;
+ }
+
return 0;
err:
@@ -1327,6 +1344,8 @@ dpaa2_dev_stats_reset(struct rte_eth_dev *dev)
struct dpaa2_dev_priv *priv = dev->data->dev_private;
struct fsl_mc_io *dpni = (struct fsl_mc_io *)priv->hw;
int32_t retcode;
+ int i;
+ struct dpaa2_queue *dpaa2_q;
PMD_INIT_FUNC_TRACE();
@@ -1339,6 +1358,19 @@ dpaa2_dev_stats_reset(struct rte_eth_dev *dev)
if (retcode)
goto error;
+ /* Reset the per queue stats in dpaa2_queue structure */
+ for (i = 0; i < priv->nb_rx_queues; i++) {
+ dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[i];
+ if (dpaa2_q)
+ dpaa2_q->rx_pkts = 0;
+ }
+
+ for (i = 0; i < priv->nb_tx_queues; i++) {
+ dpaa2_q = (struct dpaa2_queue *)priv->tx_vq[i];
+ if (dpaa2_q)
+ dpaa2_q->tx_pkts = 0;
+ }
+
return;
error:
--
2.17.1
[dpdk-dev] [PATCH 11/11] net/dpaa2: fix VLAN filter enablement
From: Hemant Agrawal
Fixes: 0ebce6129bc6 ("net/dpaa2: support new ethdev offload APIs")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa2/dpaa2_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index 1715e9f33..d9be3377b 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -407,7 +407,8 @@ dpaa2_eth_dev_configure(struct rte_eth_dev *dev)
}
}
- dpaa2_vlan_offload_set(dev, ETH_VLAN_FILTER_MASK);
+ if (rx_offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
+ dpaa2_vlan_offload_set(dev, ETH_VLAN_FILTER_MASK);
/* update the current status */
dpaa2_dev_link_update(dev, 0);
--
2.17.1
Re: [dpdk-dev] [PATCH v2 01/33] config: add Cavium OcteonTX crypto PMD skeleton
I think it would be better to squash the makefile related changes in the 3/33 patch as the code is actually added in that and here the code is not getting compiled here. So the changes in the following files has to be moved to patch 3/33? drivers/crypto/Makefile drivers/crypto/meson.build drivers/crypto/octeontx/Makefile drivers/crypto/octeontx/meson.build mk/rte.app.mk I think this patch will just have MAINTAINER edit (even that might be required to be moved to 3/33?) & changes to config/common_base, after that. Is that fine? In my opinion, you do not need this patch as separate one. config/common_base can also be added in the 3/33. -Akhil
Re: [dpdk-dev] [PATCH v2 03/33] crypto/octeontx: add PCI probe and remove
Hi Akhil,
On 17-09-2018 16:04, Akhil Goyal wrote:
External Email
+static struct rte_pci_driver otx_cryptodev_pmd = {
+ .id_table = pci_id_cpt_table,
+ .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
+ .probe = otx_cpt_pci_probe,
+ .remove = otx_cpt_pci_remove,
+};
remove extra spaces/
Between otx_cryptodev_pmd, otx_cryptodev_drv &
RTE_INIT(otx_cpt_init_log)? Which all ones you want removed?
It looks there are 2 tabs for the elements of the above structure.. It
should be a single tab.
Understood. Will fix it in v3.
Thanks,
Anoob
Re: [dpdk-dev] [PATCH v2 05/33] common/cpt: add common code for init routine
On 9/4/2018 9:28 AM, Anoob Joseph wrote:
From: Anoob Joseph
Adding code identified common for OcteonTX family crypto devices. This
patch is adding the code required by the structures and code path of
init routine.
Signed-off-by: Ankur Dwivedi
Signed-off-by: Anoob Joseph
Signed-off-by: Murthy NSSR
Signed-off-by: Nithin Dabilpuram
Signed-off-by: Ragothaman Jayaraman
Signed-off-by: Srisivasubramanian S
Signed-off-by: Tejasree Kondoj
---
drivers/common/cpt/cpt_common.h | 54 +
1 file changed, 54 insertions(+)
create mode 100644 drivers/common/cpt/cpt_common.h
diff --git a/drivers/common/cpt/cpt_common.h b/drivers/common/cpt/cpt_common.h
new file mode 100644
index 000..feca5fe
--- /dev/null
+++ b/drivers/common/cpt/cpt_common.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Cavium, Inc
+ */
+
+#ifndef _CPT_COMMON_H_
+#define _CPT_COMMON_H_
+
+/*
+ * This file defines common macros and structs
+ */
+
+/*
+ * Macros to determine CPT model. Driver makefile will define CPT_MODEL
+ * accordingly
+ */
+#define CRYPTO_OCTEONTX0x1
+
+#define AE_TYPE 1
+#define SE_TYPE 2
+
+/* cpt instance */
+struct cpt_instance {
+ uint32_t queue_id;
+ uintptr_t rsvd;
+};
+
+struct cptvf_meta_info {
+ void *cptvf_meta_pool;
+ int cptvf_op_mlen;
+ int cptvf_op_sb_mlen;
+};
+
+struct rid {
+ uintptr_t rid;
+ /**< Request id of a crypto operation */
no need for extra tab for comments.
+};
+
+/*
+ * Pending queue structure
+ *
+ */
+struct pending_queue {
+ uint16_t enq_tail;
+ uint16_t deq_head;
+ uint16_t soft_qlen;
+ /**< Software expected queue length */
+ uint16_t p_doorbell;
+ struct rid *rid_queue;
+ /**< Array of pending requests */
+ uint64_t pending_count;
+ /**< Pending requests count */
+};
better to add comment for each element of structure.
Also remove extra tab for comments(here and any other place if any.)
+
+#endif /* _CPT_COMMON_H_ */
[dpdk-dev] [PATCH v4] doc: add cross compile part for sample applications
Fixes: 7cacb05655 ("doc: add generic build instructions for sample apps")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
---
doc/guides/sample_app_ug/compiling.rst | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/compiling.rst
b/doc/guides/sample_app_ug/compiling.rst
index a2d75ed22..f6b31fc7b 100644
--- a/doc/guides/sample_app_ug/compiling.rst
+++ b/doc/guides/sample_app_ug/compiling.rst
@@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
applications.
To compile all the sample applications
--
-
Set the path to DPDK source code if its not set:
.. code-block:: console
@@ -93,3 +92,18 @@ Build the application:
export RTE_TARGET=build
make
+
+To cross compile the sample application(s)
+--
+
+For cross compiling the sample application(s), please append
'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
+In example of AARCH64 cross compiling:
+
+.. code-block:: console
+
+export RTE_TARGET=build
+export RTE_SDK=/path/to/rte_sdk
+make -C examples CROSS=aarch64-linux-gnu-
+ or
+ cd $(pwd)/examples/
+make CROSS=aarch64-linux-gnu-
--
2.11.0
[dpdk-dev] [PATCH v5] doc: add cross compile part for sample applications
Fixes: 7cacb05655 ("doc: add generic build instructions for sample apps")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Honnappa Nagarahalli
---
doc/guides/sample_app_ug/compiling.rst | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/compiling.rst
b/doc/guides/sample_app_ug/compiling.rst
index a2d75ed22..9ff531906 100644
--- a/doc/guides/sample_app_ug/compiling.rst
+++ b/doc/guides/sample_app_ug/compiling.rst
@@ -9,7 +9,6 @@ This section explains how to compile the DPDK sample
applications.
To compile all the sample applications
--
-
Set the path to DPDK source code if its not set:
.. code-block:: console
@@ -93,3 +92,18 @@ Build the application:
export RTE_TARGET=build
make
+
+To cross compile the sample application(s)
+--
+
+For cross compiling the sample application(s), please append
'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
+In example of AARCH64 cross compiling:
+
+.. code-block:: console
+
+export RTE_TARGET=build
+export RTE_SDK=/path/to/rte_sdk
+make -C examples CROSS=aarch64-linux-gnu-
+ or
+cd $(pwd)/examples/
+make CROSS=aarch64-linux-gnu-
--
2.11.0
Re: [dpdk-dev] [PATCH v3 3/3] doc: add cross compile part for sample applications
Hi Jerin,
Thanks for review, could you help review the v5 version?
Best Regards,
Gavin
> -Original Message-
> From: Jerin Jacob
> Sent: Monday, September 17, 2018 6:35 PM
> To: Gavin Hu (Arm Technology China)
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> ; Steve Capper
> ; Ola Liljedahl ; nd
> ; sta...@dpdk.org
> Subject: Re: [PATCH v3 3/3] doc: add cross compile part for sample
> applications
>
> -Original Message-
> > Date: Mon, 17 Sep 2018 10:28:57 +
> > From: "Gavin Hu (Arm Technology China)"
> > To: Jerin Jacob
> > CC: "dev@dpdk.org" , Honnappa Nagarahalli
> > , Steve Capper
> ,
> > Ola Liljedahl , nd ,
> "sta...@dpdk.org"
> >
> > Subject: RE: [PATCH v3 3/3] doc: add cross compile part for sample
> > applications
> >
> > > -Original Message-
> > > From: Jerin Jacob
> > > Sent: Monday, September 17, 2018 5:48 PM
> > > To: Gavin Hu (Arm Technology China)
> > > Cc: dev@dpdk.org; Honnappa Nagarahalli
> > > ; Steve Capper
> ;
> > > Ola Liljedahl ; nd ;
> > > sta...@dpdk.org
> > > Subject: Re: [PATCH v3 3/3] doc: add cross compile part for sample
> > > applications
> > >
> > > -Original Message-
> > > > Date: Mon, 17 Sep 2018 15:47:35 +0800
> > > > From: Gavin Hu
> > > > To: dev@dpdk.org
> > > > CC: gavin...@arm.com, honnappa.nagaraha...@arm.com,
> > > > steve.cap...@arm.com, ola.liljed...@arm.com,
> > > > jerin.ja...@caviumnetworks.com, n...@arm.com, sta...@dpdk.org
> > > > Subject: [PATCH v3 3/3] doc: add cross compile part for sample
> > > > applications
> > > > X-Mailer: git-send-email 2.11.0
> > > >
> > > > External Email
> > > >
> > > > Fixes: 7cacb05655 ("doc: add generic build instructions for sample
> > > > apps")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Gavin Hu
> > > > Reviewed-by: Honnappa Nagarahalli
> > > > ---
> > > > doc/guides/sample_app_ug/compiling.rst | 15 ++-
> > > > 1 file changed, 14 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/doc/guides/sample_app_ug/compiling.rst
> > > > b/doc/guides/sample_app_ug/compiling.rst
> > > > index a2d75ed22..6f04743c8 100644
> > > > --- a/doc/guides/sample_app_ug/compiling.rst
> > > > +++ b/doc/guides/sample_app_ug/compiling.rst
> > > > @@ -9,7 +9,6 @@ This section explains how to compile the DPDK
> > > > sample
> > > applications.
> > > > To compile all the sample applications
> > > > --
> > > >
> > > > -
> > > > Set the path to DPDK source code if its not set:
> > > >
> > > > .. code-block:: console
> > > > @@ -93,3 +92,17 @@ Build the application:
> > > >
> > > > export RTE_TARGET=build
> > > > make
> > > > +
> > > > +To cross compile the sample application(s)
> > > > +--
> > > > +
> > > > +For cross compiling the sample application(s), please append
> > > 'CROSS=$(CROSS_COMPILER_PREFIX)' to the 'make' command.
> > > > +In example of AARCH64 cross compiling:
> > > > +
> > > > +.. code-block:: console
> > > > +
> > > > +export RTE_TARGET=build
> > > > +export RTE_SDK=/path/to/rte_sdk
> > > > +make -C examples CROSS=aarch64-linux-gnu-
> > > > + or
> > > > +make CROSS=aarch64-linux-gnu-
> > >
> > > It should be make -C examples/l3fwd CROSS=aarch64-linux-gnu-, Right?
> > > as without giving directory it builds the SDK only.
> >
> > -C examples/l3fwd can be ignored if the $(pwd) is already in there.
>
> Yes. Since it mentioned as "or" it better to explicitly mentioned in it.
>
> i.e
>
> make -C examples CROSS=aarch64-linux-gnu-
>
> or
>
> cd $(pwd)/examples/
> make CROSS=aarch64-linux-gnu-
>
> or
>
> make -C examples/ CROSS=aarch64-linux-gnu-
>
> >
> > >
> > > > --
> > > > 2.11.0
> > > >
Re: [dpdk-dev] [PATCH v3] net/i40e: add alarm handler
On 9/11/2018 4:35 AM, Beilei Xing wrote:
> This patch adds alarm handler, and then i40e
> PF will use alarm handler instead of interrupt
> handler when device is started and Rx interrupt
> mode is disabled. This way will save CPU cycles
> during receiving packets.
>
> Signed-off-by: Beilei Xing
<...>
> +static void
> +i40e_dev_alarm_handler(void *param)
> +{
> + struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
> + struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t icr0;
> +
> + /* Disable interrupt */
> + i40e_pf_disable_irq0(hw);
> +
> + /* read out interrupt causes */
> + icr0 = I40E_READ_REG(hw, I40E_PFINT_ICR0);
> +
> + /* No interrupt event indicated */
> + if (!(icr0 & I40E_PFINT_ICR0_INTEVENT_MASK)) {
> + PMD_DRV_LOG(INFO, "No interrupt event");
Hi Beilei, Qi,
This prints an "info" level log each 50ms which makes console unusable.
This patch already merged in master repo.
So can you please send another patch to remove the log?
Thanks,
ferruh
Re: [dpdk-dev] [PATCH v2 07/33] common/cpt: add hardware register defines
+typedef union cpt_res_s {
+ uint64_t u[2];
+ struct cpt_res_s_8s {
+#if (RTE_BYTE_ORDER == RTE_BIG_ENDIAN) /* Word 0 - Big Endian */
+ uint64_t reserved_17_63: 47;
+ uint64_t doneint : 1;
+ /**< [ 16: 16] Done interrupt. This bit is copied from the
+* corresponding instruction's CPT_INST_S[DONEINT].
+**/
+ uint64_t reserved_8_15 : 8;
+ uint64_t compcode : 8;
+ /**< [ 7: 0] Indicates completion/error status of the CPT
+* coprocessor for the associated instruction, as enumerated by
+* CPT_COMP_E. Core software may write the memory location
+* containing [COMPCODE] to 0x0 before ringing the doorbell, and
+* then poll for completion by checking for a nonzero value.
+
+Once the core observes a nonzero [COMPCODE] value in this case,
+the CPT coprocessor will have also completed L2/DRAM write
+operations.
+ */
commenting style shall be uniform in the file.
Half of the comments have * and half don't have. Please be consistent.
-Akhil
Re: [dpdk-dev] Warnings when building the doc on Ubuntu 18.04
On Mon, Sep 17, 2018 at 12:15 PM, Thomas Monjalon wrote: > 17/09/2018 11:59, David Marchand: >> Hello, >> >> I tried to build the documentation but it looks like the instructions >> about how to build it are not up to date. Currently running Ubuntu >> 18.04, it might be the reason. > > In pkg/dpdk.spec, there is this requirement (for RedHat based distro): > doxygen, python-sphinx, inkscape, texlive-collection-latexextra > I am not sure it is up to date though. > > There is also a guide listing the dependencies: > doc/guides/contributing/documentation.rst > Here, it is mentioned > TexLive (at least TexLive-core and the extra Latex support) > and > # Ubuntu/Debian. > sudo apt-get -y install texlive-latex-extra I followed this doc, yes. > Is it enough? Or is there a miss? I am more under the impression that there is a pb. # on a fresh Ubuntu 16.04, root@ubuntu1604:~# apt-cache rdepends latexmk latexmk Reverse Depends: latexila texlive-full texlive-full texlive-extra-utils # and on my ubuntu 18.04 marchand@gribouille:~$ apt-cache rdepends latexmk latexmk Reverse Depends: latexila texlive-full texlive-extra-utils python-sphinx python3-sphinx jupyter-sphinx-theme-doc texlive-latex-extra does not depend on latexmk. So 16.04 vs 18.04 is not the issue. Looking again at 16.04 : root@ubuntu1604:~# apt-cache depends latexila |grep latexmk Recommends: latexmk root@ubuntu1604:~# apt-cache depends texlive-full |grep latexmk Depends: latexmk root@ubuntu1604:~# apt-cache depends texlive-extra-utils |grep latexmk Suggests: latexmk So texlive-full is the only that has a hard dependency on it. >> After this, I still see those warnings (and actually a lot of others). >> The pdf generated docs have no link in them, but the html ones are fine. >> Is is expected ? > > The warnings are about the cross-doc links. > I think links are working inside a PDF but obviously not when referencing > another PDF document. > Do you see a different issue? Two types of warnings, "unknown label" and "unknown document". The "unknown label" warnings seem to be cross doc links, yes. But some unknown document warnings are odd to me. I will look at this a bit more. -- David Marchand
Re: [dpdk-dev] [PATCH] build: create relative symlinks for PMDs in libdir
13/09/2018 11:11, Bruce Richardson:
> On Wed, Sep 12, 2018 at 06:21:34PM +0100, Luca Boccassi wrote:
> > Add -r option to ln, otherwise the link will be absolute and contain
> > the build path and break packaging among other things:
> >
> > lrwxrwxrwx 1 bluca bluca 99 Sep 11 22:17 librte_mempool_dpaa.so.1.1
> > -> /home/bluca/git/dpdk/testt4//usr/local/lib/x86_64-linux-gnu/dpdk/
> > drivers/librte_mempool_dpaa.so.1.1
> >
> > With -r:
> >
> > lrwxrwxrwx 1 bluca bluca 35 Sep 12 18:13 librte_pmd_zlib.so.1.1
> > -> dpdk/drivers/librte_pmd_zlib.so.1.1
> >
> > Fixes: ed4d43d73e2b ("build: symlink drivers to library directory")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Luca Boccassi
> > ---
> > buildtools/symlink-drivers-solibs.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/buildtools/symlink-drivers-solibs.sh
> > b/buildtools/symlink-drivers-solibs.sh
> > index 803dfec491..9826c6ae37 100644
> > --- a/buildtools/symlink-drivers-solibs.sh
> > +++ b/buildtools/symlink-drivers-solibs.sh
> > @@ -9,4 +9,4 @@
> > # parameters to script are paths relative to install prefix:
> > # 1. directory containing driver files e.g. lib64/dpdk/drivers
> > # 2. directory for installed regular libs e.g. lib64
> > -ln -sf ${DESTDIR}/${MESON_INSTALL_PREFIX}/$1/*
> > ${DESTDIR}/${MESON_INSTALL_PREFIX}/$2
> > +ln -rsf ${DESTDIR}/${MESON_INSTALL_PREFIX}/$1/*
> > ${DESTDIR}/${MESON_INSTALL_PREFIX}/$2
>
> Acked-by: Bruce Richardson
Applied, thanks
Re: [dpdk-dev] [PATCH v3 01/10] event/dsw: add DSW device registration and build system
-Original Message- > Date: Tue, 11 Sep 2018 10:02:07 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 01/10] event/dsw: add DSW device registration and build > system > X-Mailer: git-send-email 2.17.1 > > > This patch contains the Meson and GNU Make build system extensions > required for the Distributed Event Device, and also the initialization > code for the driver itself. > > Signed-off-by: Mattias Rönnblom Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v2 01/33] config: add Cavium OcteonTX crypto PMD skeleton
Hi Akhil, On 17-09-2018 16:07, Akhil Goyal wrote: External Email I think it would be better to squash the makefile related changes in the 3/33 patch as the code is actually added in that and here the code is not getting compiled here. So the changes in the following files has to be moved to patch 3/33? drivers/crypto/Makefile drivers/crypto/meson.build drivers/crypto/octeontx/Makefile drivers/crypto/octeontx/meson.build mk/rte.app.mk I think this patch will just have MAINTAINER edit (even that might be required to be moved to 3/33?) & changes to config/common_base, after that. Is that fine? In my opinion, you do not need this patch as separate one. config/common_base can also be added in the 3/33. In that case 02/33 patch would become the first patch right? The same problem would be there too, I guess. The macros added in that patch gets used only in 03/33 patch. Is that fine? The first patch would be a shell patch for most PMD additions. That's the reason we started this way. If you want it changed, will do so. Please do let me know what will be the right approach. Anoob
Re: [dpdk-dev] [PATCH v2 05/33] common/cpt: add common code for init routine
17/09/2018 12:45, Akhil Goyal:
> On 9/4/2018 9:28 AM, Anoob Joseph wrote:
> > +struct pending_queue {
> > + uint16_t enq_tail;
> > + uint16_t deq_head;
> > + uint16_t soft_qlen;
> > + /**< Software expected queue length */
> > + uint16_t p_doorbell;
> > + struct rid *rid_queue;
> > + /**< Array of pending requests */
> > + uint64_t pending_count;
> > + /**< Pending requests count */
> > +};
> better to add comment for each element of structure.
> Also remove extra tab for comments(here and any other place if any.)
I don't understand this trend in the community about doing comments
_after_ the item _and_ not on the same line.
The default style should be commenting _before_.
And if you feel it is better to have the comment on the same line,
then you can comment _after_, but on the same line.
Re: [dpdk-dev] [PATCH] build: simplify logic for default library dependencies
08/08/2018 17:58, Bruce Richardson: > On Thu, Jul 26, 2018 at 03:55:56PM +0200, Thomas Monjalon wrote: > > 19/07/2018 16:37, Bruce Richardson: > > > EAL is a standard dependency of all libraries, except for those built > > > before it. We can therefore simplify the logic by just checking if EAL > > > has been processed, and make it a standard dependency if so. > > > > > > Signed-off-by: Bruce Richardson > > > > I guess there is no specific benefit for 18.08. > > It is deferred to 18.11 to avoid any risk. > > > Sure, no problem. Applied, thanks
Re: [dpdk-dev] [PATCH] build: add configuration summary at end of config
29/08/2018 18:19, Bruce Richardson: > After running meson to configure a DPDK build, it can be useful to know > what was automatically enabled or disabled. Therefore, print out by way of > summary a categorised list of libraries and drivers to be built. > > Signed-off-by: Bruce Richardson Applied, thanks
Re: [dpdk-dev] [PATCH 2/3] net/virtio-user: avoid parsing process mappings
On Mon, Sep 17, 2018 at 11:17:42AM +0100, Burakov, Anatoly wrote:
> On 10-Sep-18 4:59 AM, Tiwei Bie wrote:
> > On Fri, Sep 07, 2018 at 01:21:35PM +0100, Burakov, Anatoly wrote:
> > > On 07-Sep-18 12:35 PM, Tiwei Bie wrote:
> > > > On Fri, Sep 07, 2018 at 10:39:16AM +0100, Burakov, Anatoly wrote:
> > > > > On 05-Sep-18 5:28 AM, Tiwei Bie wrote:
> > > > > > Recently some memory APIs were introduced to allow users to
> > > > > > get the file descriptor and offset for each memory segment.
> > > > > > We can leverage those APIs to get rid of the /proc magic on
> > > > > > memory table preparation in vhost-user backend.
> > > > > >
> > > > > > Signed-off-by: Tiwei Bie
> > > > > > ---
> > > > >
> > > > >
> > > > >
> > > > > > - for (i = 0; i < num; ++i) {
> > > > > > - mr = &msg->payload.memory.regions[i];
> > > > > > - mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
> > > > > > - mr->userspace_addr = huges[i].addr;
> > > > > > - mr->memory_size = huges[i].size;
> > > > > > - mr->mmap_offset = 0;
> > > > > > - fds[i] = open(huges[i].path, O_RDWR);
> > > > > > + if (rte_memseg_get_fd_offset_thread_unsafe(ms, &offset) < 0) {
> > > > > > + PMD_DRV_LOG(ERR, "Failed to get offset, ms=%p
> > > > > > rte_errno=%d",
> > > > > > + ms, rte_errno);
> > > > > > + return -1;
> > > > > > + }
> > > > > > +
> > > > > > + start_addr = (uint64_t)(uintptr_t)ms->addr;
> > > > > > + end_addr = start_addr + ms->len;
> > > > > > +
> > > > > > + for (i = 0; i < wa->region_nr; i++) {
> > > > >
> > > > > There has to be a better way than to run this loop on every segment.
> > > > > Maybe
> > > > > store last-used region, and only do a region look up if there's a
> > > > > mismatch?
> > > > > Generally, in single-file segments mode, you'll get lots of segments
> > > > > from
> > > > > one memseg list one after the other, so you will need to do a lookup
> > > > > once
> > > > > memseg list changes, instead of on each segment.
> > > >
> > > > We may have holes in one memseg list due to dynamic free.
> > > > Do you mean we just need to do rte_memseg_contig_walk()
> > > > and we can assume that fds of the contiguous memegs will
> > > > be the same?
> > >
> > > No, i didn't mean that.
> > >
> > > Whether or not you are in single-file segments mode, you still need to
> > > scan
> > > each segment. However, you lose your state when you exit this function,
> > > and
> > > thus have to look up the appropriate memory region (that matches your fd)
> > > again, over and over. It would be good if you could store last-used memory
> > > region somewhere, so that next time you come back into this function, if
> > > the
> > > memseg has the same fd, you will not have to look it up.
> > >
> > > Something like this:
> > >
> > > struct walk_arg {
> > > *last_used;
> > >
> > > }
> > >
> > > int walk_func() {
> > >
> > > cur_region = wa->last_used; // check if it matches
> > > if (cur->region->fd != fd) {
> > > // fd is different - we've changed the segment
> > >
> > > wa->last_used = cur_region
> > > }
> > > }
> >
> > Thanks for the code. :)
> >
> > >
> > > So, cache last used region to not have to look it up again, because
> > > chances
> > > are, you won't have to. That way, you will still do region lookups, but
> > > only
> > > if you have to - not every time.
> >
> > I can do it, but I'm not sure this optimization is really
> > necessary. Because this loop should be quite fast, as the
> > max number of regions permitted by vhost-user is quite
> > small. And actually we need to do that loop at least once
> > for each packet in vhost-user's dequeue and enqueue path,
> > i.e. the data path.
>
> The number of regions is small, but the number of segments may be in the
> thousands. Think worst case - 8K segments in the 16th region
The number of regions permitted by vhost-user is 8.
And most likely, we just have two regions as the
single-file-segment mode is mandatory when using
2MB pages.
> - with my code,
> you will execute only 16 iterations on first segment and use "last used" for
> the rest of the segments,
We still need to do 8K iterations on the segments.
> while with your code, it'll be 8K times 16 :)
IMO, what we really need is a way to reduce "8K",
i.e. reduce the number of segments (which could
be thousands currently) we need to parse.
And the loop should be faster than the function
call to rte_memseg_get_fd_thread_unsafe() and
rte_memseg_get_fd_offset_thread_unsafe() (which
are also called for each segment).
>
> You'll have to clarify the "for each packet" part, not sure i follow.
Take the vhost-PMD as an example, when doing Rx burst
and Tx burst, for each mbuf (i.e. packet), we need to
do that loop at least once.
>
> --
> Thanks,
> Anatoly
Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c
b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index d25f9c1..cc0030e 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -10,9 +10,15 @@
#include "cpt_pmd_logs.h"
#include "otx_cryptodev.h"
+#include "otx_cryptodev_capabilities.h"
#include "otx_cryptodev_hw_access.h"
#include "otx_cryptodev_ops.h"
+static const struct rte_cryptodev_capabilities otx_capabilities[] = {
+ OTX_SYM_CAPABILITIES,
+ RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+};
+
better to have otx_capabilities structure defined in the
otx_cryptodev_capabilities.h
I don't see any value addition of creating a macro in one file using in a
separate structure in another file
which doesn't have anything new in that structure. It would also give
checkpatch error.
You can directly have a capability structure without the #define.
/* Alarm routines */
static void
Re: [dpdk-dev] [PATCH] test-meson-builds: add 32-bit compilation test
29/08/2018 18:02, Bruce Richardson: > Add in a cross-file to enable 32-bit compile tests as part > of the test-meson-builds script. > > Signed-off-by: Bruce Richardson > --- > NOTE: For ease of use, it's recommended that meson 0.47 be used for > this testing. With earlier versions, it may be necessary to ensure that > the same development packages are installed for both 64-bit and 32-bit. > --- > config/x86/i686_sse4_linuxapp_gcc | 18 ++ > devtools/test-meson-builds.sh | 4 > 2 files changed, 22 insertions(+) I'm not sure about adding this test as mandatory, because 32-bit version of libraries can be hard to get, especially libbsd and libnuma. I hope this test will be run by all developers, so we should not discourage them by adding too many requirements. Opinion? Idea?
Re: [dpdk-dev] [PATCH v3 03/10] event/dsw: add DSW port configuration
-Original Message- > Date: Tue, 11 Sep 2018 10:02:09 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 03/10] event/dsw: add DSW port configuration > X-Mailer: git-send-email 2.17.1 > > > Allow port setup and release in the DSW event device. > > Signed-off-by: Mattias Rönnblom Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v3 04/10] event/dsw: add support in DSW for linking/unlinking ports
-Original Message- > Date: Tue, 11 Sep 2018 10:02:10 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 04/10] event/dsw: add support in DSW for > linking/unlinking ports > X-Mailer: git-send-email 2.17.1 > > > Added support for linking and unlinking ports to queues in a DSW event > device. > > Signed-off-by: Mattias Rönnblom Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH 00/16] Support externally allocated memory in DPDK
Monday, September 17, 2018 1:07 PM, Burakov, Anatoly: > Subject: Re: [dpdk-dev] [PATCH 00/16] Support externally allocated memory > in DPDK > > On 13-Sep-18 8:44 AM, Shahaf Shuler wrote: [...] > >> The responsibility to ensure memory is accessible before using it is > >> on the shoulders of the user - there is no checking done with regards > >> to validity of the memory (nor could there be...). > > > > That makes sense. However who should be in-charge of mapping this > memory for dma access? > > The user or internally be the PMD when encounter the first packet or while > traversing the existing mempools? > > > Hi Shahaf, > > There are two ways this can be solved. The first way is to perform VFIO > mapping automatically on adding/attaching memory. The second is to force > user to do it manually. For now, the latter is chosen because user knows best > if they intend to do DMA on that memory, but i'm open to suggestions. I agree with that approach, and will add not only if the mempool is for dma or not but also which ports will use this mempool (this can effect on the mapping). However I don't think this is generic enough to use only VFIO. As you said, there are some devices not using VFIO for mapping rather some proprietary driver utility. IMO DPDK should introduce generic and device agnostic APIs to the user. My suggestion is instead of doing vfio_dma_map that or vfio_dma_unmap that have a generic dma_map(uint8_t port, address, len). Each driver will register with its own mapping callback (can be vfio_dma_map). It can be outside of this series, just wondering the people opinion on such approach. > > There is an issue with some devices and buses (i.e. bus/fslmc) bypassing EAL > VFIO infrastructure and performing their own VFIO/DMA mapping magic, but > solving that problem is outside the scope of this patchset. Those > devices/buses should fix themselves :) > > When not using VFIO, it's out of our hands anyway. Why? VFIO is not a must requirement for devices in DPDK. > > -- > Thanks, > Anatoly
Re: [dpdk-dev] [PATCH v2 01/33] config: add Cavium OcteonTX crypto PMD skeleton
On 9/17/2018 5:12 PM, Joseph, Anoob wrote: Hi Akhil, On 17-09-2018 16:07, Akhil Goyal wrote: External Email I think it would be better to squash the makefile related changes in the 3/33 patch as the code is actually added in that and here the code is not getting compiled here. So the changes in the following files has to be moved to patch 3/33? drivers/crypto/Makefile drivers/crypto/meson.build drivers/crypto/octeontx/Makefile drivers/crypto/octeontx/meson.build mk/rte.app.mk I think this patch will just have MAINTAINER edit (even that might be required to be moved to 3/33?) & changes to config/common_base, after that. Is that fine? In my opinion, you do not need this patch as separate one. config/common_base can also be added in the 3/33. In that case 02/33 patch would become the first patch right? The same problem would be there too, I guess. The macros added in that patch gets used only in 03/33 patch. Is that fine? I think that would be fine. Better to have a 03/33 patch before 02/33 if it doesn't have dependencies. The first patch would be a shell patch for most PMD additions. That's the reason we started this way. If you want it changed, will do so. Please do let me know what will be the right approach. For the makefiles, you would be compiling the empty files which does not have any code. That does not make any sense to me. Normally, when we submit a new PMD, we add the basic PMD probe/remove in the first patch and add it into build system. Maintainers is also updated for the new PMD. Further ops are added later in the patchset. Hardware specific header files/ functions are added before they are used in the driver in a single/multiple logical patches. In the end, documentation is added along with release note and MAINTAINERS update for documentation files. - Akhil
Re: [dpdk-dev] [PATCH v3 05/10] event/dsw: add DSW event scheduling and device start/stop
-Original Message- > Date: Tue, 11 Sep 2018 10:02:11 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 05/10] event/dsw: add DSW event scheduling and device > start/stop > X-Mailer: git-send-email 2.17.1 > > > With this patch, the DSW event device can be started and stopped, > and also supports scheduling events between ports. > > Signed-off-by: Mattias Rönnblom Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v3 09/10] event/dsw: implement eventdev 'xstats' counters in DSW
-Original Message- > Date: Tue, 11 Sep 2018 10:02:15 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 09/10] event/dsw: implement eventdev 'xstats' counters > in DSW > X-Mailer: git-send-email 2.17.1 > > External Email > > The DSW event device now implements the 'xstats' interface and a > number of port- and device-level counters. > > Signed-off-by: Mattias Rönnblom Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v2 05/33] common/cpt: add common code for init routine
Hi Thomas,
On 17-09-2018 17:16, Thomas Monjalon wrote:
External Email
17/09/2018 12:45, Akhil Goyal:
On 9/4/2018 9:28 AM, Anoob Joseph wrote:
+struct pending_queue {
+ uint16_t enq_tail;
+ uint16_t deq_head;
+ uint16_t soft_qlen;
+ /**< Software expected queue length */
+ uint16_t p_doorbell;
+ struct rid *rid_queue;
+ /**< Array of pending requests */
+ uint64_t pending_count;
+ /**< Pending requests count */
+};
better to add comment for each element of structure.
Also remove extra tab for comments(here and any other place if any.)
I don't understand this trend in the community about doing comments
_after_ the item _and_ not on the same line.
The default style should be commenting _before_.
And if you feel it is better to have the comment on the same line,
then you can comment _after_, but on the same line.
Will fix it. Saw comments after the item being used frequently and
thought that was the convention.
Thanks
Anoob
Re: [dpdk-dev] [PATCH v3 10/10] event/dsw: include DSW event device documentation
-Original Message- > Date: Tue, 11 Sep 2018 10:02:16 +0200 > From: Mattias Rönnblom > To: jerin.ja...@caviumnetworks.com > CC: bruce.richard...@intel.com, dev@dpdk.org, Mattias Rönnblom > > Subject: [PATCH v3 10/10] event/dsw: include DSW event device documentation > X-Mailer: git-send-email 2.17.1 > > > The DSW event device is documented in DPDK Programmer's Guide. > > Signed-off-by: Mattias Rönnblom > --- > doc/guides/eventdevs/dsw.rst | 97 ++ > doc/guides/eventdevs/index.rst | 1 + > 2 files changed, 98 insertions(+) > create mode 100644 doc/guides/eventdevs/dsw.rst > > diff --git a/doc/guides/eventdevs/dsw.rst b/doc/guides/eventdevs/dsw.rst > new file mode 100644 > index 0..de41ae9d3 > --- /dev/null > +++ b/doc/guides/eventdevs/dsw.rst > @@ -0,0 +1,97 @@ > +.. SPDX-License-Identifier: BSD-3-Clause > +Copyright(c) 2017 Intel Corporation. Is adding Intel copyright by intention? > +Copyright(c) 2018 Ericsson AB > + > +Distributed Software Eventdev Poll Mode Driver > +== > + > +The distributed software eventdev is a parallel implementation of the s/parallel/driver?? > +eventdev API, which distributes the task of scheduling events among > +all the eventdev ports and the lcore threads using them. > + Please update MAINTAINERS and doc/guides/rel_notes/release_18_11.rst files. With above changes: Acked-by: Jerin Jacob if there are no other review comments then I will push next revision v4 to next-eventdev. Thanks, Jerin
Re: [dpdk-dev] [PATCH v2 05/33] common/cpt: add common code for init routine
Hi Thomas,
On 9/17/2018 5:16 PM, Thomas Monjalon wrote:
17/09/2018 12:45, Akhil Goyal:
On 9/4/2018 9:28 AM, Anoob Joseph wrote:
+struct pending_queue {
+ uint16_t enq_tail;
+ uint16_t deq_head;
+ uint16_t soft_qlen;
+ /**< Software expected queue length */
+ uint16_t p_doorbell;
+ struct rid *rid_queue;
+ /**< Array of pending requests */
+ uint64_t pending_count;
+ /**< Pending requests count */
+};
better to add comment for each element of structure.
Also remove extra tab for comments(here and any other place if any.)
I don't understand this trend in the community about doing comments
_after_ the item _and_ not on the same line.
The default style should be commenting _before_.
And if you feel it is better to have the comment on the same line,
then you can comment _after_, but on the same line.
I think this should not matter, whether the comment should be before or after,
it should be consistent across the code. I can see that both are being used
equally.
Shall we change the complete code beyond this driver as well?
I think whatever we choose, it should be atleast consistent within the file.
-Akhil
Re: [dpdk-dev] [PATCH v2 09/33] crypto/octeontx: adds symmetric capabilities
Hi Akhil,
On 17-09-2018 17:31, Akhil Goyal wrote:
External Email
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c
b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index d25f9c1..cc0030e 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -10,9 +10,15 @@
#include "cpt_pmd_logs.h"
#include "otx_cryptodev.h"
+#include "otx_cryptodev_capabilities.h"
#include "otx_cryptodev_hw_access.h"
#include "otx_cryptodev_ops.h"
+static const struct rte_cryptodev_capabilities otx_capabilities[] = {
+ OTX_SYM_CAPABILITIES,
+ RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+};
+
better to have otx_capabilities structure defined in the
otx_cryptodev_capabilities.h
I don't see any value addition of creating a macro in one file using
in a separate structure in another file
which doesn't have anything new in that structure. It would also give
checkpatch error.
You can directly have a capability structure without the #define.
This was the convention followed in qat driver.
https://git.dpdk.org/dpdk/tree/drivers/crypto/qat/qat_sym_capabilities.h
I guess it was to avoid variable definition in header. May be Pablo too
can comment on this. I'll make the change accordingly.
Thanks,
Anoob
[dpdk-dev] [PATCH v2] mbuf: remove deprecated segment free functions
__rte_mbuf_raw_free and __rte_pktmbuf_prefree_seg have been deprecated for
a long time now (early 17.05), are not part of the abi and are easily
replaced with existing api.
Signed-off-by: David Marchand
Acked-by: Andrew Rybchenko
---
doc/guides/rel_notes/release_18_11.rst | 5 +
lib/librte_mbuf/rte_mbuf.h | 16
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/release_18_11.rst
b/doc/guides/rel_notes/release_18_11.rst
index 3ae6b3f58..d98573072 100644
--- a/doc/guides/rel_notes/release_18_11.rst
+++ b/doc/guides/rel_notes/release_18_11.rst
@@ -68,6 +68,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=
+* mbuf: The ``__rte_mbuf_raw_free()`` and ``__rte_pktmbuf_prefree_seg()``
+ functions were deprecated since 17.05 and are removed:
+
+ Those functions were kept for compatibility and are replaced by
+ ``rte_mbuf_raw_free()`` and ``rte_pktmbuf_prefree_seg()``.
ABI Changes
---
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 9ce5d76d7..a50b05c64 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -1038,14 +1038,6 @@ rte_mbuf_raw_free(struct rte_mbuf *m)
rte_mempool_put(m->pool, m);
}
-/* compat with older versions */
-__rte_deprecated
-static inline void
-__rte_mbuf_raw_free(struct rte_mbuf *m)
-{
- rte_mbuf_raw_free(m);
-}
-
/**
* The packet mbuf constructor.
*
@@ -1658,14 +1650,6 @@ rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
return NULL;
}
-/* deprecated, replaced by rte_pktmbuf_prefree_seg() */
-__rte_deprecated
-static inline struct rte_mbuf *
-__rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
-{
- return rte_pktmbuf_prefree_seg(m);
-}
-
/**
* Free a segment of a packet mbuf into its original mempool.
*
--
2.17.1
Re: [dpdk-dev] [PATCH v2 10/33] common/cpt: add PMD ops helper functions
On 9/4/2018 9:28 AM, Anoob Joseph wrote:
From: Murthy NSSR
Adding pmd ops helper functions. Control path accessed APIs would be
added as helper functions. Adding microcode defined macros etc as
dependencies to the helper functions.
Signed-off-by: Ankur Dwivedi
Signed-off-by: Anoob Joseph
Signed-off-by: Murthy NSSR
Signed-off-by: Nithin Dabilpuram
Signed-off-by: Ragothaman Jayaraman
Signed-off-by: Srisivasubramanian S
Signed-off-by: Tejasree Kondoj
---
drivers/common/Makefile | 4 +++
drivers/common/cpt/Makefile | 25
drivers/common/cpt/cpt_common.h | 41 +++
drivers/common/cpt/cpt_mcode_defines.h| 38 +
drivers/common/cpt/cpt_pmd_ops_helper.c | 41 +++
drivers/common/cpt/cpt_pmd_ops_helper.h | 34 ++
drivers/common/cpt/meson.build| 8 ++
drivers/common/cpt/rte_common_cpt_version.map | 6
drivers/common/meson.build| 2 +-
mk/rte.app.mk | 4 +++
10 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 drivers/common/cpt/Makefile
create mode 100644 drivers/common/cpt/cpt_mcode_defines.h
create mode 100644 drivers/common/cpt/cpt_pmd_ops_helper.c
create mode 100644 drivers/common/cpt/cpt_pmd_ops_helper.h
create mode 100644 drivers/common/cpt/meson.build
create mode 100644 drivers/common/cpt/rte_common_cpt_version.map
diff --git a/drivers/common/Makefile b/drivers/common/Makefile
index 0fd2237..ca4e854 100644
--- a/drivers/common/Makefile
+++ b/drivers/common/Makefile
@@ -8,4 +8,8 @@ ifeq
($(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF)$(CONFIG_RTE_LIBRTE_OCTEONTX_MEMPOO
DIRS-y += octeontx
endif
+ifeq ($(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO),y)
+DIRS-y += cpt
+endif
+
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/common/cpt/Makefile b/drivers/common/cpt/Makefile
new file mode 100644
index 000..2340aa9
--- /dev/null
+++ b/drivers/common/cpt/Makefile
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Cavium, Inc
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_common_cpt.a
+
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -I$(RTE_SDK)/drivers/bus/pci
+EXPORT_MAP := rte_common_cpt_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-y += cpt_pmd_ops_helper.c
+
+LDLIBS += -lrte_eal
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/common/cpt/cpt_common.h b/drivers/common/cpt/cpt_common.h
index feca5fe..1f78d42 100644
--- a/drivers/common/cpt/cpt_common.h
+++ b/drivers/common/cpt/cpt_common.h
@@ -18,6 +18,24 @@
#define AE_TYPE 1
#define SE_TYPE 2
+#ifndef ROUNDUP4
+#define ROUNDUP4(val) (((val) + 3) & 0xfffc)
+#endif
+
+#ifndef ROUNDUP8
+#define ROUNDUP8(val) (((val) + 7) & 0xfff8)
+#endif
+
+#ifndef ROUNDUP16
+#define ROUNDUP16(val) (((val) + 15) & 0xfff0)
+#endif
+
+#ifndef __hot
+#define __hot __attribute__((hot))
+#endif
+
+#define MOD_INC(i, l) ((i) == (l - 1) ? (i) = 0 : (i)++)
+
/* cpt instance */
struct cpt_instance {
uint32_t queue_id;
@@ -51,4 +69,27 @@ struct pending_queue {
/**< Pending requests count */
};
+struct cpt_request_info {
+ /* fast path fields */
+ uint64_t dma_mode : 2;
+ /**< DMA mode */
+ uint64_t se_req : 1;
+ /**< To SE core */
+ uint64_t comp_baddr : 61;
+ volatile uint64_t *completion_addr;
+ volatile uint64_t *alternate_caddr;
+ void *op;
+ /**< Reference to operation */
better to have comments in the same line wherever possible and if not,
please check indentation.
Please check other patches as well.
Re: [dpdk-dev] [PATCH v2 05/33] common/cpt: add common code for init routine
17/09/2018 14:32, Akhil Goyal:
>
> Hi Thomas,
>
> On 9/17/2018 5:16 PM, Thomas Monjalon wrote:
>
> > 17/09/2018 12:45, Akhil Goyal:
> >> On 9/4/2018 9:28 AM, Anoob Joseph wrote:
> >>> +struct pending_queue {
> >>> + uint16_t enq_tail;
> >>> + uint16_t deq_head;
> >>> + uint16_t soft_qlen;
> >>> + /**< Software expected queue length */
> >>> + uint16_t p_doorbell;
> >>> + struct rid *rid_queue;
> >>> + /**< Array of pending requests */
> >>> + uint64_t pending_count;
> >>> + /**< Pending requests count */
> >>> +};
> >> better to add comment for each element of structure.
> >> Also remove extra tab for comments(here and any other place if any.)
> > I don't understand this trend in the community about doing comments
> > _after_ the item _and_ not on the same line.
> > The default style should be commenting _before_.
> > And if you feel it is better to have the comment on the same line,
> > then you can comment _after_, but on the same line.
> >
> I think this should not matter, whether the comment should be before or after,
>
> it should be consistent across the code. I can see that both are being used
> equally.
>
> Shall we change the complete code beyond this driver as well?
>
> I think whatever we choose, it should be atleast consistent within the file.
Let me rephrase.
There are 3 styles:
1/ comment on the previous line (before the item)
2/ comment on the same line (just after the item)
3/ comment on the next line (after the item)
I am fine with #1 and #2 but I really don't see the benefit of #3.
Re: [dpdk-dev] [PATCH] test-meson-builds: add 32-bit compilation test
On Mon, Sep 17, 2018 at 02:03:50PM +0200, Thomas Monjalon wrote: > 29/08/2018 18:02, Bruce Richardson: > > Add in a cross-file to enable 32-bit compile tests as part > > of the test-meson-builds script. > > > > Signed-off-by: Bruce Richardson > > --- > > NOTE: For ease of use, it's recommended that meson 0.47 be used for > > this testing. With earlier versions, it may be necessary to ensure that > > the same development packages are installed for both 64-bit and 32-bit. > > --- > > config/x86/i686_sse4_linuxapp_gcc | 18 ++ > > devtools/test-meson-builds.sh | 4 > > 2 files changed, 22 insertions(+) > > I'm not sure about adding this test as mandatory, because 32-bit version > of libraries can be hard to get, especially libbsd and libnuma. > I hope this test will be run by all developers, so we should not discourage > them by adding too many requirements. > Opinion? Idea? Libbsd is not required, but yes, libnuma is, so you do need a 32-bit libnuma (devel) installed to run this test. I would expect that to be available on most distros though. I'm open to suggestions as to how to make this optional, but I do think that sanity checking 32-bit is good practice to avoid errors, e.g. those wonderful printf format strings for uint64_t. /Bruce
