[dpdk-dev] [PATCH 3/3] net/mlx5: add rte_flow rule creation
Convert Ethernet, IPv4, IPv6, TCP, UDP layers into ibv_flow and create
those rules when after validation (i.e. NIC supports the rule).
VLAN is still not supported in this commit.
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5_flow.c | 645 ++-
1 file changed, 631 insertions(+), 14 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 54807ad..e948000 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -31,6 +31,17 @@
*/
#include
+#include
+
+/* Verbs header. */
+/* ISO C doesn't support unnamed structs/unions, disabling -pedantic. */
+#ifdef PEDANTIC
+#pragma GCC diagnostic ignored "-Wpedantic"
+#endif
+#include
+#ifdef PEDANTIC
+#pragma GCC diagnostic error "-Wpedantic"
+#endif
#include
#include
@@ -39,11 +50,82 @@
#include "mlx5.h"
+/** Define a value to use as index for the drop queue. */
+#define MLX5_FLOW_DROP_QUEUE ((uint32_t)-1)
+
struct rte_flow {
LIST_ENTRY(rte_flow) next;
+ struct ibv_exp_flow_attr *ibv_attr;
+ struct ibv_exp_rwq_ind_table *ind_table;
+ struct ibv_qp *qp;
+ struct ibv_exp_flow *ibv_flow;
+ struct ibv_exp_wq *wq;
+ struct ibv_cq *cq;
+ uint8_t drop;
};
/**
+ * Check support for a given item.
+ *
+ * @param item[in]
+ * Item specification.
+ * @param mask[in]
+ * Bit-mask covering supported fields to compare with spec, last and mask in
+ * \item.
+ * @param size
+ * Bit-Mask size in bytes.
+ *
+ * @return
+ * 0 on success.
+ */
+static int
+mlx5_flow_item_validate(const struct rte_flow_item *item,
+ const uint8_t *mask, unsigned int size)
+{
+ int ret = 0;
+
+ if (item->spec && !item->mask) {
+ unsigned int i;
+ const uint8_t *spec = item->spec;
+
+ for (i = 0; i < size; ++i)
+ if ((spec[i] | mask[i]) != mask[i])
+ return -1;
+ }
+ if (item->last && !item->mask) {
+ unsigned int i;
+ const uint8_t *spec = item->last;
+
+ for (i = 0; i < size; ++i)
+ if ((spec[i] | mask[i]) != mask[i])
+ return -1;
+ }
+ if (item->mask) {
+ unsigned int i;
+ const uint8_t *spec = item->mask;
+
+ for (i = 0; i < size; ++i)
+ if ((spec[i] | mask[i]) != mask[i])
+ return -1;
+ }
+ if (item->spec && item->last) {
+ uint8_t spec[size];
+ uint8_t last[size];
+ const uint8_t *apply = mask;
+ unsigned int i;
+
+ if (item->mask)
+ apply = item->mask;
+ for (i = 0; i < size; ++i) {
+ spec[i] = ((const uint8_t *)item->spec)[i] & apply[i];
+ last[i] = ((const uint8_t *)item->last)[i] & apply[i];
+ }
+ ret = memcmp(spec, last, size);
+ }
+ return ret;
+}
+
+/**
* Validate a flow supported by the NIC.
*
* @param priv
@@ -67,9 +149,43 @@ priv_flow_validate(struct priv *priv,
const struct rte_flow_action actions[],
struct rte_flow_error *error)
{
- (void)priv;
const struct rte_flow_item *ilast = NULL;
const struct rte_flow_action *alast = NULL;
+ /* Supported mask. */
+ const struct rte_flow_item_eth eth_mask = {
+ .dst.addr_bytes = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff },
+ .src.addr_bytes = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff },
+ };
+ const struct rte_flow_item_ipv4 ipv4_mask = {
+ .hdr = {
+ .src_addr = -1,
+ .dst_addr = -1,
+ },
+ };
+ const struct rte_flow_item_ipv6 ipv6_mask = {
+ .hdr = {
+ .src_addr = {
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ },
+ .dst_addr = {
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ },
+ },
+ };
+ const struct rte_flow_item_udp udp_mask = {
+ .hdr = {
+ .src_port = -1,
+ .dst_port = -1,
+ },
+ };
+ const struct rte_flow_item_tcp tcp_mask = {
+ .hdr = {
+ .src_port = -1,
+ .dst_port = -1,
+ },
+ };
if (attr->group) {
rte_flow_error_set(error, ENOTSUP,
@@ -100,27 +216,70 @@ priv_flow_validate(struct priv *priv,
[dpdk-dev] [PATCH 2/3] net/mlx5: add software support for rte_flow
Introduce initial software validation for rte_flow rules.
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_flow.c| 196 ++--
drivers/net/mlx5/mlx5_trigger.c | 1 +
3 files changed, 169 insertions(+), 29 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 04f4eaa..df0e77c 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -136,6 +136,7 @@ struct priv {
unsigned int reta_idx_n; /* RETA index size. */
struct fdir_filter_list *fdir_filter_list; /* Flow director rules. */
struct fdir_queue *fdir_drop_queue; /* Flow director drop queue. */
+ LIST_HEAD(mlx5_flows, rte_flow) flows; /* RTE Flow rules. */
uint32_t link_speed_capa; /* Link speed capabilities. */
rte_spinlock_t lock; /* Lock for control functions. */
};
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index a514dff..54807ad 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -30,11 +30,125 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include
+
#include
#include
#include
+#include
+
#include "mlx5.h"
+struct rte_flow {
+ LIST_ENTRY(rte_flow) next;
+};
+
+/**
+ * Validate a flow supported by the NIC.
+ *
+ * @param priv
+ * Pointer to private structure.
+ * @param[in] attr
+ * Flow rule attributes.
+ * @param[in] pattern
+ * Pattern specification (list terminated by the END pattern item).
+ * @param[in] actions
+ * Associated actions (list terminated by the END action).
+ * @param[out] error
+ * Perform verbose error reporting if not NULL.
+ *
+ * @return
+ * 0 on success, a negative errno value otherwise and rte_errno is set.
+ */
+static int
+priv_flow_validate(struct priv *priv,
+ const struct rte_flow_attr *attr,
+ const struct rte_flow_item items[],
+ const struct rte_flow_action actions[],
+ struct rte_flow_error *error)
+{
+ (void)priv;
+ const struct rte_flow_item *ilast = NULL;
+ const struct rte_flow_action *alast = NULL;
+
+ if (attr->group) {
+ rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ATTR_GROUP,
+ NULL,
+ "groups are not supported");
+ return -rte_errno;
+ }
+ if (attr->priority) {
+ rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY,
+ NULL,
+ "priorities are not supported");
+ return -rte_errno;
+ }
+ if (attr->egress) {
+ rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ATTR_EGRESS,
+ NULL,
+ "egress is not supported");
+ return -rte_errno;
+ }
+ if (!attr->ingress) {
+ rte_flow_error_set(error, ENOTSUP,
+ RTE_FLOW_ERROR_TYPE_ATTR_INGRESS,
+ NULL,
+ "only ingress is supported");
+ return -rte_errno;
+ }
+ for (; items->type != RTE_FLOW_ITEM_TYPE_END; ++items) {
+ if (items->type == RTE_FLOW_ITEM_TYPE_VOID) {
+ continue;
+ } else if (items->type == RTE_FLOW_ITEM_TYPE_ETH) {
+ if (ilast)
+ goto exit_item_not_supported;
+ ilast = items;
+ } else if ((items->type == RTE_FLOW_ITEM_TYPE_IPV4) ||
+ (items->type == RTE_FLOW_ITEM_TYPE_IPV6)) {
+ if (!ilast)
+ goto exit_item_not_supported;
+ else if (ilast->type != RTE_FLOW_ITEM_TYPE_ETH)
+ goto exit_item_not_supported;
+ ilast = items;
+ } else if ((items->type == RTE_FLOW_ITEM_TYPE_UDP) ||
+ (items->type == RTE_FLOW_ITEM_TYPE_TCP)) {
+ if (!ilast)
+ goto exit_item_not_supported;
+ else if ((ilast->type != RTE_FLOW_ITEM_TYPE_IPV4) &&
+(ilast->type != RTE_FLOW_ITEM_TYPE_IPV6))
+ goto exit_item_not_supported;
+ ilast = items;
+ } else {
+ goto exit_item_not_supported;
+ }
+ }
+ for (; actions->type != RTE_FLOW_ACTION_TYPE_END; ++actions) {
+ if (actions->type == RTE_FLOW_ACTION_TYPE_VOID) {
+ continue;
+ } else if ((actions->t
[dpdk-dev] [PATCH 1/3] net/mlx5: add preliminary support for rte_flow
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/Makefile| 1 +
drivers/net/mlx5/mlx5.h | 16 ++
drivers/net/mlx5/mlx5_fdir.c | 15 ++
drivers/net/mlx5/mlx5_flow.c | 122 +++
4 files changed, 154 insertions(+)
create mode 100644 drivers/net/mlx5/mlx5_flow.c
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index cf87f0b..6d1338a 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -48,6 +48,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_stats.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_rss.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_fdir.c
SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_mr.c
+SRCS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5_flow.c
# Dependencies.
DEPDIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += lib/librte_ether
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 79b7a60..04f4eaa 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -59,6 +59,7 @@
#include
#include
#include
+#include
#ifdef PEDANTIC
#pragma GCC diagnostic error "-Wpedantic"
#endif
@@ -268,4 +269,19 @@ void priv_fdir_enable(struct priv *);
int mlx5_dev_filter_ctrl(struct rte_eth_dev *, enum rte_filter_type,
enum rte_filter_op, void *);
+/* mlx5_flow.c */
+
+int mlx5_flow_validate(struct rte_eth_dev *, const struct rte_flow_attr *,
+ const struct rte_flow_item [],
+ const struct rte_flow_action [],
+ struct rte_flow_error *);
+struct rte_flow *mlx5_flow_create(struct rte_eth_dev *,
+ const struct rte_flow_attr *,
+ const struct rte_flow_item [],
+ const struct rte_flow_action [],
+ struct rte_flow_error *);
+int mlx5_flow_destroy(struct rte_eth_dev *, struct rte_flow *,
+ struct rte_flow_error *);
+int mlx5_flow_flush(struct rte_eth_dev *, struct rte_flow_error *);
+
#endif /* RTE_PMD_MLX5_H_ */
diff --git a/drivers/net/mlx5/mlx5_fdir.c b/drivers/net/mlx5/mlx5_fdir.c
index 1acf682..f80c58b 100644
--- a/drivers/net/mlx5/mlx5_fdir.c
+++ b/drivers/net/mlx5/mlx5_fdir.c
@@ -55,6 +55,8 @@
#include
#include
#include
+#include
+#include
#ifdef PEDANTIC
#pragma GCC diagnostic error "-Wpedantic"
#endif
@@ -1042,6 +1044,14 @@ priv_fdir_ctrl_func(struct priv *priv, enum
rte_filter_op filter_op, void *arg)
return ret;
}
+static const struct rte_flow_ops mlx5_flow_ops = {
+ .validate = mlx5_flow_validate,
+ .create = mlx5_flow_create,
+ .destroy = mlx5_flow_destroy,
+ .flush = mlx5_flow_flush,
+ .query = NULL,
+};
+
/**
* Manage filter operations.
*
@@ -1067,6 +1077,11 @@ mlx5_dev_filter_ctrl(struct rte_eth_dev *dev,
struct priv *priv = dev->data->dev_private;
switch (filter_type) {
+ case RTE_ETH_FILTER_GENERIC:
+ if (filter_op != RTE_ETH_FILTER_GET)
+ return -EINVAL;
+ *(const void **)arg = &mlx5_flow_ops;
+ return 0;
case RTE_ETH_FILTER_FDIR:
priv_lock(priv);
ret = priv_fdir_ctrl_func(priv, filter_op, arg);
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
new file mode 100644
index 000..a514dff
--- /dev/null
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -0,0 +1,122 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright 2016 6WIND S.A.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of 6WIND S.A. 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
[dpdk-dev] [PATCH 0/3] net/mlx5: support flow_rte
This series requires rte_flow [1]. It brings rte_flow support to the same level as flow director (FDIR) in mlx5. [1] http://dpdk.org/ml/archives/dev/2016-November/050262.html Nelio Laranjeiro (3): net/mlx5: add preliminary support for rte_flow net/mlx5: add software support for rte_flow net/mlx5: add rte_flow rule creation drivers/net/mlx5/Makefile | 1 + drivers/net/mlx5/mlx5.h | 17 + drivers/net/mlx5/mlx5_fdir.c| 15 + drivers/net/mlx5/mlx5_flow.c| 877 drivers/net/mlx5/mlx5_trigger.c | 1 + 5 files changed, 911 insertions(+) create mode 100644 drivers/net/mlx5/mlx5_flow.c -- 2.1.4
[dpdk-dev] [PATCH 30/56] net/sfc: include libefx in build
On 11/25/2016 01:24 PM, Ferruh Yigit wrote: > On 11/24/2016 3:44 PM, Andrew Rybchenko wrote: >> See one question below. >> >> On 11/23/2016 06:26 PM, Ferruh Yigit wrote: >>> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: From: Artem Andreev Implement efsys.h for the PMD. Reviewed-by: Andy Moreton Signed-off-by: Artem Andreev Signed-off-by: Andrew Rybchenko --- drivers/net/sfc/efx/Makefile | 54 +++ drivers/net/sfc/efx/efsys.h | 767 +++ 2 files changed, 821 insertions(+) create mode 100644 drivers/net/sfc/efx/efsys.h <...> diff --git a/drivers/net/sfc/efx/efsys.h b/drivers/net/sfc/efx/efsys.h new file mode 100644 index 000..2eef996 --- /dev/null +++ b/drivers/net/sfc/efx/efsys.h @@ -0,0 +1,767 @@ >>> <...> >>> >>> I guess below is hardcoded compile time configuration for libefx, do you >>> think does it make sense to document this default configuration? >> Yes, it is libefx configuration and more options will be enabled when >> corresponding >> functionality is supported in the PMD. >> I'm sorry, but I don't understand what would you like to see in the >> documentation. >> Could you clarify, please? > This is mostly a question, following defines how libefx behaves, and a > little hard to find, do you think does it make sense to document these > in nic documentation, guides/nics/sfc_efx.rst, to highlight default > configuration. > > Like by default filtering capabilities and SFN7xxx family support > enabled but 5xxx/6xxx family support disabled... These can be listed in > a bullet listed way in two groups (default enabled / default disabled) ? I think that the information about dependencies is not very useful in the user guide documentation. For almost all options is not sufficient just to enable it here. Support in the PMD is required to bind libefx to corresponding external interfaces. I think it is a good idea to document here why some options are enabled and why SFN5xxx/SFN6xxx (Siena) support is disabled. Will do in v2. + +#define EFSYS_OPT_NAMES 0 + +#define EFSYS_OPT_SIENA 0 +#define EFSYS_OPT_HUNTINGTON 1 +#define EFSYS_OPT_MEDFORD 1 +#ifdef RTE_LIBRTE_SFC_EFX_DEBUG +#define EFSYS_OPT_CHECK_REG 1 +#else +#define EFSYS_OPT_CHECK_REG 0 +#endif + +#define EFSYS_OPT_MCDI 1 +#define EFSYS_OPT_MCDI_LOGGING 0 +#define EFSYS_OPT_MCDI_PROXY_AUTH 0 + +#define EFSYS_OPT_MAC_STATS 0 + +#define EFSYS_OPT_LOOPBACK 0 + +#define EFSYS_OPT_MON_MCDI 0 +#define EFSYS_OPT_MON_STATS 0 + +#define EFSYS_OPT_PHY_STATS 0 +#define EFSYS_OPT_BIST 0 +#define EFSYS_OPT_PHY_LED_CONTROL 0 +#define EFSYS_OPT_PHY_FLAGS 0 + +#define EFSYS_OPT_VPD 0 +#define EFSYS_OPT_NVRAM 0 +#define EFSYS_OPT_BOOTCFG 0 + +#define EFSYS_OPT_DIAG 0 +#define EFSYS_OPT_RX_SCALE 0 +#define EFSYS_OPT_QSTATS 0 +#define EFSYS_OPT_FILTER 1 +#define EFSYS_OPT_RX_SCATTER 0 + +#define EFSYS_OPT_EV_PREFETCH 0 + +#define EFSYS_OPT_DECODE_INTR_FATAL 0 + +#define EFSYS_OPT_LICENSING 0 + +#define EFSYS_OPT_ALLOW_UNCONFIGURED_NIC 0 + +#define EFSYS_OPT_RX_PACKED_STREAM 0 >>> <...>
[dpdk-dev] [PATCH 01/56] net/sfc: libefx-based PMD stub sufficient to build and init
On 11/25/2016 01:17 PM, Ferruh Yigit wrote: > On 11/24/2016 3:59 PM, Andrew Rybchenko wrote: >> On 11/23/2016 06:26 PM, Ferruh Yigit wrote: >>> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: The PMD is put into the sfc/efx subdirectory to have a place for the second PMD and library shared by both. Enable the PMD by default on supported configuratons. Reviewed-by: Andy Moreton Signed-off-by: Andrew Rybchenko --- MAINTAINERS | 6 ++ config/common_base | 6 ++ config/defconfig_arm-armv7a-linuxapp-gcc| 1 + config/defconfig_arm64-armv8a-linuxapp-gcc | 1 + config/defconfig_i686-native-linuxapp-gcc | 5 + config/defconfig_i686-native-linuxapp-icc | 5 + config/defconfig_ppc_64-power8-linuxapp-gcc | 1 + config/defconfig_tile-tilegx-linuxapp-gcc | 1 + config/defconfig_x86_64-native-linuxapp-icc | 5 + config/defconfig_x86_x32-native-linuxapp-gcc| 5 + doc/guides/nics/features/sfc_efx.ini| 10 ++ doc/guides/nics/index.rst | 1 + doc/guides/nics/sfc_efx.rst | 109 + <...> >>> And you can add extra options here, please keep in mind that there are >>> three compiler supported right now: gcc, clang and icc. You may require >>> to add compiler and version checks.. >> I've tried to disable the driver build on ICC since we've never tested it. > I believe we don't support selective config per compiler. Currently if a > code is enabled by default, it should support compilation with all three > compilers. I thought that the following lines in config/defconfig_x86_64-native-linuxapp-icc do the job: # # Solarflare PMD build is not supported using icc toolchain # CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n >> I've failed to find list of compiler versions which must/should be checked. > That list is not clear as far as I know. Mostly version related fixes > added based on reported build errors. So you can leave as it is right > now, or can test with default compiler versions of some common > distributions. I see. Thanks. <...>
[dpdk-dev] [PATCH v2 6/7] pci: Combine rte_eal_pci_scan and rte_eal_pci_probe
On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> Two functions is both confusing and unnecessary. Previously,
> rte_eal_pci_scan populated an internal list of devices by
> scanning sysfs. Then, rte_eal_pci_probe would match registered
> drivers to that internal list. These are not really useful
> operations to perform separately, though, so
> simplify the api down to just rte_eal_pci_probe which can
> be called repeatedly through the lifetime of the application
> to scan for new or removed PCI devices and load or unload
> drivers as required.
Agree with this.
And similar case exists for rte_eal_dev_init() for which there is
another patch floated by Jerin [1].
Also, I am already merging these two (EAL Bus model) [2]. So, we have:
- Only a probe called from EAL for all devices, whether PCI, VDEV or
another other type
- Probe in turns performs all scans and driver->probes()
Concern I have is that with the change of placement for device scan,
would it impact the external modules/PMDs as currently the scanned list
is created *before* eal_plugins_init(). But, now the list is created
*after* plugin initialization.
There are other similar inits like creation of slave threads. As well as
concern raised by Ferruh about device enumeration.
I don't have clear idea of all such dependencies. Maybe David and Ferruh
in CC might be able to comment better.
[1] http://dpdk.org/ml/archives/dev/2016-November/050415.html
[2] http://dpdk.org/ml/archives/dev/2016-November/050301.html
>
> Signed-off-by: Ben Walker
> ---
> app/test/test_pci.c | 2 +-
> lib/librte_eal/bsdapp/eal/eal.c | 3 ---
> lib/librte_eal/bsdapp/eal/eal_pci.c | 17 +
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
> lib/librte_eal/common/eal_common_pci.c | 6 ++
> lib/librte_eal/common/eal_private.h | 14 +-
> lib/librte_eal/common/include/rte_pci.h | 17 +
> lib/librte_eal/linuxapp/eal/eal.c | 3 ---
> lib/librte_eal/linuxapp/eal/eal_pci.c | 18 +-
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
> 10 files changed, 19 insertions(+), 63 deletions(-)
>
> diff --git a/app/test/test_pci.c b/app/test/test_pci.c
> index cda186d..fdd84f7 100644
> --- a/app/test/test_pci.c
> +++ b/app/test/test_pci.c
> @@ -180,7 +180,7 @@ test_pci_setup(void)
> TAILQ_INSERT_TAIL(&real_pci_device_list, dev, next);
> }
>
> - ret = rte_eal_pci_scan();
> + ret = rte_eal_pci_probe();
> TEST_ASSERT_SUCCESS(ret, "failed to scan PCI bus");
> rte_eal_pci_dump(stdout);
>
> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> index 35e3117..fd44528 100644
> --- a/lib/librte_eal/bsdapp/eal/eal.c
> +++ b/lib/librte_eal/bsdapp/eal/eal.c
> @@ -561,9 +561,6 @@ rte_eal_init(int argc, char **argv)
> if (rte_eal_timer_init() < 0)
> rte_panic("Cannot init HPET or TSC timers\n");
>
> - if (rte_eal_pci_init() < 0)
> - rte_panic("Cannot init PCI\n");
> -
> eal_check_mem_on_local_socket();
>
> if (eal_plugins_init() < 0)
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index 8b3ed88..6c3a169 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -361,7 +361,7 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
> * list. Call pci_scan_one() for each pci entry found.
> */
> int
> -rte_eal_pci_scan(void)
> +pci_scan(void)
> {
> int fd;
> unsigned dev_count = 0;
> @@ -667,18 +667,3 @@ rte_eal_pci_ioport_unmap(struct rte_pci_ioport *p)
>
> return ret;
> }
> -
> -/* Init the PCI EAL subsystem */
> -int
> -rte_eal_pci_init(void)
> -{
> - /* for debug purposes, PCI can be disabled */
> - if (internal_config.no_pci)
> - return 0;
> -
> - if (rte_eal_pci_scan() < 0) {
> - RTE_LOG(ERR, EAL, "%s(): Cannot scan PCI bus\n", __func__);
> - return -1;
> - }
> - return 0;
> -}
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 2f81f7c..67c469c 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -44,7 +44,6 @@ DPDK_2.0 {
> rte_eal_pci_probe;
> rte_eal_pci_probe_one;
> rte_eal_pci_register;
> - rte_eal_pci_scan;
> rte_eal_pci_unregister;
> rte_eal_process_type;
> rte_eal_remote_launch;
> diff --git a/lib/librte_eal/common/eal_common_pci.c
> b/lib/librte_eal/common/eal_common_pci.c
> index 4f8c3a0..d50a534 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -81,6 +81,7 @@
> #include
>
> #include "eal_private.h"
> +#include "eal_internal_cfg.h"
>
> struct pci_driver_list pci_driver_list =
>
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/25/2016 04:00 PM, Thomas Monjalon wrote: > 2016-11-25 12:43, Ferruh Yigit: >> On 11/25/2016 12:02 PM, Andrew Rybchenko wrote: >>> On 11/25/2016 01:24 PM, Ferruh Yigit wrote: On 11/23/2016 7:49 AM, Andrew Rybchenko wrote: > On 11/23/2016 03:02 AM, Ferruh Yigit wrote: >> Also folder structure is drivers/net/sfc/efx/, why /sfc/ >> layer is created? >> sfc is company name (solarflare communications), right? Other driver >> folders not structured based on company, what about using >> drivers/net/efx/* ? > I've tried to explain it above in item (2): > > >>> > >2. Another Solarflare PMD with in-kernel part (for control operations) > is considered and could be added in the future. Code for data path > should be shared by these two drivers. libefx-based PMD is put into > 'efx' subdirectory to have a space for another PMD and shared code. > > <<< > > So, main reason is to have location for the code shared by two Solarflare > network PMDs. May be it better to relocate when we really have it. > I'm open for other ideas/suggestions. If there will be another PMD that shares code with current one, the logic seems good, but I am not sure about start using company names, I am not against it, just I don't know. >>> I think that mlx4 and mlx5 are tightly bound to the company name (plus >>> adapter generation, I guess). >>> Let's relocate later, this buys some time to think / get feedback on issue. >>> Do I understand correctly that you suggest to avoid extra level inside >>> for now >>> and relocate later if required? If so, that's fine for me. >>> >>> As for naming, we think that just "efx" is a bad idea. The prefix is >>> occupied by >>> the libefx functions and driver should use something else. We have chosen >>> "sfc" mainly to follow naming used in Linux kernel for Solarflare driver >>> (the first level of Ethernet driver names is company bound in the Linux >>> kernel). >>> If we avoid extra level as discussed above, I think "sfc_efx", "sfcefx" >>> (may be it >>> will look better nearby other drivers) or just "sfc" are fine for us. >>> >> Thomas, Bruce, any comment on this? > You can add multiple drivers in the same library. As an example, ixgbe > directory have several drivers for PF/VF, scalar/vector, etc. > If you really want separate directories for your drivers while sharing some > code, you can link some files from the other directory. Thanks for ideas/examples. I'll remove extra level. > About the name of this directory, I have no strong opinion. > sfcefx looks good. If there is no strong opinion against "sfc" , we'd prefer to keep it: 1. sfc is used in Linux (and, hopefully, well know) 2. sfc is shorter and already used in sources 3. sfc seems to be more future proof if we would like to add more drivers inside (efx binds it to libefx) 4. sfc could be read as well as Solarflare Flareon Controller ;) Andrew.
[dpdk-dev] [PATCH v2 4/7] pci: rte_eal_pci_scan now handles removal of PCI devices
Hi Ben, On Thursday 24 November 2016 01:37 AM, Ben Walker wrote: > rte_eal_pci_scan can be called repeatedly to re-scan the PCI > bus. If a device was removed from the system, the associated > driver will automatically be unloaded. > > Signed-off-by: Ben Walker > --- [...] While reviewing, I found that there are some checkpatch warnings on this patch: --->8--- ### [PATCH v2 4/7] pci: rte_eal_pci_scan now handles removal of PCI devices WARNING:LONG_LINE_COMMENT: line over 80 characters #76: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:490: + /* Search the device list for devices that are no longer present on the system WARNING:LONG_LINE_STRING: line over 80 characters #105: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:519: + RTE_LOG(DEBUG, EAL, "PCI device "PCI_PRI_FMT" was removed.\n", WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #111: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:525: +* Unload it. */ WARNING:LONG_LINE_STRING: line over 80 characters #112: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:526: + RTE_LOG(DEBUG, EAL, " Unload driver: %x:%x %s\n", WARNING:LONG_LINE: line over 80 characters #113: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:527: + dev->id.vendor_id, dev->id.device_id, WARNING:LONG_LINE_COMMENT: line over 80 characters #117: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:531: + /* It doesn't matter what remove returns - WARNING:LONG_LINE_COMMENT: line over 80 characters #118: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:532: +* we're removing the device either way. */ WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #118: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:532: +* we're removing the device either way. */ WARNING:LONG_LINE: line over 80 characters #125: FILE: lib/librte_eal/linuxapp/eal/eal_pci.c:539: + if (dev->driver->drv_flags & RTE_PCI_DRV_NEED_MAPPING) total: 0 errors, 9 warnings, 69 lines checked --->8---
[dpdk-dev] [PATCH v2 3/7] pci: Pass rte_pci_addr to functions instead of separate args
On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> Instead of passing domain, bus, devid, func, just pass
> an rte_pci_addr.
>
> Signed-off-by: Ben Walker
> ---
> lib/librte_eal/linuxapp/eal/eal_pci.c | 32 +---
> 1 file changed, 13 insertions(+), 19 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
> b/lib/librte_eal/linuxapp/eal/eal_pci.c
> index 876ba38..073af5f 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -267,8 +267,7 @@ pci_parse_sysfs_resource(const char *filename, struct
> rte_pci_device *dev)
>
> /* Scan one pci sysfs entry, and fill the devices list from it. */
> static int
> -pci_scan_one(const char *dirname, uint16_t domain, uint8_t bus,
> - uint8_t devid, uint8_t function)
> +pci_scan_one(const char *dirname, const struct rte_pci_addr *addr)
> {
> char filename[PATH_MAX];
> unsigned long tmp;
> @@ -281,10 +280,7 @@ pci_scan_one(const char *dirname, uint16_t domain,
> uint8_t bus,
> return -1;
>
> memset(dev, 0, sizeof(*dev));
> - dev->addr.domain = domain;
> - dev->addr.bus = bus;
> - dev->addr.devid = devid;
> - dev->addr.function = function;
> + dev->addr = *addr;
>
> /* get vendor id */
> snprintf(filename, sizeof(filename), "%s/vendor", dirname);
> @@ -429,16 +425,14 @@ pci_update_device(const struct rte_pci_addr *addr)
>pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
>addr->function);
>
> - return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> - addr->function);
> + return pci_scan_one(filename, addr);
> }
>
> /*
> * split up a pci address into its constituent parts.
> */
> static int
> -parse_pci_addr_format(const char *buf, int bufsize, uint16_t *domain,
> - uint8_t *bus, uint8_t *devid, uint8_t *function)
> +parse_pci_addr_format(const char *buf, int bufsize, struct rte_pci_addr
> *addr)
> {
> /* first split on ':' */
> union splitaddr {
> @@ -466,10 +460,10 @@ parse_pci_addr_format(const char *buf, int bufsize,
> uint16_t *domain,
>
> /* now convert to int values */
> errno = 0;
> - *domain = (uint16_t)strtoul(splitaddr.domain, NULL, 16);
> - *bus = (uint8_t)strtoul(splitaddr.bus, NULL, 16);
> - *devid = (uint8_t)strtoul(splitaddr.devid, NULL, 16);
> - *function = (uint8_t)strtoul(splitaddr.function, NULL, 10);
> + addr->domain = (uint16_t)strtoul(splitaddr.domain, NULL, 16);
> + addr->bus = (uint8_t)strtoul(splitaddr.bus, NULL, 16);
> + addr->devid = (uint8_t)strtoul(splitaddr.devid, NULL, 16);
> + addr->function = (uint8_t)strtoul(splitaddr.function, NULL, 10);
> if (errno != 0)
> goto error;
>
> @@ -490,8 +484,7 @@ rte_eal_pci_scan(void)
> struct dirent *e;
> DIR *dir;
> char dirname[PATH_MAX];
> - uint16_t domain;
> - uint8_t bus, devid, function;
> + struct rte_pci_addr addr;
>
> dir = opendir(pci_get_sysfs_path());
> if (dir == NULL) {
> @@ -500,20 +493,21 @@ rte_eal_pci_scan(void)
> return -1;
> }
>
> +
Unnecessary new line.
> while ((e = readdir(dir)) != NULL) {
> if (e->d_name[0] == '.')
> continue;
>
> - if (parse_pci_addr_format(e->d_name, sizeof(e->d_name), &domain,
> - &bus, &devid, &function) != 0)
> + if (parse_pci_addr_format(e->d_name, sizeof(e->d_name), &addr)
> != 0)
> continue;
>
> snprintf(dirname, sizeof(dirname), "%s/%s",
> pci_get_sysfs_path(), e->d_name);
> - if (pci_scan_one(dirname, domain, bus, devid, function) < 0)
> + if (pci_scan_one(dirname, &addr) < 0)
> goto error;
> }
> closedir(dir);
> +
> return 0;
>
> error:
>
This is much more cleaner than passing all the BDF entries.
Except the above unnecessary new line:
Acked-by: Shreyansh Jain
[dpdk-dev] [PATCH] i40evf: add set maximum frame size support
This adds the ability to set maximum frame size for an i40e virtual
interface. This patch is based on the i40e physical function maximum
frame size implementation. This was tested on an system configured with
multiple i40e virtual functions. Verified that the MTU was configurable
and that sending packets greater than the configured MTU resulted in a
drop.
Signed-off-by: Michael Bieniek
---
drivers/net/i40e/i40e_ethdev_vf.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index aa306d6..8477c98 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -158,6 +158,7 @@ i40evf_dev_rx_queue_intr_disable(struct rte_eth_dev *dev,
uint16_t queue_id);
static void i40evf_handle_pf_event(__rte_unused struct rte_eth_dev *dev,
uint8_t *msg,
uint16_t msglen);
+static int i40evf_dev_mtu_set(struct rte_eth_dev *dev, uint16_t);
/* Default hash key buffer for RSS */
static uint32_t rss_key_default[I40E_VFQF_HKEY_MAX_INDEX + 1];
@@ -225,6 +226,7 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
.reta_query = i40evf_dev_rss_reta_query,
.rss_hash_update = i40evf_dev_rss_hash_update,
.rss_hash_conf_get= i40evf_dev_rss_hash_conf_get,
+ .mtu_set = i40evf_dev_mtu_set,
};
/*
@@ -2635,3 +2637,34 @@ i40evf_dev_rss_hash_conf_get(struct rte_eth_dev *dev,
return 0;
}
+
+static int
+i40evf_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct rte_eth_dev_data *dev_data = dev->data;
+ uint32_t frame_size = mtu + ETHER_HDR_LEN
+ + ETHER_CRC_LEN + I40E_VLAN_TAG_SIZE;
+ int ret = 0;
+
+ /* check if mtu is within the allowed range */
+ if ((mtu < ETHER_MIN_MTU) || (frame_size > I40E_FRAME_SIZE_MAX))
+ return -EINVAL;
+
+ /* mtu setting is forbidden if port is started */
+ if (dev_data->dev_started) {
+ PMD_DRV_LOG(ERR,
+ "port %d must be stopped before configuration\n",
+ dev_data->port_id);
+ return -EBUSY;
+ }
+
+ if (frame_size > ETHER_MAX_LEN)
+ dev_data->dev_conf.rxmode.jumbo_frame = 1;
+ else
+ dev_data->dev_conf.rxmode.jumbo_frame = 0;
+
+ dev_data->dev_conf.rxmode.max_rx_pkt_len = frame_size;
+
+ return ret;
+}
--
2.4.11
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/23/2016 03:02 AM, Ferruh Yigit wrote: > On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >> The patch series adds Solarflare libefx-based network PMD. >> >> This version of the driver supports Solarflare SFN7xxx and SFN8xxx >> families of 10/40 Gbps adapters. >> >> libefx is a platform-independent library to implement drivers for >> Solarflare network adapters. It provides unified adapter family >> independent interface (if possible). FreeBSD [1] and illumos [2] >> drivers are built on top of the library. >> >> The patch series could be logically structured into 5 sub-series: >> 1. (1) add the driver skeleton including documentation >> 2. (2-30) import libefx and include it in build with the latest patch >> 3. (31-43) implement minimal device level operations in steps >> 4. (44-51) implement Rx subsystem >> 5. (52-56) implement Tx subsystem >> >> Functional driver with multi-queue support capable to send and receive >> traffic appears with the last patch in the series. >> >> The following design decisions are made during development: >> >> 1. Since libefx uses positive errno return codes, positive errno >> return codes are used inside the driver and coversion to negative >> is done on return from eth_dev_ops callbacks. We think that it >> is the less error-prone way. >> >> 2. Another Solarflare PMD with in-kernel part (for control operations) >> is considered and could be added in the future. Code for data path >> should be shared by these two drivers. libefx-based PMD is put into >> 'efx' subdirectory to have a space for another PMD and shared code. >> >> 3. Own event queue (a way to deliver events from HW to host CPU) is >> used for house-keeping (e.g. link status notifications), each Tx >> and each Rx queue. No locks on datapath are requires in this case. >> >> 4. Alarm is used to periodically poll house-keeping event queue. >> The event queue is used to deliver link status change notifications, >> Rx/Tx queue flush events, SRAM events. It is not used on datapath. >> The event queue polling is protected using spin-lock since >> concurrent access from different contexts is possible (e.g. device >> stop when polling alarm is running). >> >> [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ >> [2] >> https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ >> >> --- >> >> Andrew Rybchenko (49): >>net/sfc: libefx-based PMD stub sufficient to build and init >>net/sfc: import libefx base >>net/sfc: import libefx register definitions >>net/sfc: import libefx filters support >>net/sfc: import libefx MCDI definition >>net/sfc: import libefx MCDI implementation >>net/sfc: import libefx MCDI logging support >>net/sfc: import libefx MCDI proxy authorization support >>net/sfc: import libefx 5xxx/6xxx family support >>net/sfc: import libefx SFN7xxx family support >>net/sfc: import libefx SFN8xxx family support >>net/sfc: import libefx diagnostics support >>net/sfc: import libefx built-in selftest support >>net/sfc: import libefx software per-queue statistics support >>net/sfc: import libefx PHY flags control support >>net/sfc: import libefx PHY statistics support >>net/sfc: import libefx PHY LEDs control support >>net/sfc: import libefx MAC statistics support >>net/sfc: import libefx event prefetch support >>net/sfc: import libefx Rx scatter support >>net/sfc: import libefx RSS support >>net/sfc: import libefx loopback control support >>net/sfc: import libefx monitors statistics support >>net/sfc: import libefx support to access monitors via MCDI >>net/sfc: import libefx support for Rx packed stream mode >>net/sfc: import libefx NVRAM support >>net/sfc: import libefx VPD support >>net/sfc: import libefx bootrom configuration support >>net/sfc: import libefx licensing support >>net/sfc: implement dummy callback to get device information >>net/sfc: implement driver operation to init device on attach >>net/sfc: add device configure and close stubs >>net/sfc: add device configuration checks >>net/sfc: implement device start and stop operations >>net/sfc: make available resources estimation and allocation >>net/sfc: interrupts support sufficient for event queue init >>net/sfc: implement event queue support >>net/sfc: implement EVQ dummy exception handling >>net/sfc: maintain management event queue >>net/sfc: periodic management EVQ polling using alarm >>net/sfc: minimum port control sufficient to receive traffic >>net/sfc: implement Rx subsystem stubs >>net/sfc: check configured rxmode >>net/sfc: implement Rx queue setup release operations >>net/sfc: calculate Rx buffer size which may be used >>net/sfc: validate Rx queue buffers setup >>net/sfc: implement Rx queue start and stop operations >>net/sfc: imp
[dpdk-dev] Proposal for a new Committer model
On Thu, Nov 24, 2016 at 01:53:55PM +0800, Yuanhan Liu wrote:
> On Wed, Nov 23, 2016 at 03:19:19PM -0500, Neil Horman wrote:
> > On Wed, Nov 23, 2016 at 11:41:20PM +0800, Yuanhan Liu wrote:
> > > On Wed, Nov 23, 2016 at 09:11:54AM -0500, Neil Horman wrote:
> > > > > Could we define some of the potential subtrees now and look to
> > > > > introduce them in the this release cycle? EAL and the Core libs, as
> > > > > suggested by Thomas, seem like 2 obvious ones.
> > > > >
> > > > Sure, I'd suggest the following:
> > >
> > > I would pull the git history to see which components are in
> > > active status in last release (or even, in last few release).
> > > And try to make a sub-tree if corresponding component is hot.
> > >
> > > # the 2nd volume shows how many patches prefixed with a related component
> > > [yliu at yliu-dev ~/dpdk]$ git log --oneline v16.07..v16.11 | awk '{print
> > > $2}' | \
> > > sort | uniq -c | sort -nr | head -30 | nl
> > > 1 52 doc:
> > > 2 40 net/ixgbe/base:
> > > 3 38 app/test:
> > > 4 37 kni:
> > > 5 27 vhost:
> > > 6 27 net/virtio:
> > > 7 27 net/mlx5:
> > > 8 26 app/testpmd:
> > > 9 25 net/i40e:
> > > 10 23 net/pcap:
> > > 11 22 net/bnxt:
> > > 12 20 net/enic:
> > > 13 18 net/qede:
> > > 14 17 net/thunderx:
> > > 15 16 net/qede/base:
> > > 16 16 eal:
> > > 17 15 net/ixgbe:
> > > 18 14 net:
> > > 19 14 crypto/qat:
> > > 20 13 scripts:
> > > 21 13 net/bnx2x:
> > > 22 12 net/i40e/base:
> > > 23 12 examples/ipsec-secgw:
> > > 24 11 mbuf:
> > > 25 11 hash:
> > > 26 10 lib:
> > > 27 10 examples/ip_pipeline:
> > > 28 10 ethdev:
> > > 299 pci:
> > > 307 net/vmxnet3:
> > > ...
> > > 463 pdump:
> > > 473 net/virtio_user:
> > > 483 net/ring:
> > > 493 net/nfp:
> > > 503 net/mlx:
> > > 513 net/ena:
> > > 523 net/e1000:
> > > 533 net/bonding:
> > > ...
> > > 562 sched:
> > > 572 port:
> > > ...
> > > 651 timer:
> > > 661 remove
> > > 671 pmdinfogen:
> > > 681 net/igb:
> > > 691 net/enic/base:
> > > 701 meter:
> > > ...
> > > 841 cfgfile:
> > > 851 app/procinfo:
> > > 861 app/proc_info:
> > > 871 acl:
> > >
> > > Something obvious is that:
> > >
> > > - "doc" deserves a sub-tree, and John is a perfect committer for that
> > > if he's willing to.
> > >
> > > - generally, I'd agree with Neil that most (if not all) pmds may need
> > > a sub-tree. While, some others may not, for example, net/ring, net/pcap.
> > >
> > No, thats the opposite of what I think. I think all net pmds should flow
> > through a single subtree, all crypto pmds through another, etc.
>
> I misunderstood it. I was think you were suggesting to create a sub-tree
> for most (or all) pmds. Some of my comments didn't apply then.
>
> But yes, we have already done that: we have next-net and next-crypto.
>
Yes, I'm speaking elsewhere in this thread on the topic of how that merge
process works, and how it can be improved. But this granularity I think is
correct.
> > > For those non-active pmds, I think it's okay to let the generic
> > > pmd committer to cover them.
> > >
> > Not sure what you're getting at here. Low volume pms (or any library) can
> > still
> > go through a subtree. The goal is to fragmet the commit work so one person
> > doesn't have to do it all.
> >
> > > - it's not that wise to me to list all the components we have so far
> > > and make a sub-tree for each of them.
> > >
> > I think you misunderstood the organization of my last note. I agree with
> > you
> > here. When I listed the core and listed several libraries under it, my
> > intent
> > was to create a core subtree that accepted patches for all of those
> > libraries.
> >
> > > For example, some components like librte_{port, pdump, cfgfile, acl,
> > > and etc} just have few (or even, just one) commits in last release.
> > > It makes no sense to me to introduce a tree for each of them.
> > >
> > Yes, this is what I was saying in my last note.
> >
> > > Another thought is we could also create sub-trees based on category
> > > but not on components like Neil suggested, especially that EAL looks
> > > way too big to be maintained in one tree. Instead, it could be something
> > > like:
> > >
> > > - a tree for BSD
> > >
> > This gets tricky, because then several libraries will be covered by multiple
> > trees, and that leads to merge conflicts.
>
> If we go that way, I meant a sub-sub-tree under EAL sub-tree. And conflicts
Hmmm.I'm not
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/25/2016 01:24 PM, Ferruh Yigit wrote: > On 11/23/2016 7:49 AM, Andrew Rybchenko wrote: >> On 11/23/2016 03:02 AM, Ferruh Yigit wrote: >>> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: The patch series adds Solarflare libefx-based network PMD. This version of the driver supports Solarflare SFN7xxx and SFN8xxx families of 10/40 Gbps adapters. libefx is a platform-independent library to implement drivers for Solarflare network adapters. It provides unified adapter family independent interface (if possible). FreeBSD [1] and illumos [2] drivers are built on top of the library. The patch series could be logically structured into 5 sub-series: 1. (1) add the driver skeleton including documentation 2. (2-30) import libefx and include it in build with the latest patch 3. (31-43) implement minimal device level operations in steps 4. (44-51) implement Rx subsystem 5. (52-56) implement Tx subsystem Functional driver with multi-queue support capable to send and receive traffic appears with the last patch in the series. The following design decisions are made during development: 1. Since libefx uses positive errno return codes, positive errno return codes are used inside the driver and coversion to negative is done on return from eth_dev_ops callbacks. We think that it is the less error-prone way. 2. Another Solarflare PMD with in-kernel part (for control operations) is considered and could be added in the future. Code for data path should be shared by these two drivers. libefx-based PMD is put into 'efx' subdirectory to have a space for another PMD and shared code. 3. Own event queue (a way to deliver events from HW to host CPU) is used for house-keeping (e.g. link status notifications), each Tx and each Rx queue. No locks on datapath are requires in this case. 4. Alarm is used to periodically poll house-keeping event queue. The event queue is used to deliver link status change notifications, Rx/Tx queue flush events, SRAM events. It is not used on datapath. The event queue polling is protected using spin-lock since concurrent access from different contexts is possible (e.g. device stop when polling alarm is running). [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ [2] https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ --- Andrew Rybchenko (49): net/sfc: libefx-based PMD stub sufficient to build and init net/sfc: import libefx base net/sfc: import libefx register definitions net/sfc: import libefx filters support net/sfc: import libefx MCDI definition net/sfc: import libefx MCDI implementation net/sfc: import libefx MCDI logging support net/sfc: import libefx MCDI proxy authorization support net/sfc: import libefx 5xxx/6xxx family support net/sfc: import libefx SFN7xxx family support net/sfc: import libefx SFN8xxx family support net/sfc: import libefx diagnostics support net/sfc: import libefx built-in selftest support net/sfc: import libefx software per-queue statistics support net/sfc: import libefx PHY flags control support net/sfc: import libefx PHY statistics support net/sfc: import libefx PHY LEDs control support net/sfc: import libefx MAC statistics support net/sfc: import libefx event prefetch support net/sfc: import libefx Rx scatter support net/sfc: import libefx RSS support net/sfc: import libefx loopback control support net/sfc: import libefx monitors statistics support net/sfc: import libefx support to access monitors via MCDI net/sfc: import libefx support for Rx packed stream mode net/sfc: import libefx NVRAM support net/sfc: import libefx VPD support net/sfc: import libefx bootrom configuration support net/sfc: import libefx licensing support net/sfc: implement dummy callback to get device information net/sfc: implement driver operation to init device on attach net/sfc: add device configure and close stubs net/sfc: add device configuration checks net/sfc: implement device start and stop operations net/sfc: make available resources estimation and allocation net/sfc: interrupts support sufficient for event queue init net/sfc: implement event queue support net/sfc: implement EVQ dummy exception handling net/sfc: maintain management event queue net/sfc: periodic management EVQ polling using alarm net/sfc: minimum port control sufficient t
[dpdk-dev] Proposal for a new Committer model
On Thu, Nov 24, 2016 at 10:17:09AM +0100, Thomas Monjalon wrote: > 2016-11-23 15:13, Neil Horman: > > Can either you or thomas provide some detail as to how you are doing patch > > management between trees (details of the commands you use are what I would > > be > > interested in). It sounds to me like there may be some optimization to be > > made > > here before we even make changes to the subtrees. > > Until now, we preferred avoiding merge commits. > That's why I rebase sub-trees to integrate them in the mainline. > As Ferruh explained, it does not require more work because sub-trees are > regularly rebased anyway. > And I use a script to keep original committer name and date. > > Hope it's clear now > It is clear, but I would make the assertion that performing that rebase yourselves (and arguably having the subtree maintainers do that too), you are undoing all the speedup that you would otherwise have gained. To illustrate, from what it sounds like to me, this is your workflow, from the moment that a merge window starts: 1) Each subtree maintainer syncrhonizes with your tree (either via a rebase, or a simple pull and creation of a new next version branch), the specific method can really be left up to the preference of the subtree maintainer 2) Developent procedes in parallel on multiple subtrees, and to your tree (for those patches that have no other designated subtree) 3) At some point, you opt to merge subtrees to your trees. For each tree you ostensibly then need to: 3a) Inform the subtree maintainer (or otherwise record the point up to which you decided to integrate) 3b) Grab a copy of that tree from the start to the end point (either via a remote branch clone or some other method) 3c) Rebase the branch in 3(b) to the HEAD of your tree, correcting any errors along the way 3d) preform a merge to your master branch, which, after 3(c), will by definition be a fast forward branch While thats a workable solution, it suffers from many drawbacks: a) It looses your commit history. That is to say, with a true merge, you record several other relevant pieces of information, including: * The branch/tree that the series came from * The changes that needed to be made to make the series fit (conflict tracking) * The sha1 sums of the commits (immutable changeset tracking). By rebasing you loose all of that, especially that last piece because the rebase you preform changes your shasums. With a non-merge, you keep all that information properly. b) You increase your error risk. With a true merge, all the changes you need to make to get a merge to resolve properly are contained in a single commit (the merge commit), providing easy review of your updates (not that they should happen frequently). By rebasing, you are left with potentially changed commits that aren't trackable or easily comparable to the origional submission. c) Perhaps most importantly, you serialize the entire process. To follow the above, you need to merge one branch at a time, rebasing each until it works properly, then merging it. With a true merge, you are afforded the opportunity to merge any number of branches in parallel (see git-octopus-merge). Apologies if this was discussed on list previously, but what was the percieved advantage to avoiding merge commits? It seems like alot of lost opportunity to avoid something that is actually fairly informative in the toolchain. Regards Neil
[dpdk-dev] [PATCH v2 2/7] pci: Separate detaching ethernet ports from PCI devices
On Thursday 24 November 2016 01:37 AM, Ben Walker wrote: > Attaching and detaching ethernet ports from an application > is not the same thing as physically removing a PCI device, > so clarify the flags indicating support. All PCI devices > are assumed to be physically removable, so no flag is > necessary in the PCI layer. > > Signed-off-by: Ben Walker > --- > doc/guides/prog_guide/port_hotplug_framework.rst | 2 +- > drivers/net/bnxt/bnxt_ethdev.c | 3 ++- > drivers/net/e1000/em_ethdev.c| 4 ++-- > drivers/net/e1000/igb_ethdev.c | 7 --- > drivers/net/fm10k/fm10k_ethdev.c | 4 ++-- > drivers/net/i40e/i40e_ethdev.c | 4 ++-- > drivers/net/i40e/i40e_ethdev_vf.c| 3 ++- > drivers/net/ixgbe/ixgbe_ethdev.c | 7 --- > drivers/net/nfp/nfp_net.c| 4 ++-- > drivers/net/virtio/virtio_ethdev.c | 3 ++- > drivers/net/vmxnet3/vmxnet3_ethdev.c | 3 ++- > drivers/net/xenvirt/rte_eth_xenvirt.c| 2 +- > lib/librte_eal/common/include/rte_pci.h | 2 -- > lib/librte_ether/rte_ethdev.c| 2 -- > 14 files changed, 26 insertions(+), 24 deletions(-) > > diff --git a/doc/guides/prog_guide/port_hotplug_framework.rst > b/doc/guides/prog_guide/port_hotplug_framework.rst > index 6e4436e..d68d08e 100644 > --- a/doc/guides/prog_guide/port_hotplug_framework.rst > +++ b/doc/guides/prog_guide/port_hotplug_framework.rst > @@ -106,5 +106,5 @@ Limitations > > * Not all PMDs support detaching feature. > To know whether a PMD can support detaching, search for the > -"RTE_PCI_DRV_DETACHABLE" flag in PMD implementation. If the flag is > +"RTE_ETH_DEV_DETAHABLE" flag in rte_eth_dev::data::dev_flags. If the > flag is Incorrect spelling. Should be 'RTE_ETH_DEV_DETACHABLE'. > defined in the PMD, detaching is supported. > diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c > index 035fe07..a2100f6 100644 > --- a/drivers/net/bnxt/bnxt_ethdev.c > +++ b/drivers/net/bnxt/bnxt_ethdev.c > @@ -1051,6 +1051,7 @@ bnxt_dev_init(struct rte_eth_dev *eth_dev) > RTE_LOG(INFO, PMD, "%s", bnxt_version); > > rte_eth_copy_pci_info(eth_dev, eth_dev->pci_dev); > + eth_dev->data->dev_flags = RTE_ETH_DEV_DETACHABLE; > bp = eth_dev->data->dev_private; > > if (bnxt_vf_pciid(eth_dev->pci_dev->id.device_id)) [...] - Shreyansh
[dpdk-dev] [PATCH v2 1/7] pci: If a driver's probe function fails, unmap resources.
On Thursday 24 November 2016 01:37 AM, Ben Walker wrote:
> If resources were mapped prior to probe, unmap them
> if probe fails.
>
> This does not handle the case where the kernel driver was
> forcibly unbound prior to probe.
>
> Signed-off-by: Ben Walker
> ---
> lib/librte_eal/common/eal_common_pci.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/eal_common_pci.c
> b/lib/librte_eal/common/eal_common_pci.c
> index 6bff675..4f8c3a0 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -215,8 +215,11 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
> struct rte_pci_device *d
>
> /* call the driver probe() function */
> ret = dr->probe(dr, dev);
> - if (ret)
> + if (ret) {
> dev->driver = NULL;
> + if (dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING)
> + rte_eal_pci_unmap_device(dev);
> + }
>
> return ret;
> }
>
Acked-by: Shreyansh Jain
[dpdk-dev] [PATCH v9] drivers/net:new PMD using tun/tap host interface
Keith,
This won't build when integrated with v16.11. The register macro
prefix has been renamed. a v10 is needed.
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 7f303db..297d4b6 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -752,5 +752,6 @@ static struct rte_vdev_driver pmd_tap_drv = {
.remove = rte_pmd_tap_remove,
};
-DRIVER_REGISTER_VDEV(net_tap, pmd_tap_drv);
-DRIVER_REGISTER_PARAM_STRING(net_tap, "iface=,speed=N");
+RTE_PMD_REGISTER_VDEV(net_tap, pmd_tap_drv);
+RTE_PMD_REGISTER_ALIAS(net_tap, eth_tap);
+RTE_PMD_REGISTER_PARAM_STRING(net_tap, "iface=,speed=N");
On Mon, Nov 21, 2016 at 7:56 AM, Ferruh Yigit wrote:
> On 10/13/2016 11:03 PM, Keith Wiles wrote:
>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
>> on the local host. The PMD allows for DPDK and the host to
>> communicate using a raw device interface on the host and in
>> the DPDK application. The device created is a Tap device with
>> a L2 packet header.
>>
>> v9 - Fix up the docs to use correct syntax
>> v8 - Fix issue with tap_tx_queue_setup() not return zero on success.
>> v7 - Reword the comment in common_base and fix the data->name issue
>> v6 - fixed the checkpatch issues
>> v5 - merge in changes from list review see related emails
>> fixed many minor edits
>> v4 - merge with latest driver changes
>> v3 - fix includes by removing ifdef for other type besides Linux
>> Fix the copyright notice in the Makefile
>> v2 - merge all of the patches into one patch
>> Fix a typo on naming the tap device
>> Update the maintainers list
>>
>> Signed-off-by: Keith Wiles
>> ---
>
> Just a reminder, this is a new PMD and waiting for community review.
[dpdk-dev] [PATCH] test: adding AES cipher-only tests on QAT PMD
> -Original Message- > From: Trahe, Fiona > Sent: Thursday, November 24, 2016 6:29 PM > To: dev at dpdk.org > Cc: De Lara Guarch, Pablo ; Trahe, Fiona > ; Griffin, John ; > Kusztal, > ArkadiuszX > Subject: [PATCH] test: adding AES cipher-only tests on QAT PMD > > Extended functional AES-CBC and AES-CTR cipher-only tests to run on QAT > PMD. > Added AES_CBC cipher-only performance tests on QAT PMD. > No driver changes, but as now tested, QAT documentation is updated to > remove constraint. > > Signed-off-by: Fiona Trahe > --- > app/test/test_cryptodev.c | 18 ++ > app/test/test_cryptodev_aes_test_vectors.h | 36 +++ > app/test/test_cryptodev_perf.c | 96 +++-- > - > doc/guides/cryptodevs/qat.rst | 1 - > 4 files changed, 102 insertions(+), 49 deletions(-) > > -- > 2.5.0 Acked-by: Arek Kusztal
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
2016-11-25 11:00, Bruce Richardson: > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote: > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote: > > > 2016-11-24 07:29, Jerin Jacob: > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote: > > > > > 2016-11-18 11:14, Jerin Jacob: > > > > > > +#define EVENTDEV_NAME_SKELETON_PMD event_skeleton > > > > > > +/**< Skeleton event device PMD name */ > > > > > > > > > > I do not understand this #define. > > > > > > > > Applications can explicitly request the a specific driver though driver > > > > name. This will go as argument to rte_event_dev_get_dev_id(const char > > > > *name). > > > > The reason for keeping this #define in rte_eventdev.h is that, > > > > application needs to include only rte_eventdev.h not rte_eventdev_pmd.h. > > > > > > So each driver must register its name in the API? > > > Is it really needed? > > > > Otherwise how application knows the name of the driver. > > The similar scheme used in cryptodev. > > http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev/rte_cryptodev.h#n53 > > No strong opinion here. Open for suggestions. > > > > I like having a name registered. I think we need a scheme where an app > can find and use an implementation using a specific driver. I do not like having the driver names in the API. An API should not know its drivers. If an application do some driver-specific processing, it knows the driver name as well. The driver name is written in the driver.
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
2016-11-25 12:43, Ferruh Yigit: > On 11/25/2016 12:02 PM, Andrew Rybchenko wrote: > > On 11/25/2016 01:24 PM, Ferruh Yigit wrote: > >> On 11/23/2016 7:49 AM, Andrew Rybchenko wrote: > >>> On 11/23/2016 03:02 AM, Ferruh Yigit wrote: > Also folder structure is drivers/net/sfc/efx/, why /sfc/ > layer is created? > sfc is company name (solarflare communications), right? Other driver > folders not structured based on company, what about using > drivers/net/efx/* ? > >>> I've tried to explain it above in item (2): > >>> > >>> >>> > >>> > >>> 2. Another Solarflare PMD with in-kernel part (for control operations) > >>> is considered and could be added in the future. Code for data path > >>> should be shared by these two drivers. libefx-based PMD is put into > >>> 'efx' subdirectory to have a space for another PMD and shared code. > >>> > >>> <<< > >>> > >>> So, main reason is to have location for the code shared by two Solarflare > >>> network PMDs. May be it better to relocate when we really have it. > >>> I'm open for other ideas/suggestions. > >> If there will be another PMD that shares code with current one, the > >> logic seems good, but I am not sure about start using company names, I > >> am not against it, just I don't know. > > > > I think that mlx4 and mlx5 are tightly bound to the company name (plus > > adapter generation, I guess). > > > >> Let's relocate later, this buys some time to think / get feedback on issue. > > > > Do I understand correctly that you suggest to avoid extra level inside > > for now > > and relocate later if required? If so, that's fine for me. > > > > As for naming, we think that just "efx" is a bad idea. The prefix is > > occupied by > > the libefx functions and driver should use something else. We have chosen > > "sfc" mainly to follow naming used in Linux kernel for Solarflare driver > > (the first level of Ethernet driver names is company bound in the Linux > > kernel). > > If we avoid extra level as discussed above, I think "sfc_efx", "sfcefx" > > (may be it > > will look better nearby other drivers) or just "sfc" are fine for us. > > > > Thomas, Bruce, any comment on this? You can add multiple drivers in the same library. As an example, ixgbe directory have several drivers for PF/VF, scalar/vector, etc. If you really want separate directories for your drivers while sharing some code, you can link some files from the other directory. About the name of this directory, I have no strong opinion. sfcefx looks good.
[dpdk-dev] [PATCH v3] kni: avoid using lsb_release script
The lsb_release script is part of an optional package which is not always installed. On the other hand, /etc/lsb-release is always present even on minimal Ubuntu installations. root at ubuntu1604:~# dpkg -S /etc/lsb-release base-files: /etc/lsb-release Read the file if present and use the variables defined in it. Signed-off-by: Robin Jarry --- lib/librte_eal/linuxapp/kni/Makefile | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/kni/Makefile b/lib/librte_eal/linuxapp/kni/Makefile index 4e99e07e7aec..1e4756123d0c 100644 --- a/lib/librte_eal/linuxapp/kni/Makefile +++ b/lib/librte_eal/linuxapp/kni/Makefile @@ -44,8 +44,10 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h MODULE_CFLAGS += -Wall -Werror -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) -MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .) +-include /etc/lsb-release + +ifeq ($(DISTRIB_ID),Ubuntu) +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(DISTRIB_RELEASE)) UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE $(RTE_KERNELDIR)/include/generated/utsrelease.h \ | cut -d '"' -f2 | cut -d- -f1,2 | tr .- ,`,1) MODULE_CFLAGS += -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))" -- 2.1.4
[dpdk-dev] [PATCH] i40e: fix oversize packet counter not incrementing for large packets
The XL710 requires that the Set MAC Config command be used to define the
maximum frame size in order for the Receive Oversize Count register
(GLPRT_ROC) to be incremented for packets received that are greater than
the MTU. Without this change, the XL710 will drop the oversized packets
without incrementing the corresponding counter.
Signed-off-by: Michael Bieniek
---
drivers/net/i40e/i40e_ethdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..c11c80b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -9709,6 +9709,7 @@ static int
i40e_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_dev_data *dev_data = pf->dev_data;
uint32_t frame_size = mtu + ETHER_HDR_LEN
+ ETHER_CRC_LEN + I40E_VLAN_TAG_SIZE;
@@ -9732,6 +9733,7 @@ i40e_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
dev_data->dev_conf.rxmode.jumbo_frame = 0;
dev_data->dev_conf.rxmode.max_rx_pkt_len = frame_size;
+ i40e_aq_set_mac_config(hw, frame_size, TRUE, 0, NULL);
return ret;
}
--
2.4.11
[dpdk-dev] [PATCH 00/16] e1000 base code update
Hi Wenzhuo, On 11/23/2016 5:22 PM, Wenzhuo Lu wrote: > Updated e1000 base code to fix several bugs and support > i219 NICs. > > Wenzhuo Lu (16): > e1000/base: increased ULP timer > e1000/base: increase PHY PLL clock gate timing > e1000/base: try more times to get HW mailbox lock > e1000/base: add getting HW version support for i354 > e1000/base: expose e1000_write_vfta_i350 > e1000/base: add max RX jumbo frame define > e1000/base: restore link speed after ULP exit > e1000/base: clear ULP configuration register on ULP exit > e1000/base: increase LANPHYPC low duration > e1000/base: workaround for ULP entry flow > e1000/base: enable new i219 devices > e1000/base: always request clock during K1 at 1G link speed > e1000/base: ability to force K1-off disabled > e1000/base: support more i219 devices > e1000/base: update readme > e1000: add new i219 devices > > drivers/net/e1000/base/README | 4 +- > drivers/net/e1000/base/e1000_82575.c | 1 - > drivers/net/e1000/base/e1000_82575.h | 1 + > drivers/net/e1000/base/e1000_api.c | 19 + > drivers/net/e1000/base/e1000_defines.h | 9 + > drivers/net/e1000/base/e1000_hw.h | 21 +- > drivers/net/e1000/base/e1000_ich8lan.c | 865 > +++-- > drivers/net/e1000/base/e1000_ich8lan.h | 21 +- > drivers/net/e1000/base/e1000_mbx.c | 36 +- > drivers/net/e1000/base/e1000_nvm.c | 1 + > drivers/net/e1000/base/e1000_regs.h| 7 + > drivers/net/e1000/em_ethdev.c | 34 +- > 12 files changed, 949 insertions(+), 70 deletions(-) > Based on this pathset. Can you also please send another patch to: 1- add I219 to supported nics list 2- announce new supported nic in release notes. Also as far as I can see there is no igb/e1000 documentation under doc/guides/nics/*, it can good to provide one, not with above requested patches perhaps, but in some suitable time. Thanks, ferruh
[dpdk-dev] [PATCH 00/16] e1000 base code update
On 11/23/2016 5:22 PM, Wenzhuo Lu wrote: > Updated e1000 base code to fix several bugs and support > i219 NICs. > > Wenzhuo Lu (16): > e1000/base: increased ULP timer > e1000/base: increase PHY PLL clock gate timing > e1000/base: try more times to get HW mailbox lock > e1000/base: add getting HW version support for i354 > e1000/base: expose e1000_write_vfta_i350 > e1000/base: add max RX jumbo frame define > e1000/base: restore link speed after ULP exit > e1000/base: clear ULP configuration register on ULP exit > e1000/base: increase LANPHYPC low duration > e1000/base: workaround for ULP entry flow > e1000/base: enable new i219 devices > e1000/base: always request clock during K1 at 1G link speed > e1000/base: ability to force K1-off disabled > e1000/base: support more i219 devices > e1000/base: update readme > e1000: add new i219 devices > > drivers/net/e1000/base/README | 4 +- > drivers/net/e1000/base/e1000_82575.c | 1 - > drivers/net/e1000/base/e1000_82575.h | 1 + > drivers/net/e1000/base/e1000_api.c | 19 + > drivers/net/e1000/base/e1000_defines.h | 9 + > drivers/net/e1000/base/e1000_hw.h | 21 +- > drivers/net/e1000/base/e1000_ich8lan.c | 865 > +++-- > drivers/net/e1000/base/e1000_ich8lan.h | 21 +- > drivers/net/e1000/base/e1000_mbx.c | 36 +- > drivers/net/e1000/base/e1000_nvm.c | 1 + > drivers/net/e1000/base/e1000_regs.h| 7 + > drivers/net/e1000/em_ethdev.c | 34 +- > 12 files changed, 949 insertions(+), 70 deletions(-) > Series applied to dpdk-next-net/master, thanks. Some modifications done in both commit subject and logs, can you please double check the updates.
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/25/2016 12:02 PM, Andrew Rybchenko wrote: > On 11/25/2016 01:24 PM, Ferruh Yigit wrote: >> On 11/23/2016 7:49 AM, Andrew Rybchenko wrote: >>> On 11/23/2016 03:02 AM, Ferruh Yigit wrote: On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: > The patch series adds Solarflare libefx-based network PMD. > > This version of the driver supports Solarflare SFN7xxx and SFN8xxx > families of 10/40 Gbps adapters. > > libefx is a platform-independent library to implement drivers for > Solarflare network adapters. It provides unified adapter family > independent interface (if possible). FreeBSD [1] and illumos [2] > drivers are built on top of the library. > > The patch series could be logically structured into 5 sub-series: > 1. (1) add the driver skeleton including documentation > 2. (2-30) import libefx and include it in build with the latest patch > 3. (31-43) implement minimal device level operations in steps > 4. (44-51) implement Rx subsystem > 5. (52-56) implement Tx subsystem > > Functional driver with multi-queue support capable to send and receive > traffic appears with the last patch in the series. > > The following design decisions are made during development: > > 1. Since libefx uses positive errno return codes, positive errno > return codes are used inside the driver and coversion to negative > is done on return from eth_dev_ops callbacks. We think that it > is the less error-prone way. > > 2. Another Solarflare PMD with in-kernel part (for control operations) > is considered and could be added in the future. Code for data path > should be shared by these two drivers. libefx-based PMD is put into > 'efx' subdirectory to have a space for another PMD and shared code. > > 3. Own event queue (a way to deliver events from HW to host CPU) is > used for house-keeping (e.g. link status notifications), each Tx > and each Rx queue. No locks on datapath are requires in this case. > > 4. Alarm is used to periodically poll house-keeping event queue. > The event queue is used to deliver link status change notifications, > Rx/Tx queue flush events, SRAM events. It is not used on datapath. > The event queue polling is protected using spin-lock since > concurrent access from different contexts is possible (e.g. device > stop when polling alarm is running). > > [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ > [2] > https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ > > --- > > Andrew Rybchenko (49): >net/sfc: libefx-based PMD stub sufficient to build and init >net/sfc: import libefx base >net/sfc: import libefx register definitions >net/sfc: import libefx filters support >net/sfc: import libefx MCDI definition >net/sfc: import libefx MCDI implementation >net/sfc: import libefx MCDI logging support >net/sfc: import libefx MCDI proxy authorization support >net/sfc: import libefx 5xxx/6xxx family support >net/sfc: import libefx SFN7xxx family support >net/sfc: import libefx SFN8xxx family support >net/sfc: import libefx diagnostics support >net/sfc: import libefx built-in selftest support >net/sfc: import libefx software per-queue statistics support >net/sfc: import libefx PHY flags control support >net/sfc: import libefx PHY statistics support >net/sfc: import libefx PHY LEDs control support >net/sfc: import libefx MAC statistics support >net/sfc: import libefx event prefetch support >net/sfc: import libefx Rx scatter support >net/sfc: import libefx RSS support >net/sfc: import libefx loopback control support >net/sfc: import libefx monitors statistics support >net/sfc: import libefx support to access monitors via MCDI >net/sfc: import libefx support for Rx packed stream mode >net/sfc: import libefx NVRAM support >net/sfc: import libefx VPD support >net/sfc: import libefx bootrom configuration support >net/sfc: import libefx licensing support >net/sfc: implement dummy callback to get device information >net/sfc: implement driver operation to init device on attach >net/sfc: add device configure and close stubs >net/sfc: add device configuration checks >net/sfc: implement device start and stop operations >net/sfc: make available resources estimation and allocation >net/sfc: interrupts support sufficient for event queue init >net/sfc: implement event queue support >net/sfc: implement EVQ dummy exception handling >net/sfc: maintain management event queue >net/sfc: periodic manag
[dpdk-dev] [PATCH v2] kni: avoid using lsb_release script
The lsb_release script is part of an optional package which is not always installed. On the other hand, /etc/lsb-release is always present even on minimal Ubuntu installations. root at ubuntu1604:~# dpkg -S /etc/lsb-release base-files: /etc/lsb-release Read the file if present and use the variables defined in it. Signed-off-by: Robin Jarry --- lib/librte_eal/linuxapp/kni/Makefile | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/kni/Makefile b/lib/librte_eal/linuxapp/kni/Makefile index 4e99e07e7aec..62a957ce8534 100644 --- a/lib/librte_eal/linuxapp/kni/Makefile +++ b/lib/librte_eal/linuxapp/kni/Makefile @@ -44,8 +44,12 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h MODULE_CFLAGS += -Wall -Werror -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) -MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .) +ifneq ($(wildcard /etc/lsb-release),) +-include /etc/lsb-release +endif + +ifeq ($(DISTRIB_ID),Ubuntu) +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(DISTRIB_RELEASE)) UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE $(RTE_KERNELDIR)/include/generated/utsrelease.h \ | cut -d '"' -f2 | cut -d- -f1,2 | tr .- ,`,1) MODULE_CFLAGS += -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))" -- 2.1.4
[dpdk-dev] [PATCH] kni: avoid using lsb_release script
2016-11-25, Ferruh Yigit: >What about: >+-include /etc/lsb-release Sure, that cannot hurt. >s/DISTRIB_ID/DISTRIB_RELEASE Oops last minute typo... I'll submit a v2 right away. -- Robin
[dpdk-dev] [PATCH v3] kni: avoid using lsb_release script
On 11/25/2016 12:22 PM, Robin Jarry wrote: > The lsb_release script is part of an optional package which is not > always installed. On the other hand, /etc/lsb-release is always present > even on minimal Ubuntu installations. > > root at ubuntu1604:~# dpkg -S /etc/lsb-release > base-files: /etc/lsb-release > > Read the file if present and use the variables defined in it. > > Signed-off-by: Robin Jarry Acked-by: Ferruh Yigit
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
> -Original Message- > From: Van Haaren, Harry > Sent: Friday, November 25, 2016 11:59 AM > To: Jerin Jacob ; Thomas Monjalon > > Cc: dev at dpdk.org; Richardson, Bruce ; > hemant.agrawal at nxp.com; Eads, Gage > Subject: RE: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven > programming model > > Hi All, > > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > > Sent: Friday, November 25, 2016 12:24 AM > > To: Thomas Monjalon > > Cc: dev at dpdk.org; Richardson, Bruce ; Van > > Haaren, Harry ; hemant.agrawal at nxp.com; > > Eads, Gage > > Subject: Re: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven > > programming model > > > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote: > > > 2016-11-24 07:29, Jerin Jacob: > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote: > > > > > 2016-11-18 11:14, Jerin Jacob: > > > > > > > +#define RTE_EVENT_TYPE_ETHDEV 0x0 > > > > > > +/**< The event generated from ethdev subsystem */ > > > > > > +#define RTE_EVENT_TYPE_CRYPTODEV0x1 > > > > > > +/**< The event generated from crypodev subsystem */ > > > > > > +#define RTE_EVENT_TYPE_TIMERDEV 0x2 > > > > > > +/**< The event generated from timerdev subsystem */ > > > > > > +#define RTE_EVENT_TYPE_CORE 0x3 > > > > > > +/**< The event generated from core. > > > > > > > > > > What is core? > > > > > > > > The event are generated by lcore for pipeling. Any suggestion for > > > > better name? lcore? > > > > > > What about CPU or SW? > > > > No strong opinion here. I will go with CPU then > > > +1 for CPU (as SW is the software PMD name). > Fine, I'm outvoted. I'll learn to live with it. :-) /Bruce
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
Hi All,
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Friday, November 25, 2016 12:24 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; Richardson, Bruce ; Van
> Haaren, Harry
> ; hemant.agrawal at nxp.com; Eads, Gage
>
> Subject: Re: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven
> programming model
>
> On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote:
> > 2016-11-24 07:29, Jerin Jacob:
> > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
> > > > 2016-11-18 11:14, Jerin Jacob:
> > > > > +Eventdev API - EXPERIMENTAL
> > > > > +M: Jerin Jacob
> > > > > +F: lib/librte_eventdev/
> > > >
> > > > OK to mark it experimental.
> > > > What is the plan to remove the experimental word?
> > >
> > > IMO, EXPERIMENTAL status can be changed when
> > > - At least two event drivers available(Intel and Cavium are working on
> > > SW and HW event drivers)
> > > - Functional test applications are fine with at least two drivers
> > > - Portable example application to showcase the features of the library
> > > - eventdev integration with another dpdk subsystem such as ethdev
> > >
> > > Thoughts?. I am not sure the criteria used in cryptodev case.
> >
> > Sounds good.
> > We will be more confident when drivers and tests will be implemented.
> >
> > I think the roadmap for the SW driver targets the release 17.05.
> > Do you still plan 17.02 for this API and the Cavium driver?
>
> No. 17.02 too short for up-streaming the Cavium driver.However, I think API
> and
> skeleton event driver can go in 17.02 if there are no objections.
>
> >
> > > > > +#define EVENTDEV_NAME_SKELETON_PMD event_skeleton
> > > > > +/**< Skeleton event device PMD name */
> > > >
> > > > I do not understand this #define.
> > >
> > > Applications can explicitly request the a specific driver though driver
> > > name. This will go as argument to rte_event_dev_get_dev_id(const char
> > > *name).
> > > The reason for keeping this #define in rte_eventdev.h is that,
> > > application needs to include only rte_eventdev.h not rte_eventdev_pmd.h.
> >
> > So each driver must register its name in the API?
> > Is it really needed?
>
> Otherwise how application knows the name of the driver.
> The similar scheme used in cryptodev.
> http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev/rte_cryptodev.h#n53
> No strong opinion here. Open for suggestions.
>
> >
> > > > > +struct rte_event_dev_config {
> > > > > + uint32_t dequeue_wait_ns;
> > > > > + /**< rte_event_dequeue() wait for *dequeue_wait_ns* ns on this
> > > > > device.
> > > >
> > > > Please explain exactly when the wait occurs and why.
> > >
> > > Here is the explanation from rte_event_dequeue() API definition,
> > > -
> > > @param wait
> > > 0 - no-wait, returns immediately if there is no event.
> > > >0 - wait for the event, if the device is configured with
> > > RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait until
> > > the event available or *wait* time.
> > > if the device is not configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> > > then this function will wait until the event available or
> > > *dequeue_wait_ns*
> > >
> > > ^^
> > > ns which was previously supplied to rte_event_dev_configure()
> > > -
> > > This is provides the application to have control over, how long the
> > > implementation should wait if event is not available.
> > >
> > > Let me know what exact changes are required if details are not enough in
> > > rte_event_dequeue() API definition.
> >
> > Maybe that timeout would be a better name.
> > It waits only if there is nothing in the queue.
> > It can be interesting to highlight in this comment that this parameter
> > makes the dequeue function a blocking call.
>
> OK. I will change to timeout then
>
> >
> > > > > +/** Event port configuration structure */
> > > > > +struct rte_event_port_conf {
> > > > > + int32_t new_event_threshold;
> > > > > + /**< A backpressure threshold for new event enqueues on this
> > > > > port.
> > > > > + * Use for *closed system* event dev where event capacity is
> > > > > limited,
> > > > > + * and cannot exceed the capacity of the event dev.
> > > > > + * Configuring ports with different thresholds can make higher
> > > > > priority
> > > > > + * traffic less likely to be backpressured.
> > > > > + * For example, a port used to inject NIC Rx packets into the
> > > > > event dev
> > > > > + * can have a lower threshold so as not to overwhelm the device,
> > > > > + * while ports used for worker pools can have a higher
> > > > > threshold.
> > > > > + * This value cannot exceed the *nb_events_limit*
> > > > > + * which previously supplied to rte_event_dev_configure()
> > > > > + */
> > > > > + uint8_t dequeue_depth;
> > > > > + /**< Configure number of bulk dequeues for this event port.
> > > > > + *
[dpdk-dev] [PATCH v2] kni: avoid using lsb_release script
On 11/25/2016 11:33 AM, Robin Jarry wrote: > The lsb_release script is part of an optional package which is not > always installed. On the other hand, /etc/lsb-release is always present > even on minimal Ubuntu installations. > > root at ubuntu1604:~# dpkg -S /etc/lsb-release > base-files: /etc/lsb-release > > Read the file if present and use the variables defined in it. > > Signed-off-by: Robin Jarry > --- > lib/librte_eal/linuxapp/kni/Makefile | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_eal/linuxapp/kni/Makefile > b/lib/librte_eal/linuxapp/kni/Makefile > index 4e99e07e7aec..62a957ce8534 100644 > --- a/lib/librte_eal/linuxapp/kni/Makefile > +++ b/lib/librte_eal/linuxapp/kni/Makefile > @@ -44,8 +44,12 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include > -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e > MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h > MODULE_CFLAGS += -Wall -Werror > > -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) > -MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .) > +ifneq ($(wildcard /etc/lsb-release),) I mean removing this check completely, and having only below line, do you think does it works that way? > +-include /etc/lsb-release > +endif > + > +ifeq ($(DISTRIB_ID),Ubuntu) > +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(DISTRIB_RELEASE)) > UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE > $(RTE_KERNELDIR)/include/generated/utsrelease.h \ >| cut -d '"' -f2 | cut -d- -f1,2 | tr .- ,`,1) > MODULE_CFLAGS += > -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))" >
[dpdk-dev] [PATCH] kni: avoid using lsb_release script
On 11/25/2016 9:52 AM, Robin Jarry wrote: > The lsb_release script is part of an optional package which is not > always installed. On the other hand, /etc/lsb-release is always present > even on minimal Ubuntu installations. > > root at ubuntu1604:~# dpkg -S /etc/lsb-release > base-files: /etc/lsb-release > > Read the file if present and use the variables defined in it. > > Signed-off-by: Robin Jarry > --- > lib/librte_eal/linuxapp/kni/Makefile | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_eal/linuxapp/kni/Makefile > b/lib/librte_eal/linuxapp/kni/Makefile > index 4e99e07e7aec..63b9ac8779f8 100644 > --- a/lib/librte_eal/linuxapp/kni/Makefile > +++ b/lib/librte_eal/linuxapp/kni/Makefile > @@ -44,8 +44,12 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include > -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e > MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h > MODULE_CFLAGS += -Wall -Werror > > -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) > -MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .) > +ifneq ($(wildcard /etc/lsb-release),) > +include /etc/lsb-release > +endif What about: +-include /etc/lsb-release > + > +ifeq ($(DISTRIB_ID),Ubuntu) > +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(DISTRIB_ID)) s/DISTRIB_ID/DISTRIB_RELEASE > UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE > $(RTE_KERNELDIR)/include/generated/utsrelease.h \ >| cut -d '"' -f2 | cut -d- -f1,2 | tr .- ,`,1) > MODULE_CFLAGS += > -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))" >
[dpdk-dev] [PATCH] tools/dpdkdevbind.py: remove call to lower case for mod path
If the module path has upper case chars, the dpdk-devbind.py script will crunch them to lower case. This will result in the script never finding a module. Port patch to dpdk-1.7.0 dpdk_nic_bind.py has been renamed to dpdk-devbind.py in 16.11, so just change file name. Signed-off-by: Paul Barrette Signed-off-by: Pengyu Ma Signed-off-by: chunguang yang --- tools/dpdk-devbind.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/dpdk-devbind.py b/tools/dpdk-devbind.py index f1d374d..d66d68c 100755 --- a/tools/dpdk-devbind.py +++ b/tools/dpdk-devbind.py @@ -141,7 +141,7 @@ def find_module(mod): # check using depmod try: depmod_out = check_output(["modinfo", "-n", mod], - stderr=subprocess.STDOUT).lower() + stderr=subprocess.STDOUT) if "error" not in depmod_out: path = depmod_out.strip() if exists(path): -- 2.9.3
[dpdk-dev] [PATCH] tools/dpdkdevbind.py: remove call to lower case for mod path
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote:
> On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote:
> > 2016-11-24 07:29, Jerin Jacob:
> > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
> > > > 2016-11-18 11:14, Jerin Jacob:
> > > > > +Eventdev API - EXPERIMENTAL
> > > > > +M: Jerin Jacob
> > > > > +F: lib/librte_eventdev/
> > > >
> > > > OK to mark it experimental.
> > > > What is the plan to remove the experimental word?
> > >
> > > IMO, EXPERIMENTAL status can be changed when
> > > - At least two event drivers available(Intel and Cavium are working on
> > > SW and HW event drivers)
> > > - Functional test applications are fine with at least two drivers
> > > - Portable example application to showcase the features of the library
> > > - eventdev integration with another dpdk subsystem such as ethdev
> > >
> > > Thoughts?. I am not sure the criteria used in cryptodev case.
> >
> > Sounds good.
> > We will be more confident when drivers and tests will be implemented.
> >
> > I think the roadmap for the SW driver targets the release 17.05.
> > Do you still plan 17.02 for this API and the Cavium driver?
>
> No. 17.02 too short for up-streaming the Cavium driver.However, I think API
> and
> skeleton event driver can go in 17.02 if there are no objections.
>
> >
> > > > > +#define EVENTDEV_NAME_SKELETON_PMD event_skeleton
> > > > > +/**< Skeleton event device PMD name */
> > > >
> > > > I do not understand this #define.
> > >
> > > Applications can explicitly request the a specific driver though driver
> > > name. This will go as argument to rte_event_dev_get_dev_id(const char
> > > *name).
> > > The reason for keeping this #define in rte_eventdev.h is that,
> > > application needs to include only rte_eventdev.h not rte_eventdev_pmd.h.
> >
> > So each driver must register its name in the API?
> > Is it really needed?
>
> Otherwise how application knows the name of the driver.
> The similar scheme used in cryptodev.
> http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev/rte_cryptodev.h#n53
> No strong opinion here. Open for suggestions.
>
I like having a name registered. I think we need a scheme where an app
can find and use an implementation using a specific driver.
> >
> > > > > +struct rte_event_dev_config {
> > > > > + uint32_t dequeue_wait_ns;
> > > > > + /**< rte_event_dequeue() wait for *dequeue_wait_ns* ns on this
> > > > > device.
> > > >
> > > > Please explain exactly when the wait occurs and why.
> > >
> > > Here is the explanation from rte_event_dequeue() API definition,
> > > -
> > > @param wait
> > > 0 - no-wait, returns immediately if there is no event.
> > > >0 - wait for the event, if the device is configured with
> > > RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait until
> > > the event available or *wait* time.
> > > if the device is not configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> > > then this function will wait until the event available or
> > > *dequeue_wait_ns*
> > >
> > > ^^
> > > ns which was previously supplied to rte_event_dev_configure()
> > > -
> > > This is provides the application to have control over, how long the
> > > implementation should wait if event is not available.
> > >
> > > Let me know what exact changes are required if details are not enough in
> > > rte_event_dequeue() API definition.
> >
> > Maybe that timeout would be a better name.
> > It waits only if there is nothing in the queue.
> > It can be interesting to highlight in this comment that this parameter
> > makes the dequeue function a blocking call.
>
> OK. I will change to timeout then
>
> >
> > > > > +/** Event port configuration structure */
> > > > > +struct rte_event_port_conf {
> > > > > + int32_t new_event_threshold;
> > > > > + /**< A backpressure threshold for new event enqueues on this
> > > > > port.
> > > > > + * Use for *closed system* event dev where event capacity is
> > > > > limited,
> > > > > + * and cannot exceed the capacity of the event dev.
> > > > > + * Configuring ports with different thresholds can make higher
> > > > > priority
> > > > > + * traffic less likely to be backpressured.
> > > > > + * For example, a port used to inject NIC Rx packets into the
> > > > > event dev
> > > > > + * can have a lower threshold so as not to overwhelm the device,
> > > > > + * while ports used for worker pools can have a higher
> > > > > threshold.
> > > > > + * This value cannot exceed the *nb_events_limit*
> > > > > + * which previously supplied to rte_event_dev_configure()
> > > > > + */
> > > > > + uint8_t dequeue_depth;
> > > > > + /**< Configure number of bulk dequeues for this event port.
> > > > > + * This value cannot exceed the *nb_event_port_dequeue_depth*
> > > > > + * which previously supplied to rte_event_dev_configure()
[dpdk-dev] [PATCH] kni: avoid using lsb_release script
The lsb_release script is part of an optional package which is not always installed. On the other hand, /etc/lsb-release is always present even on minimal Ubuntu installations. root at ubuntu1604:~# dpkg -S /etc/lsb-release base-files: /etc/lsb-release Read the file if present and use the variables defined in it. Signed-off-by: Robin Jarry --- lib/librte_eal/linuxapp/kni/Makefile | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/linuxapp/kni/Makefile b/lib/librte_eal/linuxapp/kni/Makefile index 4e99e07e7aec..63b9ac8779f8 100644 --- a/lib/librte_eal/linuxapp/kni/Makefile +++ b/lib/librte_eal/linuxapp/kni/Makefile @@ -44,8 +44,12 @@ MODULE_CFLAGS += -I$(RTE_OUTPUT)/include -I$(SRCDIR)/ethtool/ixgbe -I$(SRCDIR)/e MODULE_CFLAGS += -include $(RTE_OUTPUT)/include/rte_config.h MODULE_CFLAGS += -Wall -Werror -ifeq ($(shell lsb_release -si 2>/dev/null),Ubuntu) -MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(shell lsb_release -sr | tr -d .) +ifneq ($(wildcard /etc/lsb-release),) +include /etc/lsb-release +endif + +ifeq ($(DISTRIB_ID),Ubuntu) +MODULE_CFLAGS += -DUBUNTU_RELEASE_CODE=$(subst .,,$(DISTRIB_ID)) UBUNTU_KERNEL_CODE := $(shell echo `grep UTS_RELEASE $(RTE_KERNELDIR)/include/generated/utsrelease.h \ | cut -d '"' -f2 | cut -d- -f1,2 | tr .- ,`,1) MODULE_CFLAGS += -D"UBUNTU_KERNEL_CODE=UBUNTU_KERNEL_VERSION($(UBUNTU_KERNEL_CODE))" -- 2.1.4
[dpdk-dev] [PATCH] doc: introduce PVP reference benchmark
Hi John, On 11/24/2016 06:38 PM, Mcnamara, John wrote: >> -Original Message- >> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com] >> Sent: Wednesday, November 23, 2016 9:00 PM >> To: yuanhan.liu at linux.intel.com; thomas.monjalon at 6wind.com; Mcnamara, >> John >> ; Yang, Zhiyong ; >> dev at dpdk.org >> Cc: fbaudin at redhat.com; Maxime Coquelin >> Subject: [PATCH] doc: introduce PVP reference benchmark >> >> Having reference benchmarks is important in order to obtain reproducible >> performance figures. >> >> This patch describes required steps to configure a PVP setup using testpmd >> in both host and guest. >> >> Not relying on external vSwitch ease integration in a CI loop by not being >> impacted by DPDK API changes. > > Hi Maxime, > > Thanks for the detailed doc and this initiative. Some minor documentation > comments below. > > > >> + >> +Setup overview >> +.. > > This level header should be -, even if it looks like dots in the > contribution guide: > > http://dpdk.org/doc/guides/contributing/documentation.html#section-headers > > >> + >> +.. figure:: img/pvp_2nics.svg >> + >> + PVP setup using 2 NICs >> + > > The figure needs a target so it can be used with :numref:, like this: > > .. _figure_pvp_2nics: > > .. figure:: img/pvp_2nics.* > >PVP setup using 2 NICs > > >> +DPDK build >> +~~ >> + > > Put a one line description at the start of each section, even if it is just: > Build DPDK: Ok. > > > >> +Testpmd launch >> +~~ >> + >> +#. Assign NICs to DPDK: >> + >> + .. code-block:: console >> + >> +modprobe vfio-pci >> +$RTE_SDK/install/sbin/dpdk-devbind -b vfio-pci :11:00.0 >> + :11:00.1 >> + >> +*Note: Sandy Bridge family seems to have some limitations wrt its >> +IOMMU, giving poor performance results. To achieve good performance on >> +these machines, consider using UIO instead.* > > This would be better as an RST note: > > #. Assign NICs to DPDK: > >.. code-block:: console > > modprobe vfio-pci > $RTE_SDK/install/sbin/dpdk-devbind -b vfio-pci :11:00.0 :11:00.1 > >.. Note:: > > The Sandy Bridge family seems to have some IOMMU limitations giving poor > performance results. To achieve good performance on these machines > consider using UIO instead. This is indeed better, thanks for the tip! About this note, I couldn't find official information about this problem. Do you confirm the issue, or I misconfigured something? I'll also add something about security implications of using UIO. > > > >> +First, SELinux policy needs to be set to permissiven, as testpmd is run >> +as root (reboot required): > > s/permissiven/permissive/ > > > There are a couple of trailing whitespace errors as well at build as well. Ok, I will rework all this. Thanks for the review, Maxime
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/24/2016 4:15 PM, Andrew Rybchenko wrote: > On 11/23/2016 06:29 PM, Ferruh Yigit wrote: >> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >>> The patch series adds Solarflare libefx-based network PMD. >>> >>> This version of the driver supports Solarflare SFN7xxx and SFN8xxx >>> families of 10/40 Gbps adapters. >>> >>> libefx is a platform-independent library to implement drivers for >>> Solarflare network adapters. It provides unified adapter family >>> independent interface (if possible). FreeBSD [1] and illumos [2] >>> drivers are built on top of the library. >>> >>> The patch series could be logically structured into 5 sub-series: >>> 1. (1) add the driver skeleton including documentation >>> 2. (2-30) import libefx and include it in build with the latest patch >>> 3. (31-43) implement minimal device level operations in steps >>> 4. (44-51) implement Rx subsystem >>> 5. (52-56) implement Tx subsystem >>> >>> Functional driver with multi-queue support capable to send and receive >>> traffic appears with the last patch in the series. >>> >>> The following design decisions are made during development: >>> >>> 1. Since libefx uses positive errno return codes, positive errno >>> return codes are used inside the driver and coversion to negative >>> is done on return from eth_dev_ops callbacks. We think that it >>> is the less error-prone way. >>> >>> 2. Another Solarflare PMD with in-kernel part (for control operations) >>> is considered and could be added in the future. Code for data path >>> should be shared by these two drivers. libefx-based PMD is put into >>> 'efx' subdirectory to have a space for another PMD and shared code. >>> >>> 3. Own event queue (a way to deliver events from HW to host CPU) is >>> used for house-keeping (e.g. link status notifications), each Tx >>> and each Rx queue. No locks on datapath are requires in this case. >>> >>> 4. Alarm is used to periodically poll house-keeping event queue. >>> The event queue is used to deliver link status change notifications, >>> Rx/Tx queue flush events, SRAM events. It is not used on datapath. >>> The event queue polling is protected using spin-lock since >>> concurrent access from different contexts is possible (e.g. device >>> stop when polling alarm is running). >>> >>> [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ >>> [2] >>> https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ >>> >>> --- >> I would like to note that very well organized patchset. Thank you for >> your effort. > > Thanks a lot, it is very pleasant to read it. > > Please, see my questions in thread for patches 01/56 (about compiler > versions to test on) and 30/56 (about libefx configuration documentation). > > Also I'd like to ask a question about the further patches submission. > We have about 40 patches which support various features (RSS, stats, > flow control and many others). What is the preferred way to submit it? > A. Separately since they are not so tightly related (but in fact cannot be > applied in random order since some touch the same lines in code) > B. As a series to process everything in one go. If they can't be applied in random order, it is better send as a patchset. But if you can make multiple logically independent patchsets with small effort, please do, smaller patchsets are easier to chew. > > Thanks, > Andrew.
[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD
On 11/23/2016 7:49 AM, Andrew Rybchenko wrote: > On 11/23/2016 03:02 AM, Ferruh Yigit wrote: >> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >>> The patch series adds Solarflare libefx-based network PMD. >>> >>> This version of the driver supports Solarflare SFN7xxx and SFN8xxx >>> families of 10/40 Gbps adapters. >>> >>> libefx is a platform-independent library to implement drivers for >>> Solarflare network adapters. It provides unified adapter family >>> independent interface (if possible). FreeBSD [1] and illumos [2] >>> drivers are built on top of the library. >>> >>> The patch series could be logically structured into 5 sub-series: >>> 1. (1) add the driver skeleton including documentation >>> 2. (2-30) import libefx and include it in build with the latest patch >>> 3. (31-43) implement minimal device level operations in steps >>> 4. (44-51) implement Rx subsystem >>> 5. (52-56) implement Tx subsystem >>> >>> Functional driver with multi-queue support capable to send and receive >>> traffic appears with the last patch in the series. >>> >>> The following design decisions are made during development: >>> >>> 1. Since libefx uses positive errno return codes, positive errno >>> return codes are used inside the driver and coversion to negative >>> is done on return from eth_dev_ops callbacks. We think that it >>> is the less error-prone way. >>> >>> 2. Another Solarflare PMD with in-kernel part (for control operations) >>> is considered and could be added in the future. Code for data path >>> should be shared by these two drivers. libefx-based PMD is put into >>> 'efx' subdirectory to have a space for another PMD and shared code. >>> >>> 3. Own event queue (a way to deliver events from HW to host CPU) is >>> used for house-keeping (e.g. link status notifications), each Tx >>> and each Rx queue. No locks on datapath are requires in this case. >>> >>> 4. Alarm is used to periodically poll house-keeping event queue. >>> The event queue is used to deliver link status change notifications, >>> Rx/Tx queue flush events, SRAM events. It is not used on datapath. >>> The event queue polling is protected using spin-lock since >>> concurrent access from different contexts is possible (e.g. device >>> stop when polling alarm is running). >>> >>> [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/ >>> [2] >>> https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/ >>> >>> --- >>> >>> Andrew Rybchenko (49): >>>net/sfc: libefx-based PMD stub sufficient to build and init >>>net/sfc: import libefx base >>>net/sfc: import libefx register definitions >>>net/sfc: import libefx filters support >>>net/sfc: import libefx MCDI definition >>>net/sfc: import libefx MCDI implementation >>>net/sfc: import libefx MCDI logging support >>>net/sfc: import libefx MCDI proxy authorization support >>>net/sfc: import libefx 5xxx/6xxx family support >>>net/sfc: import libefx SFN7xxx family support >>>net/sfc: import libefx SFN8xxx family support >>>net/sfc: import libefx diagnostics support >>>net/sfc: import libefx built-in selftest support >>>net/sfc: import libefx software per-queue statistics support >>>net/sfc: import libefx PHY flags control support >>>net/sfc: import libefx PHY statistics support >>>net/sfc: import libefx PHY LEDs control support >>>net/sfc: import libefx MAC statistics support >>>net/sfc: import libefx event prefetch support >>>net/sfc: import libefx Rx scatter support >>>net/sfc: import libefx RSS support >>>net/sfc: import libefx loopback control support >>>net/sfc: import libefx monitors statistics support >>>net/sfc: import libefx support to access monitors via MCDI >>>net/sfc: import libefx support for Rx packed stream mode >>>net/sfc: import libefx NVRAM support >>>net/sfc: import libefx VPD support >>>net/sfc: import libefx bootrom configuration support >>>net/sfc: import libefx licensing support >>>net/sfc: implement dummy callback to get device information >>>net/sfc: implement driver operation to init device on attach >>>net/sfc: add device configure and close stubs >>>net/sfc: add device configuration checks >>>net/sfc: implement device start and stop operations >>>net/sfc: make available resources estimation and allocation >>>net/sfc: interrupts support sufficient for event queue init >>>net/sfc: implement event queue support >>>net/sfc: implement EVQ dummy exception handling >>>net/sfc: maintain management event queue >>>net/sfc: periodic management EVQ polling using alarm >>>net/sfc: minimum port control sufficient to receive traffic >>>net/sfc: implement Rx subsystem stubs >>>net/sfc: check configured rxmode >>>net/sfc: implement Rx queue setup release operations >>>net/sfc: calculate Rx buffer siz
[dpdk-dev] [PATCH 30/56] net/sfc: include libefx in build
On 11/24/2016 3:44 PM, Andrew Rybchenko wrote: > See one question below. > > On 11/23/2016 06:26 PM, Ferruh Yigit wrote: >> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >>> From: Artem Andreev >>> >>> Implement efsys.h for the PMD. >>> >>> Reviewed-by: Andy Moreton >>> Signed-off-by: Artem Andreev >>> Signed-off-by: Andrew Rybchenko >>> --- >>> drivers/net/sfc/efx/Makefile | 54 +++ >>> drivers/net/sfc/efx/efsys.h | 767 >>> +++ >>> 2 files changed, 821 insertions(+) >>> create mode 100644 drivers/net/sfc/efx/efsys.h >>> >>> diff --git a/drivers/net/sfc/efx/Makefile b/drivers/net/sfc/efx/Makefile >>> index 71f07ca..de95ea8 100644 >>> --- a/drivers/net/sfc/efx/Makefile >>> +++ b/drivers/net/sfc/efx/Makefile >>> @@ -33,6 +33,8 @@ include $(RTE_SDK)/mk/rte.vars.mk >>> # >>> LIB = librte_pmd_sfc_efx.a >>> >>> +CFLAGS += -I$(SRCDIR)/base/ >>> +CFLAGS += -I$(SRCDIR) >>> CFLAGS += -O3 >>> >>> # Enable basic warnings but disable some which are accepted >>> @@ -60,6 +62,17 @@ CFLAGS += -Wstrict-prototypes >>> CFLAGS += -Wundef >>> CFLAGS += -Wwrite-strings >>> >>> +# Extra CFLAGS for base driver files >>> +CFLAGS_BASE_DRIVER += -Wno-unused-variable >>> +CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable >> clang complain about this one: >> warning: unknown warning option '-Wno-unused-but-set-variable'; did you >> mean '-Wno-unused-const-variable'? [-Wunknown-warning-option] > > Will fix in v2 > >>> + >>> +# >>> +# List of base driver object files for which >>> +# special CFLAGS above should be applied >>> +# >>> +BASE_DRIVER_OBJS=$(patsubst %.c,%.o,$(notdir $(wildcard >>> $(SRCDIR)/base/*.c))) >>> +$(foreach obj, $(BASE_DRIVER_OBJS), $(eval CFLAGS+=$(CFLAGS_BASE_DRIVER))) >> This cause multiple "-Wno-unused-variable -Wno-unused-but-set-variable" >> params in final command, I guess the intention is: >> >> $(foreach obj, $(BASE_DRIVER_OBJS), $(eval >> CFLAGS_$(obj)+=$(CFLAGS_BASE_DRIVER))) >> >> Fixing this may generate a few compiler warnings. > > Many thanks, will fix in v2. > >> <...> >> >>> diff --git a/drivers/net/sfc/efx/efsys.h b/drivers/net/sfc/efx/efsys.h >>> new file mode 100644 >>> index 000..2eef996 >>> --- /dev/null >>> +++ b/drivers/net/sfc/efx/efsys.h >>> @@ -0,0 +1,767 @@ >> <...> >> >> I guess below is hardcoded compile time configuration for libefx, do you >> think does it make sense to document this default configuration? > > Yes, it is libefx configuration and more options will be enabled when > corresponding > functionality is supported in the PMD. > I'm sorry, but I don't understand what would you like to see in the > documentation. > Could you clarify, please? This is mostly a question, following defines how libefx behaves, and a little hard to find, do you think does it make sense to document these in nic documentation, guides/nics/sfc_efx.rst, to highlight default configuration. Like by default filtering capabilities and SFN7xxx family support enabled but 5xxx/6xxx family support disabled... These can be listed in a bullet listed way in two groups (default enabled / default disabled) ? > >>> + >>> +#defineEFSYS_OPT_NAMES 0 >>> + >>> +#defineEFSYS_OPT_SIENA 0 >>> +#defineEFSYS_OPT_HUNTINGTON 1 >>> +#defineEFSYS_OPT_MEDFORD 1 >>> +#ifdef RTE_LIBRTE_SFC_EFX_DEBUG >>> +#defineEFSYS_OPT_CHECK_REG 1 >>> +#else >>> +#defineEFSYS_OPT_CHECK_REG 0 >>> +#endif >>> + >>> +#defineEFSYS_OPT_MCDI 1 >>> +#defineEFSYS_OPT_MCDI_LOGGING 0 >>> +#defineEFSYS_OPT_MCDI_PROXY_AUTH 0 >>> + >>> +#defineEFSYS_OPT_MAC_STATS 0 >>> + >>> +#defineEFSYS_OPT_LOOPBACK 0 >>> + >>> +#defineEFSYS_OPT_MON_MCDI 0 >>> +#defineEFSYS_OPT_MON_STATS 0 >>> + >>> +#defineEFSYS_OPT_PHY_STATS 0 >>> +#defineEFSYS_OPT_BIST 0 >>> +#defineEFSYS_OPT_PHY_LED_CONTROL 0 >>> +#defineEFSYS_OPT_PHY_FLAGS 0 >>> + >>> +#defineEFSYS_OPT_VPD 0 >>> +#defineEFSYS_OPT_NVRAM 0 >>> +#defineEFSYS_OPT_BOOTCFG 0 >>> + >>> +#defineEFSYS_OPT_DIAG 0 >>> +#defineEFSYS_OPT_RX_SCALE 0 >>> +#defineEFSYS_OPT_QSTATS 0 >>> +#defineEFSYS_OPT_FILTER 1 >>> +#defineEFSYS_OPT_RX_SCATTER 0 >>> + >>> +#defineEFSYS_OPT_EV_PREFETCH 0 >>> + >>> +#defineEFSYS_OPT_DECODE_INTR_FATAL 0 >>> + >>> +#defineEFSYS_OPT_LICENSING 0 >>> + >>> +#defineEFSYS_OPT_ALLOW_UNCONFIGURED_NIC 0 >>> + >>> +#defineEFSYS_OPT_RX_PACKED_STREAM 0 >> <...> > >
[dpdk-dev] [PATCH 01/56] net/sfc: libefx-based PMD stub sufficient to build and init
On 11/24/2016 3:59 PM, Andrew Rybchenko wrote: > On 11/23/2016 06:26 PM, Ferruh Yigit wrote: >> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: >>> The PMD is put into the sfc/efx subdirectory to have a place for >>> the second PMD and library shared by both. >>> >>> Enable the PMD by default on supported configuratons. >>> >>> Reviewed-by: Andy Moreton >>> Signed-off-by: Andrew Rybchenko >>> --- >>> MAINTAINERS | 6 ++ >>> config/common_base | 6 ++ >>> config/defconfig_arm-armv7a-linuxapp-gcc| 1 + >>> config/defconfig_arm64-armv8a-linuxapp-gcc | 1 + >>> config/defconfig_i686-native-linuxapp-gcc | 5 + >>> config/defconfig_i686-native-linuxapp-icc | 5 + >>> config/defconfig_ppc_64-power8-linuxapp-gcc | 1 + >>> config/defconfig_tile-tilegx-linuxapp-gcc | 1 + >>> config/defconfig_x86_64-native-linuxapp-icc | 5 + >>> config/defconfig_x86_x32-native-linuxapp-gcc| 5 + >>> doc/guides/nics/features/sfc_efx.ini| 10 ++ >>> doc/guides/nics/index.rst | 1 + >>> doc/guides/nics/sfc_efx.rst | 109 >>> + >> Can you also update release notes please, to announce new driver. > > Thanks, will do in v2. > >> <...> >> >>> diff --git a/drivers/net/sfc/efx/Makefile b/drivers/net/sfc/efx/Makefile >>> new file mode 100644 >>> index 000..71f07ca >>> --- /dev/null >>> +++ b/drivers/net/sfc/efx/Makefile >>> @@ -0,0 +1,81 @@ >> <...> >>> + >>> +include $(RTE_SDK)/mk/rte.vars.mk >>> + >>> +# >>> +# library name >>> +# >>> +LIB = librte_pmd_sfc_efx.a >>> + >>> +CFLAGS += -O3 >>> + >>> +# Enable basic warnings but disable some which are accepted >>> +CFLAGS += -Wall >> It is possible to use $(WERROR_FLAGS), which set automatically based on >> selected compiler. See mk/toolchain/* . > > Thanks, will do in v2. > >> And you can add extra options here, please keep in mind that there are >> three compiler supported right now: gcc, clang and icc. You may require >> to add compiler and version checks.. > > I've tried to disable the driver build on ICC since we've never tested it. I believe we don't support selective config per compiler. Currently if a code is enabled by default, it should support compilation with all three compilers. > I've failed to find list of compiler versions which must/should be checked. That list is not clear as far as I know. Mostly version related fixes added based on reported build errors. So you can leave as it is right now, or can test with default compiler versions of some common distributions. > I've tested versions which come with RHEL 7.2, Debian Jessie and Sid. > (In v1 I've lost my fixes for clang which produce warnings because of > unsupported -W option) > >>> +CFLAGS += -Wno-strict-aliasing >>> + >>> +# Enable extra warnings but disable some which are accepted >>> +CFLAGS += -Wextra >>> +CFLAGS += -Wno-empty-body >>> +CFLAGS += -Wno-sign-compare >>> +CFLAGS += -Wno-type-limits >>> +CFLAGS += -Wno-unused-parameter >> Is there a way to not disable these warnings but fix in the source code? >> Or move to CFLAGS_BASE_DRIVER, if the reason is the base driver? > > Will do in v2. > >>> + >>> +# More warnings not enabled by above aggregators >>> +CFLAGS += -Waggregate-return >>> +CFLAGS += -Wbad-function-cast >>> +CFLAGS += -Wcast-qual >>> +CFLAGS += -Wdisabled-optimization >>> +CFLAGS += -Wmissing-declarations >>> +CFLAGS += -Wmissing-prototypes >>> +CFLAGS += -Wnested-externs >>> +CFLAGS += -Wold-style-definition >>> +CFLAGS += -Wpointer-arith >>> +CFLAGS += -Wstrict-prototypes >>> +CFLAGS += -Wundef >>> +CFLAGS += -Wwrite-strings >> If you believe some can be useful for everybody, please feel free to add >> to mk/toolchain/* . > > I'll definitely remove duplicates which are already included in > $(WERROR_FLAGS). > I'd prefer to keep the rest just here for now. I think that adding it > world-wide > requires testing on really many compiler versions etc. > >>> + >>> +EXPORT_MAP := rte_pmd_sfc_efx_version.map >>> + >>> +LIBABIVER := 1 >>> + >>> +# >>> +# all source are stored in SRCS-y >>> +# >>> +SRCS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += sfc_ethdev.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += sfc_kvargs.c >>> + >>> + >>> +# this lib depends upon: >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += lib/librte_eal >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += lib/librte_kvargs >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += lib/librte_ether >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += lib/librte_mempool >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += lib/librte_mbuf >>> + >>> +include $(RTE_SDK)/mk/rte.lib.mk >>> diff --git a/drivers/net/sfc/efx/rte_pmd_sfc_efx_version.map >>> b/drivers/net/sfc/efx/rte_pmd_sfc_efx_version.map >>> new file mode 100644 >>> index 000..1901bcb >>> --- /dev/null >>> +++ b/drivers/net/sfc/efx/rte_pmd_sfc_efx_version.map >>> @@ -0,0
[dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs
> -Original Message-
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Friday, November 25, 2016 4:18 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; Richardson, Bruce ; Van
> Haaren, Harry ; hemant.agrawal at nxp.com;
> Eads,
> Gage
> Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the northbound
> APIs
>
> On Wed, Nov 23, 2016 at 08:18:09PM +0100, Thomas Monjalon wrote:
> > 2016-11-18 11:15, Jerin Jacob:
> > > This patch set defines the southbound driver interface and
> > > implements the common code required for northbound eventdev API
> > > interface.
> >
> > Please make two separate patches.
>
> OK
>
> >
> > > +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> > > +#define RTE_PMD_DEBUG_TRACE(...) \
> > > + rte_pmd_debug_trace(__func__, __VA_ARGS__) #else #define
> > > +RTE_PMD_DEBUG_TRACE(...) #endif
> >
> > I would like to discuss the need for a debug option as there is
> > already a log level.
>
> IMO, we don't need this. However, RTE_FUNC_PTR_OR_ERR_RET needs the
> definition of RTE_PMD_DEBUG_TRACE inorder to compile. I think we can
> remove it when it get fixed in EAL layer.
>
> >
> > > +/* Logging Macros */
> > > +#define EDEV_LOG_ERR(fmt, args...) \
> >
> > Every symbols and macros in an exported header must be prefixed by RTE_.
> >
> OK. I will fix it
>
> > > +/* Macros to check for valid device */ #define
> > > +RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, retval) do { \
> >
> > Sometimes you use RTE_EVENT_DEV_ and sometimes RTE_EVENTDEV.
> > (I prefer the latter).
>
> I choose the naming conversion based on the interface. API side it is
> rte_event_ and driver side it is rte_eventdev_*
>
> rte_event_dev_count;
> rte_event_dev_get_dev_id
> rte_event_dev_socket_id;
> rte_event_dev_info_get;
> rte_event_dev_configure;
> rte_event_dev_start;
> rte_event_dev_stop;
> rte_event_dev_close;
> rte_event_dev_dump;
>
> rte_event_port_default_conf_get;
> rte_event_port_setup;
> rte_event_port_dequeue_depth;
> rte_event_port_enqueue_depth;
> rte_event_port_count;
> rte_event_port_link;
> rte_event_port_unlink;
> rte_event_port_links_get;
>
> rte_event_queue_default_conf_get
> rte_event_queue_setup;
> rte_event_queue_count;
> rte_event_queue_priority;
>
> rte_event_dequeue_wait_time;
>
> rte_eventdev_pmd_allocate;
> rte_eventdev_pmd_release;
> rte_eventdev_pmd_vdev_init;
> rte_eventdev_pmd_pci_probe;
> rte_eventdev_pmd_pci_remove;
For this last set, you probably are ok prefixing with just "rte_event_pmd_",
and drop the "dev" as unnecessary. That makes everything have a prefix of
"rte_event_" and thereafter dev, port, queue, or pmd as appropriate.
/Bruce
[dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs
On Wed, Nov 23, 2016 at 08:18:09PM +0100, Thomas Monjalon wrote:
> 2016-11-18 11:15, Jerin Jacob:
> > This patch set defines the southbound driver interface
> > and implements the common code required for northbound
> > eventdev API interface.
>
> Please make two separate patches.
OK
>
> > +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG
> > +#define RTE_PMD_DEBUG_TRACE(...) \
> > + rte_pmd_debug_trace(__func__, __VA_ARGS__)
> > +#else
> > +#define RTE_PMD_DEBUG_TRACE(...)
> > +#endif
>
> I would like to discuss the need for a debug option as there is
> already a log level.
IMO, we don't need this. However, RTE_FUNC_PTR_OR_ERR_RET needs the
definition of RTE_PMD_DEBUG_TRACE inorder to compile. I think we can
remove it when it get fixed in EAL layer.
>
> > +/* Logging Macros */
> > +#define EDEV_LOG_ERR(fmt, args...) \
>
> Every symbols and macros in an exported header must be prefixed by RTE_.
>
OK. I will fix it
> > +/* Macros to check for valid device */
> > +#define RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, retval) do { \
>
> Sometimes you use RTE_EVENT_DEV_ and sometimes RTE_EVENTDEV.
> (I prefer the latter).
I choose the naming conversion based on the interface. API side it
is rte_event_ and driver side it is rte_eventdev_*
rte_event_dev_count;
rte_event_dev_get_dev_id
rte_event_dev_socket_id;
rte_event_dev_info_get;
rte_event_dev_configure;
rte_event_dev_start;
rte_event_dev_stop;
rte_event_dev_close;
rte_event_dev_dump;
rte_event_port_default_conf_get;
rte_event_port_setup;
rte_event_port_dequeue_depth;
rte_event_port_enqueue_depth;
rte_event_port_count;
rte_event_port_link;
rte_event_port_unlink;
rte_event_port_links_get;
rte_event_queue_default_conf_get
rte_event_queue_setup;
rte_event_queue_count;
rte_event_queue_priority;
rte_event_dequeue_wait_time;
rte_eventdev_pmd_allocate;
rte_eventdev_pmd_release;
rte_eventdev_pmd_vdev_init;
rte_eventdev_pmd_pci_probe;
rte_eventdev_pmd_pci_remove;
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote:
> 2016-11-24 07:29, Jerin Jacob:
> > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
> > > 2016-11-18 11:14, Jerin Jacob:
> > > > +Eventdev API - EXPERIMENTAL
> > > > +M: Jerin Jacob
> > > > +F: lib/librte_eventdev/
> > >
> > > OK to mark it experimental.
> > > What is the plan to remove the experimental word?
> >
> > IMO, EXPERIMENTAL status can be changed when
> > - At least two event drivers available(Intel and Cavium are working on
> > SW and HW event drivers)
> > - Functional test applications are fine with at least two drivers
> > - Portable example application to showcase the features of the library
> > - eventdev integration with another dpdk subsystem such as ethdev
> >
> > Thoughts?. I am not sure the criteria used in cryptodev case.
>
> Sounds good.
> We will be more confident when drivers and tests will be implemented.
>
> I think the roadmap for the SW driver targets the release 17.05.
> Do you still plan 17.02 for this API and the Cavium driver?
No. 17.02 too short for up-streaming the Cavium driver.However, I think API and
skeleton event driver can go in 17.02 if there are no objections.
>
> > > > +#define EVENTDEV_NAME_SKELETON_PMD event_skeleton
> > > > +/**< Skeleton event device PMD name */
> > >
> > > I do not understand this #define.
> >
> > Applications can explicitly request the a specific driver though driver
> > name. This will go as argument to rte_event_dev_get_dev_id(const char
> > *name).
> > The reason for keeping this #define in rte_eventdev.h is that,
> > application needs to include only rte_eventdev.h not rte_eventdev_pmd.h.
>
> So each driver must register its name in the API?
> Is it really needed?
Otherwise how application knows the name of the driver.
The similar scheme used in cryptodev.
http://dpdk.org/browse/dpdk/tree/lib/librte_cryptodev/rte_cryptodev.h#n53
No strong opinion here. Open for suggestions.
>
> > > > +struct rte_event_dev_config {
> > > > + uint32_t dequeue_wait_ns;
> > > > + /**< rte_event_dequeue() wait for *dequeue_wait_ns* ns on this
> > > > device.
> > >
> > > Please explain exactly when the wait occurs and why.
> >
> > Here is the explanation from rte_event_dequeue() API definition,
> > -
> > @param wait
> > 0 - no-wait, returns immediately if there is no event.
> > >0 - wait for the event, if the device is configured with
> > RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT then this function will wait until
> > the event available or *wait* time.
> > if the device is not configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT
> > then this function will wait until the event available or *dequeue_wait_ns*
> > ^^
> > ns which was previously supplied to rte_event_dev_configure()
> > -
> > This is provides the application to have control over, how long the
> > implementation should wait if event is not available.
> >
> > Let me know what exact changes are required if details are not enough in
> > rte_event_dequeue() API definition.
>
> Maybe that timeout would be a better name.
> It waits only if there is nothing in the queue.
> It can be interesting to highlight in this comment that this parameter
> makes the dequeue function a blocking call.
OK. I will change to timeout then
>
> > > > +/** Event port configuration structure */
> > > > +struct rte_event_port_conf {
> > > > + int32_t new_event_threshold;
> > > > + /**< A backpressure threshold for new event enqueues on this
> > > > port.
> > > > +* Use for *closed system* event dev where event capacity is
> > > > limited,
> > > > +* and cannot exceed the capacity of the event dev.
> > > > +* Configuring ports with different thresholds can make higher
> > > > priority
> > > > +* traffic less likely to be backpressured.
> > > > +* For example, a port used to inject NIC Rx packets into the
> > > > event dev
> > > > +* can have a lower threshold so as not to overwhelm the device,
> > > > +* while ports used for worker pools can have a higher
> > > > threshold.
> > > > +* This value cannot exceed the *nb_events_limit*
> > > > +* which previously supplied to rte_event_dev_configure()
> > > > +*/
> > > > + uint8_t dequeue_depth;
> > > > + /**< Configure number of bulk dequeues for this event port.
> > > > +* This value cannot exceed the *nb_event_port_dequeue_depth*
> > > > +* which previously supplied to rte_event_dev_configure()
> > > > +*/
> > > > + uint8_t enqueue_depth;
> > > > + /**< Configure number of bulk enqueues for this event port.
> > > > +* This value cannot exceed the *nb_event_port_enqueue_depth*
> > > > +* which previously supplied to rte_event_dev_configure()
> > > > +*/
> > > > +};
> > >
> > > The depth configuration is not clear to me.
> >
> > Ba
[dpdk-dev] [PATCH] lpm: rte_lpm_iterate() - iterate through the routes
From: J?rgen Grahn
In practice, there's a need to iterate through the entries
of a rte_lpm, apart from the usual insert/delete/lookup
operations. This is useful for debugging and perhaps for
things like removing all entries referencing a certain nexthop.
This patch implements this through rte_lpm_iterate(), which
uses a cursor (or iterator) to keep track of the current
position. Client code doesn't need to be aware of rte_lpm
implementation details.
Change-Id: I28ea3d7d92f318988444553ee2bb30b709bcb3b6
Signed-off-by: Jorgen Grahn
Signed-off-by: alloc
---
lib/librte_lpm/Makefile | 4 +-
lib/librte_lpm/rte_lpm_iterate.c | 81
lib/librte_lpm/rte_lpm_iterate.h | 56 +++
3 files changed, 139 insertions(+), 2 deletions(-)
create mode 100644 lib/librte_lpm/rte_lpm_iterate.c
create mode 100644 lib/librte_lpm/rte_lpm_iterate.h
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 3dc549d..c45da19 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -42,10 +42,10 @@ EXPORT_MAP := rte_lpm_version.map
LIBABIVER := 2
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c
+SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c rte_lpm_iterate.c
# install this header file
-SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include := rte_lpm.h rte_lpm6.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include := rte_lpm.h rte_lpm6.h
rte_lpm_iterate.h
ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_neon.h
diff --git a/lib/librte_lpm/rte_lpm_iterate.c b/lib/librte_lpm/rte_lpm_iterate.c
new file mode 100644
index 000..f643764
--- /dev/null
+++ b/lib/librte_lpm/rte_lpm_iterate.c
@@ -0,0 +1,81 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2014 J?rgen Grahn. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of 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.
+ */
+#include "rte_lpm_iterate.h"
+#include "rte_lpm.h"
+
+#include
+
+
+/**
+ * Iterate through the lpm, pulling out at most 'buflen' valid routes
+ * (less means we've hit the end). The cursor should be initialized
+ * to { 0, 0 } before the first call.
+ *
+ * The routes are partially sorted, by prefix length. Undefined
+ * results if the lpm is modified in parallel with or inbetween calls,
+ * although the iteration will still terminate properly.
+ */
+unsigned
+rte_lpm_iterate(struct rte_lpm_route* const buf, unsigned buflen,
+ const struct rte_lpm* lpm,
+ struct rte_lpm_cursor* const cursor)
+{
+ struct rte_lpm_route* p = buf;
+ struct rte_lpm_route* const end = p + buflen;
+
+ const struct rte_lpm_rule_info* const rinfo = lpm->rule_info;
+ const struct rte_lpm_rule* const rtbl = lpm->rules_tbl;
+
+ unsigned d = cursor->d;
+ unsigned n = cursor->n;
+
+ while(p!=end) {
+ if(d==32) break;
+ if(n>=rinfo[d].used_rules) {
+ d++;
+ n = 0;
+ continue;
+ }
+ const struct rte_lpm_rule rule = rtbl[rinfo[d].first_rule + n];
+ p->addr.s_addr = htonl(rule.ip);
+ p->plen = d+1;
+ p->nh = rule.next_hop;
+ p++;
+ n++;
+ }
+
+ cursor->d = d;
+ cursor->n = n;
+
+ return p - buf;
+}
d
[dpdk-dev] [PATCH 1/4] eventdev: introduce event driven programming model
On Thu, Nov 24, 2016 at 04:24:11PM +, Bruce Richardson wrote: > On Fri, Nov 18, 2016 at 11:14:59AM +0530, Jerin Jacob wrote: > > In a polling model, lcores poll ethdev ports and associated > > rx queues directly to look for packet. In an event driven model, > > by contrast, lcores call the scheduler that selects packets for > > them based on programmer-specified criteria. Eventdev library > > adds support for event driven programming model, which offer > > applications automatic multicore scaling, dynamic load balancing, > > pipelining, packet ingress order maintenance and > > synchronization services to simplify application packet processing. > > > > By introducing event driven programming model, DPDK can support > > both polling and event driven programming models for packet processing, > > and applications are free to choose whatever model > > (or combination of the two) that best suits their needs. > > > > Signed-off-by: Jerin Jacob > > --- > > Hi Jerin, > > Thanks for the patchset. A few minor comments in general on the API that > we found from working with it (thus far - more may follow :-) ). Thanks Bruce. > > 1. Priorities: priorities are used in a number of places in the API, but >all are uint8_t types and have their own MAX/NORMAL/MIN values. I think >it would be simpler for the user just to have one priority type in the >library, and use that everywhere. I suggest using RTE_EVENT_PRIORITY_* >and drop the separate defines for SERVICE_PRIORITY, and QUEUE_PRIORITY >etc. Ideally, I'd see things like this converted to enums too, rather >than defines, but I'm not sure it's possible in this case. OK. I will address it in v2 > > 2. Functions for config and setup can have their structure parameter >types as const as they don't/shouldn't change the values internally. >So add "const" to parameters to: > rte_event_dev_configure() > rte_event_queue_setup() > rte_event_port_setup() > rte_event_port_link() > OK. I will address it in v2 > 3. in event schedule() function, the dev->schedule() function needs the >dev instance pointer passed in as parameter. OK. I will address it in v2 > > 4. The event op values and the event type values would be better as >enums rather than as a set of #defines. OK. I will address it in v2 I will reply to your other comments in Thomas's email. > > Regards, > /Bruce
