[dpdk-dev] Getting meta data from different pipelines in ip_pipeline application
Hi, This is how I want my pipelines to work:- Pipeline 4: Has to get the source mac address and save it in 160th(160-167) meta data filed in the mbuf. Pipeline 5: Will take the vlan id and store it in 168th(168-175) offset of the same mbuf Pipeline 6: Take the incoming port id which is in 23rd position of the mbuf and store it in 175th offset. (It will overlap with vlan id field stored, but since I need only that one bit and I have to access all the three fileds together as a 16 bit key value, I have done this overlapping) Pipeline 7: Key offset is given as 160 and key size is given as 16. So that 160 to 175 will be available as we have stored those in meta data in the previous three pipelines. I want to know whether my logic will work if I write the config file as shown below. Will pipeline 7 be able to get the stored source mac address, vlan id and port id from the given key offset? [PIPELINE4] .. .. dma_size = 8 dma_dst_offset = 160 dma_src_offset = 262 dma_src_mask = dma_hash_offset = 192 [PIPELINE5] .. .. dma_size = 8 dma_dst_offset = 168 dma_src_offset = 268 dma_src_mask = 0FFF dma_hash_offset = 200 [PIPELINE6] .. .. dma_size = 8 dma_dst_offset = 175 dma_src_offset = 23 dma_src_mask = FF00 dma_hash_offset = 208 [PIPELINE7] .. .. key_size = 16 key_offset = 160 key_mask = 0FFF00FF .. Thanks for your reply and help. Regards, Nidhia Varghese
Re: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver.
Hi Jeff,
A few comments below:
On Sun, May 28, 2017 at 11:44:40PM +0800, Jeff Guo wrote:
For HW hotplug feature, we had already got upstream that removal event adding
from 6wind as bellow.
dependency of “add device removal event” patch set:
http://dpdk.org/dev/patchwork/patch/23693/
[dpdk-dev,v2,1/5] ethdev: introduce device removal event
http://dpdk.org/dev/patchwork/patch/23694/
[dpdk-dev,v2,2/5] net/mlx4: device removal event support
http://dpdk.org/dev/patchwork/patch/23695/
[dpdk-dev,v2,3/5] app/testpmd: generic event handler
http://dpdk.org/dev/patchwork/patch/23696/
[dpdk-dev,v2,4/5] app/testpmd: request link status interrupt
http://dpdk.org/dev/patchwork/patch/23697/
[dpdk-dev,v2,5/5] app/testpmd: request device removal interrupt
From the patches, we can see a new event type “RTE_ETH_DEV_INTR_RMV” has been
added into the ethdev, and the event has been implemented in mlx4 driver, and
Testpmd be use for testing purposes and as a practical usage example for how to
use these event. The progress is use the mlx4 driver to register interrupt
callback function to rte eal interrupt source, and when rte epolling detect the
IBV_EVENT_DEVICE_FATAL , which is identify the device remove behavior, it will
callback into the driver’s interrupt handle to handle it, and then callback to
the user app, such as testpmd, to detach the pci device.
So far, except the mlx4 driver, other driver like i40, that not have the remove
interrupt from hw, will not be able to monitoring the remove behavior, so in
order to expand the hot plug feature for all driver cases, something must be
done ot detect the remove event at the kernel level and offer a new line of
interrupt to the userland. The idea is coming as below.
It's nice that this event is extended to other drivers.
Use I40e as example, we know that the rmv interrupt is not added in hw, but we
could monitor the uio file descriptor to catch the device remove event as
bellow.
The info of uevent form FD monitoring:
remove@/devices/pci:80/:80:02.2/:82:00.0/:83:03.0/:84:00.2/uio/uio2
ACTION=remove
DEVPATH=/devices/pci:80/:80:02.2/:82:00.0/:83:03.0/:84:00.2/uio/uio2
SUBSYSTEM=uio
MAJOR=243
MINOR=2
DEVNAME=uio2
SEQNUM=11366
Firstly, in order to monitor the uio file descriptor, we need to create socket
to monitor the uio fd, that is defined as “hotplug_fd”, and then add the uio fd
into the epoll fd list, rte eal could epoll all of the interrupt event from hw
interrupt and also include the uevent from hotplug_fd.
Secondly, in order to read out the uevent that monitoring, we need to add
uevent API in rte layer. We plan add 2 , rte_uevent_connect and
rte_get_uevent. All driver interrupt handler could use these API to enable the
uevent monitoring, and read out the uevent type , then corresponding to handle
these uevent, such as detach the device when get the remove type.
I find having a generic uevent API interesting.
However, all specifics pertaining to UIO use (hotplug_fd, subsystem
enum) should stay in UIO specific code (eal_pci_uio.c?).
I am currently moving the PCI bus out of the EAL. EAL subsystems should
not rely on PCI specifics, as they won't be available afterward.
It should also allow you to clean up your API. Exposing hotplug_fd and
requiring PMDs to link it can be avoided and should result in a simpler
API.
Signed-off-by: Jeff Guo
---
drivers/net/i40e/i40e_ethdev.c | 15 +++
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 146 -
.../linuxapp/eal/include/exec-env/rte_interrupts.h | 32 +
3 files changed, 191 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 4c49673..0336f82 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -66,6 +66,8 @@
#include "i40e_pf.h"
#include "i40e_regs.h"
+extern int hotplug_fd;
+
#define ETH_I40E_FLOATING_VEB_ARG "enable_floating_veb"
#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
@@ -5808,8 +5810,21 @@ i40e_dev_interrupt_handler(void *param)
{
struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ struct rte_uevent event;
uint32_t icr0;
+ /* check device uevent */
+ while (rte_get_uevent(hotplug_fd, &event) > 0) {
+ if (event.subsystem == 1) {
+ if (event.action == RTE_UEVENT_ADD) {
+ //do nothing here
+ } else if (event.action == RTE_UEVENT_REMOVE) {
+ _rte_eth_dev_callback_process(dev,
+ RTE_ETH_EVENT_INTR_RMV, NULL);
+ }
+ }
+ }
+
/* Disable interrupt */
i40e_pf_disable_irq0(hw);
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_int
[dpdk-dev] [PATCH v3]net/mlx5: implement drop action in hardware classifier
remove/add blank line according to convensions Shachar Beiser (1): net/mlx5: implement drop action in hardware classifier drivers/net/mlx5/Makefile| 5 + drivers/net/mlx5/mlx5_flow.c | 17 + 2 files changed, 22 insertions(+) -- 1.8.3.1
Re: [dpdk-dev] [PATCH] net/mlx5: fix wrong exception handling
On Mon, May 29, 2017 at 06:02:59PM -0700, Yongseok Koh wrote:
> A sanity check is required in priv_fdir_disable(). If resizing Rx queue
> fails, this can cause a crash by referencing a NULL pointer.
>
> Cc: sta...@dpdk.org
> Fixes: 76f5c99e6840 ("mlx5: support flow director")
> Fixes: 0cdddf4d0626 ("net/mlx5: split Rx queue structure")
>
> Signed-off-by: Yongseok Koh
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
[dpdk-dev] [PATCH 0/3] Add support for using a config file for DPDK
From: Michal Jastrzebski This patch introduce a mechanism for running dpdk application with parameters provided by configuration file. New API for cfgfile library allows to create a cfgfile at runtime, add new section and add entry in a section - opens up the possibility to have applications dynamically build up a proper DPDK configuration, rather than having to have a pre-existing one. A new API for EAL takes a config file data type - either loaded from file, or built up programmatically in the application - and extracts DPDK parameters from it to be used when eal init is called. This allows apps to have an alternative method to configure EAL, other than via command-line parameters. Testpmd application is used to the demonstrate the new eal API. If a --cfgfile-path option is passed into command line non EAL section, then the file is loaded and used by app. If a file called config.ini is present in current working directory, and no --cfgfile-path option is passed in, config.ini file will be loaded and used by app. Currently *.ini file format is supported, but we would like to demonstrate in v2 how alternative config file formats could be used. Other work planned for v2: support for subsections – allowing to pass i.e. [DPDK.vdev0] and its parameters, cleanup to EAL API and testpmd. Jacek Piasecki (1): cfgfile: add new API functions Kuba Kozak (2): eal: add functions parsing EAL arguments app/testpmd: changed example to parse options from cfg file app/test-pmd/config.ini | 16 ++ app/test-pmd/parameters.c | 135 ++- app/test-pmd/testpmd.c | 51 +++- app/test-pmd/testpmd.h |2 +- lib/Makefile|6 +- lib/librte_cfgfile/Makefile |1 + lib/librte_cfgfile/rte_cfgfile.c| 293 +-- lib/librte_cfgfile/rte_cfgfile.h| 52 lib/librte_cfgfile/rte_cfgfile_version.map |9 + lib/librte_eal/bsdapp/eal/Makefile |4 + lib/librte_eal/bsdapp/eal/eal.c | 128 +- lib/librte_eal/bsdapp/eal/rte_eal_version.map |5 + lib/librte_eal/common/include/rte_eal.h |6 + lib/librte_eal/linuxapp/eal/Makefile|3 + lib/librte_eal/linuxapp/eal/eal.c | 108 - lib/librte_eal/linuxapp/eal/rte_eal_version.map |4 + mk/rte.app.mk |2 +- 17 files changed, 684 insertions(+), 141 deletions(-) create mode 100644 app/test-pmd/config.ini -- 1.7.9.5
[dpdk-dev] [PATCH 1/3] cfgfile: add new API functions
Extend existing cfgfile library with providing new API functions:
rte_cfgfile_create() - create new cfgfile object
rte_cfgfile_add_section() - add new section to existing cfgfile object
rte_cfgfile_add_entry() - add new entry to existing cfgfile object
in specified section
This modification allows to create a cfgfile on runtime and
opens up the possibility to have applications dynamically build up
a proper DPDK configuration, rather than having to have a pre-existing one.
Signed-off-by: Jacek Piasecki
---
lib/librte_cfgfile/Makefile|1 +
lib/librte_cfgfile/rte_cfgfile.c | 293
lib/librte_cfgfile/rte_cfgfile.h | 50 +
lib/librte_cfgfile/rte_cfgfile_version.map |9 +
4 files changed, 227 insertions(+), 126 deletions(-)
diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index 755ef11..0bee43e 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -38,6 +38,7 @@ LIB = librte_cfgfile.a
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -I$(SRCDIR)/../librte_eal/common/include
EXPORT_MAP := rte_cfgfile_version.map
diff --git a/lib/librte_cfgfile/rte_cfgfile.c b/lib/librte_cfgfile/rte_cfgfile.c
index b54a523..457f8be 100644
--- a/lib/librte_cfgfile/rte_cfgfile.c
+++ b/lib/librte_cfgfile/rte_cfgfile.c
@@ -35,8 +35,8 @@
#include
#include
#include
+#include
#include
-#include
#include "rte_cfgfile.h"
@@ -144,10 +144,6 @@ struct rte_cfgfile *
rte_cfgfile_load_with_params(const char *filename, int flags,
const struct rte_cfgfile_parameters *params)
{
- int allocated_sections = CFG_ALLOC_SECTION_BATCH;
- int allocated_entries = 0;
- int curr_section = -1;
- int curr_entry = -1;
char buffer[CFG_NAME_LEN + CFG_VALUE_LEN + 4] = {0};
int lineno = 0;
struct rte_cfgfile *cfg = NULL;
@@ -159,28 +155,7 @@ struct rte_cfgfile *
if (f == NULL)
return NULL;
- cfg = malloc(sizeof(*cfg) + sizeof(cfg->sections[0]) *
- allocated_sections);
- if (cfg == NULL)
- goto error2;
-
- memset(cfg->sections, 0, sizeof(cfg->sections[0]) * allocated_sections);
-
- if (flags & CFG_FLAG_GLOBAL_SECTION) {
- curr_section = 0;
- allocated_entries = CFG_ALLOC_ENTRY_BATCH;
- cfg->sections[curr_section] = malloc(
- sizeof(*cfg->sections[0]) +
- sizeof(cfg->sections[0]->entries[0]) *
- allocated_entries);
- if (cfg->sections[curr_section] == NULL) {
- printf("Error - no memory for global section\n");
- goto error1;
- }
-
- snprintf(cfg->sections[curr_section]->name,
-sizeof(cfg->sections[0]->name), "GLOBAL");
- }
+ cfg = rte_cfgfile_create(flags);
while (fgets(buffer, sizeof(buffer), f) != NULL) {
char *pos = NULL;
@@ -191,6 +166,7 @@ struct rte_cfgfile *
"Check if line too long\n", lineno);
goto error1;
}
+ /* skip parsing if comment character found */
pos = memchr(buffer, params->comment_character, len);
if (pos != NULL) {
*pos = '\0';
@@ -198,6 +174,7 @@ struct rte_cfgfile *
}
len = _strip(buffer, len);
+ /* if not section line go to parse entry line */
if (buffer[0] != '[' && memchr(buffer, '=', len) == NULL)
continue;
@@ -212,121 +189,185 @@ struct rte_cfgfile *
*end = '\0';
_strip(&buffer[1], end - &buffer[1]);
- /* close off old section and add start new one */
- if (curr_section >= 0)
- cfg->sections[curr_section]->num_entries =
- curr_entry + 1;
- curr_section++;
-
- /* resize overall struct if we don't have room for more
- sections */
- if (curr_section == allocated_sections) {
- allocated_sections += CFG_ALLOC_SECTION_BATCH;
- struct rte_cfgfile *n_cfg = realloc(cfg,
- sizeof(*cfg) + sizeof(cfg->sections[0])
- * allocated_sections);
- if (n_cfg == NULL) {
- curr_section--;
- printf("Error - no more memory\n");
- goto error1;
- }
- cfg = n_cfg;
- }
[dpdk-dev] [PATCH 2/3] eal: add functions parsing EAL arguments
From: Kuba Kozak
added function rte_eal_configure which translate
options from config file into argc, **argv form.
changed function rte_eal_init to meld
argc, argv** options from config file with
these from command line and then parse as
before
Signed-off-by: Kuba Kozak
Suggested-by: Bruce Richardson
---
lib/Makefile|6 +-
lib/librte_cfgfile/rte_cfgfile.h|2 +
lib/librte_eal/bsdapp/eal/Makefile |4 +
lib/librte_eal/bsdapp/eal/eal.c | 128 ++-
lib/librte_eal/bsdapp/eal/rte_eal_version.map |5 +
lib/librte_eal/common/include/rte_eal.h |6 ++
lib/librte_eal/linuxapp/eal/Makefile|3 +
lib/librte_eal/linuxapp/eal/eal.c | 108 ++-
lib/librte_eal/linuxapp/eal/rte_eal_version.map |4 +
mk/rte.app.mk |2 +-
10 files changed, 261 insertions(+), 7 deletions(-)
diff --git a/lib/Makefile b/lib/Makefile
index 07e1fd0..fc5df3a 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -32,7 +32,11 @@
include $(RTE_SDK)/mk/rte.vars.mk
DIRS-y += librte_compat
+DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+DEPDIRS-librte_eal := librte_cfgfile
+endif
DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
DEPDIRS-librte_ring := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += librte_mempool
@@ -41,8 +45,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_MBUF) += librte_mbuf
DEPDIRS-librte_mbuf := librte_eal librte_mempool
DIRS-$(CONFIG_RTE_LIBRTE_TIMER) += librte_timer
DEPDIRS-librte_timer := librte_eal
-DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
-DEPDIRS-librte_cfgfile := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += librte_cmdline
DEPDIRS-librte_cmdline := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_ETHER) += librte_ether
diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index 902ec69..8808aa7 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -49,6 +49,8 @@
*
***/
+struct rte_cfgfile; /* forward declaration of struct */
+
#ifndef CFG_NAME_LEN
#define CFG_NAME_LEN 64
#endif
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index a0f9950..d70eefb 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -50,6 +50,10 @@ EXPORT_MAP := rte_eal_version.map
LIBABIVER := 4
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+LDLIBS += -lrte_cfgfile
+endif
+
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_memory.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 05f0c1f..e5e11c8 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
#include "eal_private.h"
#include "eal_thread.h"
@@ -92,6 +93,12 @@
* duration of the program, as we hold a write lock on it in the primary proc
*/
static int mem_cfg_fd = -1;
+static int cfg_argc;
+#ifdef RTE_LIBRTE_CFGFILE
+static char **cfg_argv;
+#endif
+
+
static struct flock wr_lock = {
.l_type = F_WRLCK,
.l_whence = SEEK_SET,
@@ -492,10 +499,28 @@ static void rte_eal_init_alert(const char *msg)
RTE_LOG(ERR, EAL, "%s\n", msg);
}
+#ifdef RTE_LIBRTE_CFGFILE
+static void
+free_pointer_array(char **pkt)
+{
+ int i = 0;
+
+ if (pkt) {
+ while (pkt[i]) {
+ free(pkt[i]);
+ pkt[i++] = 0;
+ }
+ free(pkt);
+ pkt = 0;
+ }
+}
+#endif
+
/* Launch threads, called at application init(). */
int
rte_eal_init(int argc, char **argv)
{
+ int combined_argc; /* combine cfg and param versions */
int i, fctret, ret;
pthread_t thread_id;
static rte_atomic32_t run_once = RTE_ATOMIC32_INIT(0);
@@ -519,8 +544,25 @@ static void rte_eal_init_alert(const char *msg)
eal_reset_internal_config(&internal_config);
+#ifdef RTE_LIBRTE_CFGFILE
+ combined_argc = argc + cfg_argc;
+ char *combined_argv[combined_argc + 1];
+
+ combined_argv[0] = argv[0];
+ for (i = 0; i < cfg_argc; i++)
+ combined_argv[i + 1] = cfg_argv[i];
+ for (i = 1; i < argc; i++)
+ combined_argv[i + cfg_argc] = argv[i];
+ combined_argv[combined_argc] = NULL;
+#else
+ combined_argc = argc;
+ char **combined_argv;
+
+ combined_argv = argv;
+#endif
+
/* set log level as early as possible */
- eal_log_level_parse(argc, argv);
+ eal_log_level_parse(combined_argc, combined_argv);
if (rte_eal_cpu_init() < 0) {
rte_eal_init_alert("Cannot detect lcores.");
@@ -528,13 +570,21 @@ static void rte_eal_init_alert(const char *
[dpdk-dev] [PATCH 3/3] app/testpmd: changed example to parse options from cfg file
From: Kuba Kozak
This patch shows how to pass arguments to application
using config.ini file.
If a --cfgfile-path option is passed into commandline
non EAL section, then the file is loaded and used by app.
If a file called config.ini is present in current working
directory, and no --cfgfile-path option is passed in, config.ini
file will be loaded and used by app.
Signed-off-by: Kuba Kozak
Suggested-by: Bruce Richardson
---
app/test-pmd/config.ini | 16 ++
app/test-pmd/parameters.c | 135 +++--
app/test-pmd/testpmd.c| 51 -
app/test-pmd/testpmd.h|2 +-
4 files changed, 196 insertions(+), 8 deletions(-)
create mode 100644 app/test-pmd/config.ini
diff --git a/app/test-pmd/config.ini b/app/test-pmd/config.ini
new file mode 100644
index 000..dfafc55
--- /dev/null
+++ b/app/test-pmd/config.ini
@@ -0,0 +1,16 @@
+[DPDK]
+v =
+l = 0-4
+n = 4
+master-lcore = 0
+proc-type = primary
+vdev = net_ring0
+vdev = net_ring1
+vdev = net_ring2
+vdev = net_ring3
+
+[TEST-PMD]
+i =
+portmask = 0xf
+nb-cores = 4
+port-topology = paired
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index fbe6284..974c548 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -77,9 +77,15 @@
#include
#endif
#include
+#include
#include "testpmd.h"
+#ifdef RTE_LIBRTE_CFGFILE
+static int cfg_argc;
+static char **cfg_argv;
+#endif
+
static void
usage(char* progname)
{
@@ -549,15 +555,107 @@
return 0;
}
+#ifdef RTE_LIBRTE_CFGFILE
+
+static void
+free_pointer_array(char **pkt)
+{
+ int i = 0;
+
+ if (pkt) {
+ while (pkt[i]) {
+ free(pkt[i]);
+ pkt[i++] = 0;
+ }
+ free(pkt);
+ pkt = 0;
+ }
+}
+
+static char *strdup_with_prefix(const char *p)
+{
+ char *np;
+
+ if (strlen(p) > 1) {
+ np = (char *)malloc(strlen(p)+3);
+ if (np)
+ strcpy(np, "--");
+ } else {
+ np = (char *)malloc(strlen(p)+2);
+ if (np)
+ strcpy(np, "-");
+ }
+ return np ? strcat(np, p) : np;
+}
+
+#define APP_SECTION "TEST-PMD"
+static int non_eal_configure(struct rte_cfgfile *cfg)
+{
+ int i, num_entries;
+
+ if (cfg == NULL) {
+ rte_errno = -EINVAL;
+ return -1;
+ }
+
+ if (!rte_cfgfile_has_section(cfg, APP_SECTION))
+ return 0;
+
+ num_entries = rte_cfgfile_section_num_entries(cfg, APP_SECTION);
+ if (num_entries <= 0)
+ return 0;
+
+ cfg_argv = malloc((num_entries * 2 + 1) * sizeof(cfg_argv[0]));
+ if (cfg_argv == NULL) {
+ rte_errno = -ENOMEM;
+ return -1;
+ }
+
+ struct rte_cfgfile_entry cfg_entries[num_entries];
+
+ rte_cfgfile_section_entries(cfg, APP_SECTION, cfg_entries, num_entries);
+
+ cfg_argc = 0;
+ for (i = 0; i < num_entries; i++) {
+ cfg_argv[cfg_argc] = strdup_with_prefix(cfg_entries[i].name);
+ if (!(cfg_argv[cfg_argc]))
+ goto allocation_error;
+ cfg_argc++;
+ if (strlen(cfg_entries[i].value)) {
+ cfg_argv[cfg_argc] = strdup(cfg_entries[i].value);
+ if (!(cfg_argv[cfg_argc]))
+ goto allocation_error;
+ cfg_argc++;
+ }
+ }
+ /* set last pointer to 0 */
+ cfg_argv[cfg_argc] = 0;
+
+ return cfg_argc;
+
+allocation_error:
+ printf("Warning: Cannot allocate memory in rte_eal_configure()\n");
+ rte_errno = ENOMEM;
+ for (i = 1; i < cfg_argc; i++) {
+ free(cfg_argv[i]);
+ cfg_argv[i] = 0;
+ }
+ return -1;
+}
+#endif
+
void
-launch_args_parse(int argc, char** argv)
+launch_args_parse(int argc, char **argv, struct rte_cfgfile *cfg)
{
+ int combined_argc; /* combine cfg and param versions */
+ char **combined_argv;
int n, opt;
char **argvopt;
int opt_idx;
enum { TX, RX };
static struct option lgopts[] = {
+ { "cfgfile-path", 1, 0, 1 },
{ "help", 0, 0, 0 },
#ifdef RTE_LIBRTE_CMDLINE
{ "interactive",0, 0, 0 },
@@ -632,14 +730,32 @@
{ 0, 0, 0, 0 },
};
- argvopt = argv;
+#ifdef RTE_LIBRTE_CFGFILE
+ int i;
+
+ non_eal_configure(cfg);
+
+ combined_argc = argc + cfg_argc;
+ combined_argv = malloc((combined_argc + 1) * sizeof(char *));
+ combined_argv[0] = argv[0];
+ for (i = 0; i < cfg_argc; i++)
+ combined_argv[i + 1] = cfg_argv[i];
+ for (i = 1; i < argc; i++)
+ combined_argv[i + cfg_argc] = argv[i];
+
Re: [dpdk-dev] [PATCH 00/13] cxgbe: add support for Chelsio T6 family of adapters
27/05/2017 05:46, Rahul Lakkireddy: > This series of patches add support for Chelsio T6 family of adapters. It is almost one year since your last contribution, welcome back Rahul :) During that time, rte_flow has been implemented in DPDK. Do you plan to use it for Chelsio offloads, instead of flow director?
Re: [dpdk-dev] [PATCH 01/13] cxgbe: add support to run Chelsio T6 cards
On 5/27/2017 4:46 AM, Rahul Lakkireddy wrote: > Add code to detect and run T6 devices. Update PCI ID Device table > with Chelsio T6 device ids and update documentation. Can you please update DPDK supported NICs web page [1] too, with a separate web patch [2] ? [1] http://dpdk.org/doc/nics [2] http://dpdk.org/browse/tools/dpdk-web/ > > Signed-off-by: Rahul Lakkireddy > Signed-off-by: Kumar Sanghvi <...>
Re: [dpdk-dev] [PATCH 05/13] cxgbe: update link speeds and port modules
On 5/27/2017 4:46 AM, Rahul Lakkireddy wrote: > Add 25G and 100G link speeds and update supported port modules. Not with this patch, but with separate patch, can it be possible to update speed_capa in cxgbe_dev_info_get() to get device specific speed capability, and update doc/guides/nics/features/cxgbe.ini to announce "Speed capabilities" feature by driver? > > Signed-off-by: Rahul Lakkireddy > Signed-off-by: Kumar Sanghvi <...>
Re: [dpdk-dev] [PATCH 00/13] cxgbe: add support for Chelsio T6 family of adapters
On 5/27/2017 4:46 AM, Rahul Lakkireddy wrote: > This series of patches add support for Chelsio T6 family of adapters. > > Patches 1 - 4 update CXGBE PMD to detect and run Chelsio T6 cards. > > Patches 5 - 6 add new link speeds and update port modules. > > Patch 7 updates information prints to accommodate Chelsio T6 cards. > > Patch 8 updates TX path to reflect Chelsio T6 changes. > > Patches 9 - 11 update RX path to reflect Chelsio T6 changes. > > Patch 12 updates port statistics to not accumulate pause frames > as part of packet count and also fixes issue with rx counters. > > Patch 13 removes RTE_PCI_DRV_INTR_LSC flag from CXGBE PMD since > it doesn't handle direct LSC interrupts. > > Thanks, > Rahul > > Rahul Lakkireddy (13): > cxgbe: add support to run Chelsio T6 cards > cxgbe: update register dump > cxgbe: update flash part information > cxgbe: grab available ports after firmware reset > cxgbe: update link speeds and port modules > cxgbe: add forward error correction support > cxgbe: update hardware info prints > cxgbe: update TX path for Chelsio T6 > cxgbe: update RXQ channel mapping for Chelsio T6 > cxgbe: update RX path for Chelsio T6 > cxgbe: add compressed error vector > cxgbe: fix port statistics > cxgbe: remove RTE_PCI_DRV_INTR_LSC from driver flags Series applied to dpdk-next-net/master, thanks. (some updates done on patch subjects)
Re: [dpdk-dev] [PATCH] net/mlx5: add vectorized Rx
28/05/2017 17:40, Yongseok Koh: > Vectorized Rx API for x86 is added. > > Signed-off-by: Yongseok Koh > --- > drivers/net/mlx5/Makefile | 1 + > drivers/net/mlx5/mlx5_defs.h | 6 + > drivers/net/mlx5/mlx5_ethdev.c | 8 + > drivers/net/mlx5/mlx5_rxq.c| 39 +++- > drivers/net/mlx5/mlx5_rxtx.c | 485 > + > drivers/net/mlx5/mlx5_rxtx.h | 10 + > 6 files changed, 548 insertions(+), 1 deletion(-) It would be probably clearer to have a specific file for Rx/Tx on SSE. So it would be compiled only for x86. > --- a/drivers/net/mlx5/Makefile > +++ b/drivers/net/mlx5/Makefile > @@ -60,6 +60,7 @@ CFLAGS += -D_DEFAULT_SOURCE > CFLAGS += -D_XOPEN_SOURCE=600 > CFLAGS += $(WERROR_FLAGS) > CFLAGS += -Wno-strict-prototypes > +CFLAGS += -msse4.1 > LDLIBS += -libverbs [...] > --- a/drivers/net/mlx5/mlx5_ethdev.c > +++ b/drivers/net/mlx5/mlx5_ethdev.c > @@ -723,7 +723,11 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev) > > }; > > +#ifdef MLX5_VECTORIZED_RX > + if (dev->rx_pkt_burst == mlx5_rx_burst_vec) > +#else > if (dev->rx_pkt_burst == mlx5_rx_burst) > +#endif > return ptypes; > return NULL; > } Can we avoid an #ifdef here? We should check SSE support at runtime with rte_cpu_get_flag_enabled().
Re: [dpdk-dev] [RFC] Kernel Control Path (KCP)
26/05/2017 18:52, Ferruh Yigit: > We are looking for re-sending [1] the Kernel Control Path (KCP) > with some updates [2]. > > Mainly this is an usability improvement for DPDK. > > And a quick reminder about what KCP is: > > "KCP is Linux virtual network interface that can control DPDK ports". > > So DPDK interfaces, somehow will be visible and it will be possible to > use common Linux tools on DPDK interfaces. Reminder: the Mellanox PMDs live with their upstream kernel modules, allowing such features. The best model would be to have control path in kernel for every PMDs. Anyway, do you think KCP (or NCI) could be upstreamed in any way?
Re: [dpdk-dev] [PATCH 00/10] net/i40e: base code update
On 5/27/2017 4:47 AM, Jingjing Wu wrote: > i40e base code upate. The main changes are: > - use virtchnl.h instead of i40e_virtchnl.h > - add support for Adaptive Virtual Function > - add new AQ commands for read/write PHY registers > - add new phy types for 25G Hi Jingjing, Patchset giving build error with clang [1] because of assignment between different enum types, can you please check the build errors? [1] .../drivers/net/i40e/i40e_pf.c:349:32: error: implicit conversion from enumeration type 'enum i40e_vsi_type' to different enumeration type 'enum virtchnl_vsi_type' [-Werror,-Wenum-conversion] vf_res->vsi_res[0].vsi_type = I40E_VSI_SRIOV; ~ ^~ .../drivers/net/i40e/i40e_pf.c:1195:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_100MB; ~ ^ .../drivers/net/i40e/i40e_pf.c:1198:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_1GB; ~ ^~~ .../drivers/net/i40e/i40e_pf.c:1201:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_10GB; ~ ^~~~ .../drivers/net/i40e/i40e_pf.c:1204:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_20GB; ~ ^~~~ .../drivers/net/i40e/i40e_pf.c:1207:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_25GB; ~ ^~~~ .../drivers/net/i40e/i40e_pf.c:1210:44: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] event.event_data.link_event.link_speed = I40E_LINK_SPEED_40GB; ~ ^~~~ .../drivers/net/i40e/i40e_pf.c:1214:4: error: implicit conversion from enumeration type 'enum i40e_aq_link_speed' to different enumeration type 'enum virtchnl_link_speed' [-Werror,-Wenum-conversion] I40E_LINK_SPEED_UNKNOWN; ^~~ 8 errors generated. .../mk/internal/rte.compile-pre.mk:138: recipe for target 'i40e_pf.o' failed make[4]: *** [i40e_pf.o] Error 1 make[4]: *** Waiting for unfinished jobs .../drivers/net/i40e/i40e_ethdev_vf.c:275:32: error: implicit conversion from enumeration type 'enum virtchnl_link_speed' to different enumeration type 'enum i40e_aq_link_speed' [-Werror,-Wenum-conversion] vpe->event_data.link_event.link_speed; ~~~^~ .../drivers/net/i40e/i40e_ethdev_vf.c:1274:30: error: implicit conversion from enumeration type 'enum virtchnl_vsi_type' to different enumeration type 'enum i40e_vsi_type' [-Werror,-Wenum-conversion] vf->vsi.type = vf->vsi_res->vsi_type; ~ ~^~~~ .../drivers/net/i40e/i40e_ethdev_vf.c:1339:50: error: implicit conversion from enumeration type 'enum virtchnl_link_speed' to different enumeration type 'enum i40e_aq_link_speed' [-Werror,-Wenum-conversion] vf->link_speed = pf_msg->event_data.link_event.link_speed; ~ ~~^~ <...>
Re: [dpdk-dev] [PATCH 0/4] cxgbe: latency and performance fixes
On 5/27/2017 4:47 AM, Rahul Lakkireddy wrote: > This series of patches rework TX and RX path to reduce latency > and improve performance. > > Patch 1 reduces latency for slow traffic by using status page update > on RX path to process batch of packets and improves coalesce TX path > to handle slow moving traffic. > > Patch 2 fixes an issue with RXQ default parameters not being applied > to all ports under same PF. > > Patch 3 fixes rmb bottleneck in RX path. > > Patch 4 adds ability to configure PCIe extended tags. > > This series depend on following series: > > "cxgbe: add support for Chelsio T6 family of adapters" > > Thanks, > Rahul > > Rahul Lakkireddy (4): > cxgbe: improve latency for slow traffic > cxgbe: fix rxq default params for ports under same PF > cxgbe: remove rmb bottleneck in RX path > cxgbe: configure PCIe extended tags Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v3 1/3] lib: add Generic Receive Offload API framework
HI Jiayu, > -Original Message- > From: Hu, Jiayu > Sent: Tuesday, May 30, 2017 6:29 AM > To: Ananyev, Konstantin > Cc: dev@dpdk.org; Wiles, Keith ; > yuanhan@linux.intel.com > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API framework > > Hi Konstantin, > > > -Original Message- > > From: Ananyev, Konstantin > > Sent: Monday, May 29, 2017 8:52 PM > > To: Hu, Jiayu > > Cc: dev@dpdk.org; Wiles, Keith ; > > yuanhan@linux.intel.com > > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API framework > > > > Hi Jiayu, > > > > > -Original Message- > > > From: Hu, Jiayu > > > Sent: Monday, May 29, 2017 11:23 AM > > > To: Ananyev, Konstantin > > > Cc: dev@dpdk.org; Wiles, Keith ; > > yuanhan@linux.intel.com > > > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API > > framework > > > > > > Hi Konstantin, > > > > > > > -Original Message- > > > > From: Ananyev, Konstantin > > > > Sent: Sunday, May 28, 2017 12:51 AM > > > > To: Hu, Jiayu > > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > > yuanhan@linux.intel.com > > > > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API > > framework > > > > > > > > > > > > Hi Jiayu, > > > > > > > > > > > > > > Hi Konstantin, > > > > > > > > > > On Sat, May 27, 2017 at 07:12:16PM +0800, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Hu, Jiayu > > > > > > > Sent: Saturday, May 27, 2017 4:42 AM > > > > > > > To: Ananyev, Konstantin > > > > > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > > yuanhan@linux.intel.com > > > > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload API > > > > framework > > > > > > > > > > > > > > On Sat, May 27, 2017 at 07:10:21AM +0800, Ananyev, Konstantin > > wrote: > > > > > > > > Hi Jiayu, > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Hu, Jiayu > > > > > > > > > Sent: Friday, May 26, 2017 8:26 AM > > > > > > > > > To: Ananyev, Konstantin > > > > > > > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > > yuanhan@linux.intel.com > > > > > > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload > > > > > > > > > API > > > > framework > > > > > > > > > > > > > > > > > > Hi Konstantin, > > > > > > > > > > > > > > > > > > On Wed, May 24, 2017 at 08:38:25PM +0800, Ananyev, > > Konstantin > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Jiayu, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Konstantin, > > > > > > > > > > > > > > > > > > > > > > Thanks for your comments. My replies/questions are below. > > > > > > > > > > > > > > > > > > > > > > BRs, > > > > > > > > > > > Jiayu > > > > > > > > > > > > > > > > > > > > > > On Mon, May 22, 2017 at 05:19:19PM +0800, Ananyev, > > > > Konstantin wrote: > > > > > > > > > > > > Hi Jiayu, > > > > > > > > > > > > My comments/questions below. > > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For applications, DPDK GRO provides three external > > functions > > > > to > > > > > > > > > > > > > enable/disable GRO: > > > > > > > > > > > > > - rte_gro_init: initialize GRO environment; > > > > > > > > > > > > > - rte_gro_enable: enable GRO for a given port; > > > > > > > > > > > > > - rte_gro_disable: disable GRO for a given port. > > > > > > > > > > > > > Before using GRO, applications should explicitly call > > > > rte_gro_init to > > > > > > > > > > > > > initizalize GRO environment. After that, applications > > > > > > > > > > > > > can > > call > > > > > > > > > > > > > rte_gro_enable to enable GRO and call rte_gro_disable > > to > > > > disable GRO for > > > > > > > > > > > > > specific ports. > > > > > > > > > > > > > > > > > > > > > > > > I think this is too restrictive and wouldn't meet > > > > > > > > > > > > various > > user's > > > > needs. > > > > > > > > > > > > User might want to: > > > > > > > > > > > > - enable/disable GRO for particular RX queue > > > > > > > > > > > > - or even setup different GRO types for different RX > > > > > > > > > > > > queues, > > > > > > > > > > > >i.e, - GRO over IPV4/TCP for queue 0, and GRO over > > > > IPV6/TCP for queue 1, etc. > > > > > > > > > > > > > > > > > > > > > > The reason for enabling/disabling GRO per-port instead of > > per- > > > > queue is that LINUX > > > > > > > > > > > controls GRO per-port. To control GRO per-queue indeed can > > > > provide more flexibility > > > > > > > > > > > to applications. But are there any scenarios that > > > > > > > > > > > different > > > > queues of a port may > > > > > > > > > > > require different GRO control (i.e. GRO types and > > enable/disable > > > > GRO)? > > > > > > > > > > > > > > > > > > > > I think yes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - For various reasons, user might prefer not to use RX > > callbacks > > > > for various reasons, > > > > > > > > > > > > But inv
Re: [dpdk-dev] [dpdk-stable] [PATCH 1/5] net/sfc/base: fix incorrect error code usage in common code
On 5/27/2017 8:55 AM, Andrew Rybchenko wrote:
> From: Andy Moreton
>
> MCDI results retuerned in req.emr_rc have already been translated
> from MC_CMD_ERR_* to errno names, so using an MC_CMD_ERR_* value
> is incorrect.
>
> Fixes: e7cd430c864f ("net/sfc/base: import SFN7xxx family support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Andy Moreton
> Signed-off-by: Andrew Rybchenko
Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 1/3] net/ixgbe/base: remove PHY access for some 1G ports
On 5/27/2017 9:33 AM, Wei Dai wrote: > This patch removes some some 1GBASE-T PHY access since the FW > configures the PHY. SW shall not configure or initialize link. > Accessing the PHY would require the use of MDI clause 22 which > should be avoided in high layer driver code. > > Signed-off-by: Wei Dai Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 6/7] mbuf: introduce new Tx offload flag for MPLS-in-UDP
On 5/28/2017 9:37 AM, Rasesh Mody wrote: > From: Harish Patil > > Some PMDs need to know the tunnel type in order to handle advance TX > features. This patch adds a new TX offload flag for MPLS-in-UDP packets. > > Signed-off-by: Harish Patil > --- > lib/librte_mbuf/rte_mbuf.c |2 ++ > lib/librte_mbuf/rte_mbuf.h | 17 ++--- > 2 files changed, 12 insertions(+), 7 deletions(-) CC: Olivier MATZ This patch updates rte_mbuf, so the patchset will wait for the ACK for this patch first. Thanks, ferruh
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/mlx5: fix flow application order on stop/start
On 5/29/2017 2:29 PM, Adrien Mazarguil wrote:
> On Mon, May 29, 2017 at 11:40:58AM +0200, Nelio Laranjeiro wrote:
>> Flow rules must be applied in the same order as they have been created and
>> thus destroyed in the reverse order.
>>
>> Fixes: 2097d0d1e2cc ("net/mlx5: support basic flow items and actions")
>>
>> Cc: sta...@dpdk.org
>> Signed-off-by: Nelio Laranjeiro
>> Acked-by: Yongseok Koh
>
> Acked-by: Adrien Mazarguil
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/mlx5: removal already initialised mbuf fields
On 5/29/2017 2:30 PM, Adrien Mazarguil wrote:
> On Mon, May 29, 2017 at 11:45:09AM +0200, Nelio Laranjeiro wrote:
>> Since commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool"), some
>> fields are already initialised and do not need to be modified by the PMD
>> anymore.
>>
>> Signed-off-by: Nelio Laranjeiro
>> Acked-by: Shahaf Shuler
>
> Except for the title ("removal" => "remove"?),
>
> Acked-by: Adrien Mazarguil
Applied to dpdk-next-net/master, thanks.
(fixed title)
Re: [dpdk-dev] [PATCH] net/ring: fix adding MAC addresses
On 5/26/2017 2:18 PM, Charles (Chas) Williams wrote:
> When .mac_addr_add() was changed to allow a return code, ring was changed
> to return -ENOTSUP. This changes the behavior of the rte_ring driver in
> a way that does not maintain backward compatibility. Additionally, if
> the intent is to return -ENOTSUP, you could simply not define the stubs.
>
> Fixes: 6d01e580ac5d ("ethdev: fix adding invalid MAC address")
>
> Signed-off-by: Chas Williams
Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] ethdev: add roughly match pattern
Hi Zhang,
You should cram "flow API" somewhere in the title of such commits.
On Tue, May 23, 2017 at 07:28:54PM -0400, Qi Zhang wrote:
> Add new meta pattern item RTE_FLOW_TYPE_ITEM_ROUGHLY.
>
> This is for device that support no-perfect match option.
> Usually a no-perfect match is fast but the cost is accuracy.
> i.e. Signature Match only match pattern's hash value, but it is
> possible two different patterns have the same hash value.
>
> Matching accuracy level can be configure by subfield threshold.
> Driver can divide the range of threshold and map to different
> accuracy levels that device support.
>
> Signed-off-by: Qi Zhang
While I really like the "roughly" pattern item name since it perfectly
describes its intended purpose in my opinion, perhaps some may not find this
name appropriate. I would like to hear other people's opinion on the matter
and not be the only one to ack this patch.
Several more comments below.
> ---
> app/test-pmd/cmdline_flow.c | 24 ++
> app/test-pmd/config.c | 1 +
> doc/guides/prog_guide/rte_flow.rst | 50
> +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 ++
> lib/librte_ether/rte_flow.h | 30 +
> 5 files changed, 107 insertions(+)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 0fd69f9..18ffcff 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -107,6 +107,8 @@ enum index {
> ITEM_END,
> ITEM_VOID,
> ITEM_INVERT,
> + ITEM_ROUGHLY,
> + ITEM_ROUGHLY_THRESHOLD,
"Threshold" is commonly abbreviated as "thresh", I think it's fine if you
use this shorter form here and in the structure definition.
There is also an issue with the position of these enum entries. They should
come in the same order as rte_flow.h definitions like you did, but you are
supposed to add new entries at the end of the various lists in that file
instead of in the middle, otherwise you're destroying API/ABI compatibility
which is not supposed to happen. More on that topic below.
> ITEM_ANY,
> ITEM_ANY_NUM,
> ITEM_PF,
> @@ -426,6 +428,7 @@ static const enum index next_item[] = {
> ITEM_END,
> ITEM_VOID,
> ITEM_INVERT,
> + ITEM_ROUGHLY,
This will have to be moved at the end of the list.
> ITEM_ANY,
> ITEM_PF,
> ITEM_VF,
> @@ -447,6 +450,12 @@ static const enum index next_item[] = {
> ZERO,
> };
>
> +static const enum index item_roughly[] = {
> + ITEM_ROUGHLY_THRESHOLD,
I suggest "ITEM_ROUGHLY_THRESH".
> + ITEM_NEXT,
> + ZERO,
> +};
> +
> static const enum index item_any[] = {
> ITEM_ANY_NUM,
> ITEM_NEXT,
> @@ -954,6 +963,21 @@ static const struct token token_list[] = {
> .next = NEXT(NEXT_ENTRY(ITEM_NEXT)),
> .call = parse_vc,
> },
> + [ITEM_ROUGHLY] = {
This will have to be moved at the end of the list.
> + .name = "roughly",
> + .help = "match the pattern roughly",
Hehe, the question is who will go out of their way to match traffic roughly
instead of perfectly? They need a better incentive to do so, in a very short
sentence.
> + .priv = PRIV_ITEM(ROUGHLY,
> + sizeof(struct rte_flow_item_roughly)),
> + .next = NEXT(item_roughly),
> + .call = parse_vc,
> + },
> + [ITEM_ROUGHLY_THRESHOLD] = {
> + .name = "threshold",
"thresh" again, I won't comment them all, you get the idea.
> + .help = "match accuracy threshold",
> + .next = NEXT(item_roughly, NEXT_ENTRY(UNSIGNED), item_param),
> + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_roughly,
> + threshold)),
> + },
> [ITEM_ANY] = {
> .name = "any",
> .help = "match any protocol for the current layer",
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index 4d873cd..5b0cd4d 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -954,6 +954,7 @@ static const struct {
> MK_FLOW_ITEM(END, 0),
> MK_FLOW_ITEM(VOID, 0),
> MK_FLOW_ITEM(INVERT, 0),
> + MK_FLOW_ITEM(ROUGHLY, sizeof(struct rte_flow_item_roughly)),
This will have to be moved at the end of the list.
> MK_FLOW_ITEM(ANY, sizeof(struct rte_flow_item_any)),
> MK_FLOW_ITEM(PF, 0),
> MK_FLOW_ITEM(VF, sizeof(struct rte_flow_item_vf)),
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index b587ba9..4cc1876 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -491,6 +491,7 @@ Usage example, matching non-TCPv4 packets only:
>
> +---+--+
> | Index | Item |
> +
This change looks unnecessary.
> +===+==+
> | 0 | INVERT |
> +---+
Re: [dpdk-dev] [PATCH] net/ring: fix adding MAC addresses
On 5/30/2017 1:45 PM, Ferruh Yigit wrote:
> On 5/26/2017 2:18 PM, Charles (Chas) Williams wrote:
>> When .mac_addr_add() was changed to allow a return code, ring was changed
>> to return -ENOTSUP. This changes the behavior of the rte_ring driver in
>> a way that does not maintain backward compatibility. Additionally, if
>> the intent is to return -ENOTSUP, you could simply not define the stubs.
>>
>> Fixes: 6d01e580ac5d ("ethdev: fix adding invalid MAC address")
>>
>> Signed-off-by: Chas Williams
>
> Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [RFC v3] flow_classify: add librte_flow_classify library
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Thursday, May 25, 2017 4:47 PM > To: dev@dpdk.org > Cc: Yigit, Ferruh ; Mcnamara, John > ; Tahhan, Maryam > ; Iremonger, Bernard > ; Adrien Mazarguil > > Subject: [RFC v3] flow_classify: add librte_flow_classify library > > Signed-off-by: Ferruh Yigit > --- > Cc: Bernard Iremonger > Cc: Adrien Mazarguil > > RFC v3: > * add create() / destroy() APIs > * query() gets rte_flow_classify object as param > * query() gets one flow at a time > > RFC v2: > * prefer user called functions to callbacks > * use rte_flow to define flows and actions > --- > config/common_base | 5 + > doc/api/doxy-api-index.md | 1 + > doc/api/doxy-api.conf | 1 + > doc/guides/rel_notes/release_17_08.rst | 1 + > lib/Makefile | 2 + > lib/librte_flow_classify/Makefile | 50 +++ > lib/librte_flow_classify/rte_flow_classify.c | 153 > + > lib/librte_flow_classify/rte_flow_classify.h | 149 > > .../rte_flow_classify_version.map | 9 ++ > mk/rte.app.mk | 1 + > 10 files changed, 372 insertions(+) > create mode 100644 lib/librte_flow_classify/Makefile create mode 100644 > lib/librte_flow_classify/rte_flow_classify.c > create mode 100644 lib/librte_flow_classify/rte_flow_classify.h > create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map > > diff --git a/config/common_base b/config/common_base index > 8907bea..3a7e73a 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -651,6 +651,11 @@ CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n > CONFIG_RTE_LIBRTE_METER=y > > # > +# Compile librte_classify > +# > +CONFIG_RTE_LIBRTE_FLOW_CLASSIFY=y > + > +# > # Compile librte_sched > # > CONFIG_RTE_LIBRTE_SCHED=y > diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index > f5f1f19..d18c2b6 100644 > --- a/doc/api/doxy-api-index.md > +++ b/doc/api/doxy-api-index.md > @@ -98,6 +98,7 @@ There are many libraries, so their headers may be > grouped by topics: >[LPM IPv4 route] (@ref rte_lpm.h), >[LPM IPv6 route] (@ref rte_lpm6.h), >[ACL](@ref rte_acl.h), > + [flow_classify] (@ref rte_flow_classify.h), >[EFD](@ref rte_efd.h) > > - **QoS**: > diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index > ca9194f..94f3d0f 100644 > --- a/doc/api/doxy-api.conf > +++ b/doc/api/doxy-api.conf > @@ -46,6 +46,7 @@ INPUT = doc/api/doxy-api-index.md \ >lib/librte_efd \ >lib/librte_ether \ >lib/librte_eventdev \ > + lib/librte_flow_classify \ >lib/librte_hash \ >lib/librte_ip_frag \ >lib/librte_jobstats \ diff --git > a/doc/guides/rel_notes/release_17_08.rst > b/doc/guides/rel_notes/release_17_08.rst > index 74aae10..6362bb2 100644 > --- a/doc/guides/rel_notes/release_17_08.rst > +++ b/doc/guides/rel_notes/release_17_08.rst > @@ -152,6 +152,7 @@ The libraries prepended with a plus sign were > incremented in this version. > librte_distributor.so.1 > librte_eal.so.4 > librte_ethdev.so.6 > + + librte_flow_classify.so.1 > librte_hash.so.2 > librte_ip_frag.so.1 > librte_jobstats.so.1 > diff --git a/lib/Makefile b/lib/Makefile index 07e1fd0..e63cd61 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -80,6 +80,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_POWER) += librte_power > DEPDIRS-librte_power := librte_eal > DIRS-$(CONFIG_RTE_LIBRTE_METER) += librte_meter DEPDIRS- > librte_meter := librte_eal > +DIRS-$(CONFIG_RTE_LIBRTE_FLOW_CLASSIFY) += librte_flow_classify > +DEPDIRS-librte_flow_classify := librte_eal librte_ether librte_net > DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += librte_sched DEPDIRS-librte_sched > := librte_eal librte_mempool librte_mbuf librte_net DEPDIRS-librte_sched > += librte_timer diff --git a/lib/librte_flow_classify/Makefile > b/lib/librte_flow_classify/Makefile > new file mode 100644 > index 000..c57e9a3 > --- /dev/null > +++ b/lib/librte_flow_classify/Makefile > @@ -0,0 +1,50 @@ > +# BSD LICENSE > +# > +# Copyright(c) 2017 Intel Corporation. All rights reserved. > +# All rights reserved. > +# > +# Redistribution and use in source and binary forms, with or without > +# modification, are permitted provided that the following conditions > +# are met: > +# > +# * Redistributions of source code must retain the above copyright > +# notice, this list of conditions and the following disclaimer. > +# * Redistributions in binary form must reproduce the above copyright > +# notice, this list of conditions and the following disclaimer in
Re: [dpdk-dev] [PATCH 1/2] net/sfc: check added but not completed descs on EF10 Tx reap
On 5/26/2017 2:50 PM, Andrew Rybchenko wrote: > There is not point to check other Tx descriptors. > It is important if Tx datapath does not reset Tx descriptor > mbuf pointer to NULL on completion (EF10 simple Tx will do). > > Signed-off-by: Andrew Rybchenko > Reviewed-by: Andy Moreton > Reviewed-by: David Riddoch Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v2] net/mlx4: support user space rxq interrupt event
On Sun, May 28, 2017 at 07:11:38PM +0300, Moti Haimovsky wrote:
> Implement rxq interrupt callbacks
>
> Signed-off-by: Moti Haimovsky
Hi Moti,
While this patch is almost identical to its mlx5 counterpart, I have one
minor nit (see below). Besides that:
Acked-by: Adrien Mazarguil
> ---
> doc/guides/nics/features/mlx4.ini | 1 +
> doc/guides/rel_notes/release_17_08.rst | 5 +
> drivers/net/mlx4/mlx4.c| 218
> -
> drivers/net/mlx4/mlx4.h| 1 +
> 4 files changed, 219 insertions(+), 6 deletions(-)
[...]
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index ec4419a..95ab325 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -75,6 +75,7 @@
> #include
> #include
> #include
> +#include
>
> /* Generated configuration header. */
> #include "mlx4_autoconf.h"
> @@ -127,6 +128,30 @@ struct mlx4_conf {
> NULL,
> };
>
> +static void
> +mlx4_dev_link_status_handler(void *);
> +
> +static void
> +mlx4_dev_interrupt_handler(void *);
> +
I understand the need for a clean up, however these definitions are not
related to this patch.
[...]
>
> -static void
> -mlx4_dev_link_status_handler(void *);
> -static void
> -mlx4_dev_interrupt_handler(void *);
> -
Please leave them here.
--
Adrien Mazarguil
6WIND
[dpdk-dev] [PATCH] net/mlx4: support user space rxq interrupt event
Implement rxq interrupt callbacks
Based on implemantation done for mlx5
Signed-off-by: Moti Haimovsky
---
doc/guides/nics/features/mlx4.ini | 1 +
doc/guides/rel_notes/release_17_08.rst | 5 +
drivers/net/mlx4/mlx4.c| 218 -
drivers/net/mlx4/mlx4.h| 1 +
4 files changed, 219 insertions(+), 6 deletions(-)
diff --git a/doc/guides/nics/features/mlx4.ini
b/doc/guides/nics/features/mlx4.ini
index 285f0ec..1a5e08b 100644
--- a/doc/guides/nics/features/mlx4.ini
+++ b/doc/guides/nics/features/mlx4.ini
@@ -6,6 +6,7 @@
[Features]
Link status = Y
Link status event= Y
+Rx interrupt = Y
Removal event= Y
Queue start/stop = Y
MTU update = Y
diff --git a/doc/guides/rel_notes/release_17_08.rst
b/doc/guides/rel_notes/release_17_08.rst
index 74aae10..3bb83db 100644
--- a/doc/guides/rel_notes/release_17_08.rst
+++ b/doc/guides/rel_notes/release_17_08.rst
@@ -41,6 +41,11 @@ New Features
Also, make sure to start the actual text at the margin.
=
+ * **Added support for Rx interrupts on mlx4 driver.**
+
+ Rx queues can be armed with an interrupt which will trigger on the
+ next packet arrival.
+
Resolved Issues
---
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index ec4419a..95ab325 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
/* Generated configuration header. */
#include "mlx4_autoconf.h"
@@ -127,6 +128,30 @@ struct mlx4_conf {
NULL,
};
+static void
+mlx4_dev_link_status_handler(void *);
+
+static void
+mlx4_dev_interrupt_handler(void *);
+
+static int
+mlx4_rx_intr_enable(struct rte_eth_dev *dev, uint16_t idx);
+
+static int
+mlx4_rx_intr_disable(struct rte_eth_dev *dev, uint16_t idx);
+
+static int
+priv_intr_efd_enable(struct priv *priv);
+
+static void
+priv_intr_efd_disable(struct priv *priv);
+
+static int
+priv_create_intr_vec(struct priv *priv);
+
+static void
+priv_destroy_intr_vec(struct priv *priv);
+
/**
* Check if running as a secondary process.
*
@@ -2756,6 +2781,8 @@ struct txq_mp2mr_mbuf_check_data {
}
if (rxq->cq != NULL)
claim_zero(ibv_destroy_cq(rxq->cq));
+ if (rxq->channel != NULL)
+ claim_zero(ibv_destroy_comp_channel(rxq->channel));
if (rxq->rd != NULL) {
struct ibv_exp_destroy_res_domain_attr attr = {
.comp_mask = 0,
@@ -3696,11 +3723,22 @@ struct txq_mp2mr_mbuf_check_data {
(void *)dev, strerror(ret));
goto error;
}
+ if (dev->data->dev_conf.intr_conf.rxq) {
+ tmpl.channel = ibv_create_comp_channel(priv->ctx);
+ if (tmpl.channel == NULL) {
+ dev->data->dev_conf.intr_conf.rxq = 0;
+ ret = ENOMEM;
+ ERROR("%p: Comp Channel creation failure: %s",
+ (void *)dev, strerror(ret));
+ goto error;
+ }
+ }
attr.cq = (struct ibv_exp_cq_init_attr){
.comp_mask = IBV_EXP_CQ_INIT_ATTR_RES_DOMAIN,
.res_domain = tmpl.rd,
};
- tmpl.cq = ibv_exp_create_cq(priv->ctx, desc, NULL, NULL, 0, &attr.cq);
+ tmpl.cq = ibv_exp_create_cq(priv->ctx, desc, NULL, tmpl.channel, 0,
+ &attr.cq);
if (tmpl.cq == NULL) {
ret = ENOMEM;
ERROR("%p: CQ creation failure: %s",
@@ -4005,6 +4043,11 @@ struct txq_mp2mr_mbuf_check_data {
(void *)dev);
goto err;
}
+ if (dev->data->dev_conf.intr_conf.rxq) {
+ ret = priv_intr_efd_enable(priv);
+ if (!ret)
+ ret = priv_create_intr_vec(priv);
+ }
ret = mlx4_priv_flow_start(priv);
if (ret) {
ERROR("%p: flow start failed: %s",
@@ -4197,6 +4240,10 @@ struct txq_mp2mr_mbuf_check_data {
assert(priv->ctx == NULL);
priv_dev_removal_interrupt_handler_uninstall(priv, dev);
priv_dev_link_interrupt_handler_uninstall(priv, dev);
+ if (priv->dev->data->dev_conf.intr_conf.rxq) {
+ priv_destroy_intr_vec(priv);
+ priv_intr_efd_disable(priv);
+ }
priv_unlock(priv);
memset(priv, 0, sizeof(*priv));
}
@@ -5157,6 +5204,8 @@ struct txq_mp2mr_mbuf_check_data {
.mac_addr_set = mlx4_mac_addr_set,
.mtu_set = mlx4_dev_set_mtu,
.filter_ctrl = mlx4_dev_filter_ctrl,
+ .rx_queue_intr_enable = mlx4_rx_intr_enable,
+ .rx_queue_intr_disable = mlx4_rx_intr_disable,
};
/**
@@ -5284,11 +5333,6 @@ struct txq_mp2mr_mbuf_check_data {
return atoi(val);
}
-static void
-mlx4_dev_link_status_han
Re: [dpdk-dev] [PATCH v3 1/3] lib: add Generic Receive Offload API framework
Hi Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Monday, May 29, 2017 8:19 PM > To: Hu, Jiayu > Cc: Ananyev, Konstantin ; dev@dpdk.org; > Wiles, Keith ; yuanhan@linux.intel.com > Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib: add Generic Receive Offload API > framework > > On Mon, May 29, 2017 at 10:22:57AM +, Hu, Jiayu wrote: > > Hi Konstantin, > > > > > -Original Message- > > > From: Ananyev, Konstantin > > > Sent: Sunday, May 28, 2017 12:51 AM > > > To: Hu, Jiayu > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > yuanhan@linux.intel.com > > > Subject: RE: [PATCH v3 1/3] lib: add Generic Receive Offload API > framework > > > > > > > > > Hi Jiayu, > > > > > > > > > > > Hi Konstantin, > > > > > > > > On Sat, May 27, 2017 at 07:12:16PM +0800, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Hu, Jiayu > > > > > > Sent: Saturday, May 27, 2017 4:42 AM > > > > > > To: Ananyev, Konstantin > > > > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > yuanhan@linux.intel.com > > > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload API > > > framework > > > > > > > > > > > > On Sat, May 27, 2017 at 07:10:21AM +0800, Ananyev, Konstantin > wrote: > > > > > > > Hi Jiayu, > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Hu, Jiayu > > > > > > > > Sent: Friday, May 26, 2017 8:26 AM > > > > > > > > To: Ananyev, Konstantin > > > > > > > > Cc: dev@dpdk.org; Wiles, Keith ; > > > yuanhan@linux.intel.com > > > > > > > > Subject: Re: [PATCH v3 1/3] lib: add Generic Receive Offload API > > > framework > > > > > > > > > > > > > > > > Hi Konstantin, > > > > > > > > > > > > > > > > On Wed, May 24, 2017 at 08:38:25PM +0800, Ananyev, > Konstantin > > > wrote: > > > > > > > > > > > > > > > > > > Hi Jiayu, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Konstantin, > > > > > > > > > > > > > > > > > > > > Thanks for your comments. My replies/questions are below. > > > > > > > > > > > > > > > > > > > > BRs, > > > > > > > > > > Jiayu > > > > > > > > > > > > > > > > > > > > On Mon, May 22, 2017 at 05:19:19PM +0800, Ananyev, > > > Konstantin wrote: > > > > > > > > > > > Hi Jiayu, > > > > > > > > > > > My comments/questions below. > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For applications, DPDK GRO provides three external > functions > > > to > > > > > > > > > > > > enable/disable GRO: > > > > > > > > > > > > - rte_gro_init: initialize GRO environment; > > > > > > > > > > > > - rte_gro_enable: enable GRO for a given port; > > > > > > > > > > > > - rte_gro_disable: disable GRO for a given port. > > > > > > > > > > > > Before using GRO, applications should explicitly call > > > rte_gro_init to > > > > > > > > > > > > initizalize GRO environment. After that, applications > > > > > > > > > > > > can > call > > > > > > > > > > > > rte_gro_enable to enable GRO and call rte_gro_disable > to > > > disable GRO for > > > > > > > > > > > > specific ports. > > > > > > > > > > > > > > > > > > > > > > I think this is too restrictive and wouldn't meet various > user's > > > needs. > > > > > > > > > > > User might want to: > > > > > > > > > > > - enable/disable GRO for particular RX queue > > > > > > > > > > > - or even setup different GRO types for different RX > > > > > > > > > > > queues, > > > > > > > > > > >i.e, - GRO over IPV4/TCP for queue 0, and GRO over > > > IPV6/TCP for queue 1, etc. > > > > > > > > > > > > > > > > > > > > The reason for enabling/disabling GRO per-port instead of > per- > > > queue is that LINUX > > > > > > > > > > controls GRO per-port. To control GRO per-queue indeed can > > > provide more flexibility > > > > > > > > > > to applications. But are there any scenarios that different > > > queues of a port may > > > > > > > > > > require different GRO control (i.e. GRO types and > enable/disable > > > GRO)? > > > > > > > > > > > > > > > > > > I think yes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - For various reasons, user might prefer not to use RX > callbacks > > > for various reasons, > > > > > > > > > > > But invoke gro() manually at somepoint in his code. > > > > > > > > > > > > > > > > > > > > An application-used GRO library can enable more flexibility > > > > > > > > > > to > > > applications. Besides, > > > > > > > > > > when perform GRO in ethdev layer or inside PMD drivers, it > > > > > > > > > > is > an > > > issue that > > > > > > > > > > rte_eth_rx_burst returns actually received packet number or > > > GROed packet number. And > > > > > > > > > > the same issue happens in GSO, and even more seriously. > This is > > > because applications > > > > > > > > > > , like VPP, always rely on the return value of > > > > > > > > > > rte_eth_tx_burst > to > > > decide further > > > > > > > > > > operations. If applications can direcly call GRO/GSO > > > > > > > > > > libraries, > > > this
Re: [dpdk-dev] [PATCH] event/sw: fix credit tracking in port dequeue
A couple nit-picks on the test, but once resolved:
Acked-by: Gage Eads
> -Original Message-
> From: Van Haaren, Harry
> Sent: Monday, May 29, 2017 10:17 AM
> To: dev@dpdk.org
> Cc: jerin.ja...@caviumnetworks.com; Eads, Gage ;
> Van Haaren, Harry
> Subject: [PATCH] event/sw: fix credit tracking in port dequeue
>
> This patch targets the next-eventdev tree.
>
> Single-link optimized ports previously did not correctly track credits when
> dequeued, and re-enqueued as a FORWARD type. This could "inflate" the
> number of credits in the system.
>
> A unit test is added to reproduce and verify the issue. The fixed
> implementation
> counts FORWARD packets and reduces the number of credits the port has if it
> is
> of single-link type.
>
> Fixes: 656af9180014 ("event/sw: add worker core functions")
>
> Signed-off-by: Harry van Haaren
> ---
> drivers/event/sw/sw_evdev_worker.c | 5
> test/test/test_eventdev_sw.c | 58
> +-
> 2 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/event/sw/sw_evdev_worker.c
> b/drivers/event/sw/sw_evdev_worker.c
> index 9cb6bef..b738506 100644
> --- a/drivers/event/sw/sw_evdev_worker.c
> +++ b/drivers/event/sw/sw_evdev_worker.c
> @@ -87,6 +87,7 @@ sw_event_enqueue_burst(void *port, const struct
> rte_event ev[], uint16_t num)
> return 0;
> }
>
> +uint32_t forwards = 0;
> for (i = 0; i < num; i++) {
> int op = ev[i].op;
> int outstanding = p->outstanding_releases > 0; @@ -95,6
> +96,7 @@ sw_event_enqueue_burst(void *port, const struct rte_event ev[],
> uint16_t num)
> p->inflight_credits -= (op == RTE_EVENT_OP_NEW);
> p->inflight_credits += (op == RTE_EVENT_OP_RELEASE) *
> outstanding;
> +forwards += (op == RTE_EVENT_OP_FORWARD);
>
> new_ops[i] = sw_qe_flag_map[op];
> new_ops[i] &= ~(invalid_qid << QE_FLAG_VALID_SHIFT); @@ -
> 113,6 +115,9 @@ sw_event_enqueue_burst(void *port, const struct rte_event
> ev[], uint16_t num)
> }
> }
>
> +/* handle directed port forward credits */
> +p->inflight_credits -= forwards * p->is_directed;
> +
> /* returns number of events actually enqueued */
> uint32_t enq = qe_ring_enqueue_burst_with_ops(p->rx_worker_ring,
> ev, i,
>new_ops);
> diff --git a/test/test/test_eventdev_sw.c b/test/test/test_eventdev_sw.c
> index
> b187d02..aaa9729 100644
> --- a/test/test/test_eventdev_sw.c
> +++ b/test/test/test_eventdev_sw.c
> @@ -548,6 +548,57 @@ test_single_directed_packet(struct test *t)
> return 0;
> }
>
> +static int
> +test_directed_forward_credits(struct test *t) {
> +uint32_t i;
> +int32_t err;
> +
> +if (init(t, 1, 1) < 0 ||
> +create_ports(t, 1) < 0 ||
> +create_directed_qids(t, 1, t->port) < 0)
> +return -1;
> +
> +if (rte_event_dev_start(evdev) < 0) {
> +printf("%d: Error with start call\n", __LINE__);
> +return -1;
> +}
> +
> +struct rte_event ev = {
> +.op = RTE_EVENT_OP_NEW,
> +.queue_id = 0,
> +};
> +
> +for (i = 0; i < 1000; i++) {
> +err = rte_event_enqueue_burst(evdev, 0, &ev, 1);
> +if (err < 0) {
> +printf("%d: error failed to enqueue\n", __LINE__);
> +return -1;
> +}
> +rte_event_schedule(evdev);
> +struct test_event_dev_stats stats;
> +err = test_event_dev_stats_get(evdev, &stats);
Does this stats get call serve a purpose?
> +if (err) {
> +printf("%d: error failed to get stats\n", __LINE__);
> +return -1;
> +}
> +
> +uint32_t deq_pkts;
> +deq_pkts = rte_event_dequeue_burst(evdev, 0, &ev, 1, 0);
> +if (deq_pkts != 1) {
> +printf("%d: error failed to deq\n", __LINE__);
> +return -1;
> +}
> +
> +/* re-write event to be a forward, and continue looping it */
> +ev.op = RTE_EVENT_OP_FORWARD;
> +}
> +
> +//rte_event_dev_dump(0, stdout);
Comment can be deleted
[dpdk-dev] [RFC 0/3] rte_mtr: generic ethdev API for metering and policing
This patch set introduces an ethdev-based generic API for Traffic Metering and Policing (MTR), which is yet another standard RX offload for Ethernet devices. Similar to rte_flow and rte_tm APIs, the configuration of MTR objects is done in their own namespace (rte_mtr) within the librte_ether library. Metering and policing action typically sits on top of flow classification, which is why MTR objects are enabled through a newly introduced rte_flow action, which is the only impact to rte_flow API. Q1: Why introduce ethdev-based traffic metering ad policing API? A1: Traffic metering and policing is a standard RX offload for Ethernet devices present in NICs, SoCs and NPUs across the industry. Q2: What's the connection between the new rte_mtr API and the existing librte_meter library? A2: The existing librte_meter library provides a SW implementation for a subset of the features exposed by this API. The rte_mtr API is agnostic to whether the implementation is HW, SW or mixed HW-SW. Q3: What's the connection between the new rte_mtr API and the existing rte_flow API? A3: The MTR object is hooked into ethdev RX processing path using a newly introduced rte_flow action, which is the only impact to the rte_flow API. The configuration of MTR objects is done in separate namespace (rte_mtr) outside of rte_flow API. Q4: Can the new rte_flow meter action drop packets? Is this a terminating action or not? A4: Although packets can be dropped by the newly introduced rte_flow meter action, this action is non-terminating, i.e. the action list typically contains at least one more action, which is a terminating action. Depending on the policer actions configured for the MTR object, some packets might be dropped while some packets passed to the next flow action with their color set in the packet mbuf. For example, a typical policer configuration is to drop the red packets while passing the green packets, therefore a subsequent rte_flow action needs to be configured to determine the final destination of green packets. Q5: Which are the main operations exposed for the MTR object? A5: Traffic metering, policing and statistics update. Traffic metering determines the color for the current packet (green, yellow, red) based on the previous history for this flow as maintained by the MTR object. The policer can do nothing, recolor or drop the packet. Stats are maintained for MTR object, as configured. Q6: Where is the output color stored for the current packet. A6: struct rte_mbuf::sched::color. Q7: Which are the supported metering algorithms? A7: srTCM (RFC 2697), trTCM (RFC 2698). Q8: Which are the supported policer actions? A8: Recolor the packet (keep or change the color determined by metering) or drop the packet. Cristian Dumitrescu (3): ethdev: add traffic metering and policing ops get API ethdev: add new rte_mtr API for traffic metering and policing rte_flow: add new action for traffic metering and policing MAINTAINERS| 4 + lib/librte_ether/Makefile | 7 +- lib/librte_ether/rte_ethdev.c | 12 + lib/librte_ether/rte_ethdev.h | 20 ++ lib/librte_ether/rte_ether_version.map | 14 + lib/librte_ether/rte_flow.h| 22 ++ lib/librte_ether/rte_mtr.c | 184 + lib/librte_ether/rte_mtr.h | 465 + lib/librte_ether/rte_mtr_driver.h | 188 + 9 files changed, 914 insertions(+), 2 deletions(-) create mode 100644 lib/librte_ether/rte_mtr.c create mode 100644 lib/librte_ether/rte_mtr.h create mode 100644 lib/librte_ether/rte_mtr_driver.h -- 2.7.4
[dpdk-dev] [RFC 1/3] ethdev: add traffic metering and policing ops get API
Following similar approach to rte_flow and rte_tm for modularity reasons.
Signed-off-by: Cristian Dumitrescu
---
lib/librte_ether/rte_ethdev.c | 12
lib/librte_ether/rte_ethdev.h | 20
lib/librte_ether/rte_ether_version.map | 6 ++
3 files changed, 38 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 83898a8..eb35ef0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3021,6 +3021,18 @@ rte_eth_dev_filter_ctrl(uint8_t port_id, enum
rte_filter_type filter_type,
return (*dev->dev_ops->filter_ctrl)(dev, filter_type, filter_op, arg);
}
+int
+rte_eth_dev_mtr_ops_get(uint8_t port_id, void *ops)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtr_ops_get, -ENOTSUP);
+ return (*dev->dev_ops->mtr_ops_get)(dev, ops);
+}
+
void *
rte_eth_add_rx_callback(uint8_t port_id, uint16_t queue_id,
rte_rx_callback_fn fn, void *user_param)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0f38b45..e3a1169 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1441,6 +1441,9 @@ typedef int (*eth_filter_ctrl_t)(struct rte_eth_dev *dev,
void *arg);
/**< @internal Take operations to assigned filter type on an Ethernet device */
+typedef int (*eth_mtr_ops_get_t)(struct rte_eth_dev *dev, void *ops);
+/**< @internal Get Trafffic Metering and Policing (MTR) operations */
+
typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
struct rte_eth_dcb_info *dcb_info);
/**< @internal Get dcb information on an Ethernet device */
@@ -1573,6 +1576,9 @@ struct eth_dev_ops {
/**< Get extended device statistic values by ID. */
eth_xstats_get_names_by_id_t xstats_get_names_by_id;
/**< Get name of extended device statistics by ID. */
+
+ eth_mtr_ops_get_t mtr_ops_get;
+ /**< Get Traffic Metering and Policing (MTR) operations. */
};
/**
@@ -4105,6 +4111,20 @@ int rte_eth_dev_filter_ctrl(uint8_t port_id, enum
rte_filter_type filter_type,
enum rte_filter_op filter_op, void *arg);
/**
+ * Take Traffic Metering and Policing (MTR) operations on an Ethernet device.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param arg
+ * Pointer to MTR operations.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ */
+int rte_eth_dev_mtr_ops_get(uint8_t port_id, void *ops);
+
+/**
* Get DCB information on an Ethernet device.
*
* @param port_id
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index d6726bb..9783aa1 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -156,3 +156,9 @@ DPDK_17.05 {
rte_eth_xstats_get_names_by_id;
} DPDK_17.02;
+
+DPDK_17.08 {
+global:
+
+ rte_eth_dev_mtr_ops_get;
+} DPDK_17.05;
--
2.7.4
[dpdk-dev] [RFC 2/3] ethdev: add new rte_mtr API for traffic metering and policing
Signed-off-by: Cristian Dumitrescu
---
MAINTAINERS| 4 +
lib/librte_ether/Makefile | 7 +-
lib/librte_ether/rte_ether_version.map | 8 +
lib/librte_ether/rte_mtr.c | 184 +
lib/librte_ether/rte_mtr.h | 465 +
lib/librte_ether/rte_mtr_driver.h | 188 +
6 files changed, 854 insertions(+), 2 deletions(-)
create mode 100644 lib/librte_ether/rte_mtr.c
create mode 100644 lib/librte_ether/rte_mtr.h
create mode 100644 lib/librte_ether/rte_mtr_driver.h
diff --git a/MAINTAINERS b/MAINTAINERS
index afb4cab..b025a7b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -240,6 +240,10 @@ Flow API
M: Adrien Mazarguil
F: lib/librte_ether/rte_flow*
+Traffic metering and policing API
+M: Cristian Dumitrescu
+F: lib/librte_ether/rte_mtr*
+
Crypto API
M: Declan Doherty
F: lib/librte_cryptodev/
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index 93fdde1..48f1098 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -1,6 +1,6 @@
# BSD LICENSE
#
-# Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+# Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
@@ -41,10 +41,11 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_ether_version.map
-LIBABIVER := 6
+LIBABIVER := 7
SRCS-y += rte_ethdev.c
SRCS-y += rte_flow.c
+SRCS-y += rte_mtr.c
#
# Export include files
@@ -56,5 +57,7 @@ SYMLINK-y-include += rte_eth_ctrl.h
SYMLINK-y-include += rte_dev_info.h
SYMLINK-y-include += rte_flow.h
SYMLINK-y-include += rte_flow_driver.h
+SYMLINK-y-include += rte_mtr.h
+SYMLINK-y-include += rte_mtr_driver.h
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index 9783aa1..89ea2ed 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -161,4 +161,12 @@ DPDK_17.08 {
global:
rte_eth_dev_mtr_ops_get;
+ rte_mtr_meter_profile_add;
+ rte_mtr_meter_profile_delete;
+ rte_mtr_create;
+ rte_mtr_destroy;
+ rte_mtr_meter_profile_update;
+ rte_mtr_policer_action_update;
+ rte_mtr_stats_update;
+ rte_mtr_stats_read;
} DPDK_17.05;
diff --git a/lib/librte_ether/rte_mtr.c b/lib/librte_ether/rte_mtr.c
new file mode 100644
index 000..efbe7fb
--- /dev/null
+++ b/lib/librte_ether/rte_mtr.c
@@ -0,0 +1,184 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of 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
+
+#include
+#include "rte_ethdev.h"
+#include "rte_mtr_driver.h"
+#include "rte_mtr.h"
+
+/* Get generic traffic metering and policing operations structure from a port.
*/
+const struct rte_mtr_ops *
+rte_mtr_ops_get(uint8_t port_id, struct rte_mtr_error *error)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ const struct rte_mtr_ops *ops;
+
+ if (!rte_eth_dev_is_valid_port(port_id)) {
+ rte_mtr_error_set(error,
+ ENODEV,
+ RTE_MTR_ERROR_TYPE_UNSPECIFIED,
+ NULL,
+ rte_strerror(ENODEV));
+ return NULL;
+ }
+
+
[dpdk-dev] [RFC 3/3] rte_flow: add new action for traffic metering and policing
Signed-off-by: Cristian Dumitrescu
---
lib/librte_ether/rte_flow.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index c47edbc..2942ca7 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -881,6 +881,14 @@ enum rte_flow_action_type {
* See struct rte_flow_action_vf.
*/
RTE_FLOW_ACTION_TYPE_VF,
+
+ /**
+* Traffic metering and policing (MTR).
+*
+* See struct rte_flow_action_meter.
+* See file rte_mtr.h for MTR object configuration.
+*/
+ RTE_FLOW_ACTION_TYPE_METER,
};
/**
@@ -974,6 +982,20 @@ struct rte_flow_action_vf {
};
/**
+ * RTE_FLOW_ACTION_TYPE_METER
+ *
+ * Traffic metering and policing (MTR).
+ *
+ * Packets matched by items of this type can be either dropped or passed to the
+ * next item with their color set by the MTR object.
+ *
+ * Non-terminating by default.
+ */
+struct rte_flow_action_meter {
+ uint32_t mtr_id; /**< MTR object ID created with rte_mtr_create(). */
+};
+
+/**
* Definition of a single action.
*
* A list of actions is terminated by a END action.
--
2.7.4
Re: [dpdk-dev] Proposed schedule dates for DPDK 17.08, 17.11 and 18.02
No comment? So the next dates will be 17.08 Proposal deadline: May 28 Integration deadline: June 29 Release: August 1 17.11 Proposal deadline: August 25, 2017 Integration deadline: September 29, 2017 Release: November 2, 2017 18.02 Proposal deadline: November 24, 2017 Integration deadline: January 5, 2018 Release: February 2, 2018 17/05/2017 15:02, Thomas Monjalon: > Hi, > > 04/05/2017 18:52, Mcnamara, John: > > The current 17.08 schedule dates are: > > > > 17.08 > > * Proposal deadline:May 28, 2017 > > * Integration deadline: June 29, 2017 > > * Release: August1, 2017 > > I think these dates are good and must be strictly respected. > It would be very bad (at least for me) to release later in August. > > > The following are proposed dates for 17.11 and 18.02. > > > > 17.11 > > * Proposal deadline:August25, 2017 > > As we can see in the following picture [1], > we work less in August and tend to send the proposals at the last minute. > [1] https://s12.postimg.org/g9uluz9u5/patchesv1.png > I don't know what can be done to avoid having hard days of reviews > after the August deadline. > Should we cut this period before or let a bit more days? > > > * Integration deadline: September 29, 2017 > > * Release: November 2, 2017 > > I'm OK for these ones. > > > 18.02 > > * Proposal deadline:November 24, 2017 > > * Integration deadline: December 29, 2017 > > The Christmas / New Year holidays will be from Dec 25 to Jan 1. > I think we could move the integration deadline to Jan 5. > > > * Release: February 2, 2018 > > The Chinese Spring Festival will be from Feb 15 to 21. > So we have a good margin. > > > These dates need to be discussed/agreed in the community since there are a > > lot of different holidays in these periods: August holidays, Christmas, > > New Year, Spring Festival.
[dpdk-dev] [PATCH] Correctly handle malloc_elem resize with padding
Currently when a malloc_elem is split after resizing, any padding
present in the elem is ignored. This causes the resized elem to be too
small when padding is present, and user data can overwrite the beginning
of the following malloc_elem.
Solve this by including the size of the padding when computing where to
split the malloc_elem.
Signed-off-by: Jamie Lavigne
---
lib/librte_eal/common/malloc_elem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/malloc_elem.c
b/lib/librte_eal/common/malloc_elem.c
index 42568e1..2ed1942 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -333,9 +333,11 @@ malloc_elem_resize(struct malloc_elem *elem, size_t size)
elem_free_list_remove(next);
join_elem(elem, next);
- if (elem->size - new_size >= MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){
+ const size_t new_total_size = new_size + elem->pad;
+
+ if (elem->size - new_total_size >= MIN_DATA_SIZE +
MALLOC_ELEM_OVERHEAD){
/* now we have a big block together. Lets cut it down a bit, by
splitting */
- struct malloc_elem *split_pt = RTE_PTR_ADD(elem, new_size);
+ struct malloc_elem *split_pt = RTE_PTR_ADD(elem,
new_total_size);
split_pt = RTE_PTR_ALIGN_CEIL(split_pt, RTE_CACHE_LINE_SIZE);
split_elem(elem, split_pt);
malloc_elem_free_list_insert(split_pt);
--
2.7.3.AMZN
[dpdk-dev] [PATCH v2] Correctly handle malloc_elem resize with padding
Currently when a malloc_elem is split after resizing, any padding
present in the elem is ignored. This causes the resized elem to be too
small when padding is present, and user data can overwrite the beginning
of the following malloc_elem.
Solve this by including the size of the padding when computing where to
split the malloc_elem.
Signed-off-by: Jamie Lavigne
---
lib/librte_eal/common/malloc_elem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/malloc_elem.c
b/lib/librte_eal/common/malloc_elem.c
index 42568e1..8766fa8 100644
--- a/lib/librte_eal/common/malloc_elem.c
+++ b/lib/librte_eal/common/malloc_elem.c
@@ -333,9 +333,11 @@ malloc_elem_resize(struct malloc_elem *elem, size_t size)
elem_free_list_remove(next);
join_elem(elem, next);
- if (elem->size - new_size >= MIN_DATA_SIZE + MALLOC_ELEM_OVERHEAD){
+ const size_t new_total_size = new_size + elem->pad;
+
+ if (elem->size - new_total_size >= MIN_DATA_SIZE +
MALLOC_ELEM_OVERHEAD) {
/* now we have a big block together. Lets cut it down a bit, by
splitting */
- struct malloc_elem *split_pt = RTE_PTR_ADD(elem, new_size);
+ struct malloc_elem *split_pt = RTE_PTR_ADD(elem,
new_total_size);
split_pt = RTE_PTR_ALIGN_CEIL(split_pt, RTE_CACHE_LINE_SIZE);
split_elem(elem, split_pt);
malloc_elem_free_list_insert(split_pt);
--
2.7.3.AMZN
Re: [dpdk-dev] [PATCH v2 20/25] bnxt: add support to get and clear VF specific stats
On Mon, May 29, 2017 at 12:43 PM, Ferruh Yigit
wrote:
> > +int rte_pmd_bnxt_get_tx_drop_count(uint8_t port, uint64_t *count)
> > +{
> > + struct rte_eth_dev *dev;
> > + struct rte_eth_dev_info dev_info;
> > + struct bnxt *bp;
> > +
> > + dev = &rte_eth_devices[port];
> > + rte_eth_dev_info_get(port, &dev_info);
> > + bp = (struct bnxt *)dev->data->dev_private;
> > +
> > + return bnxt_hwrm_func_qstats_tx_drop(bp, 0x, count);
> > +}
>
> This function is not to get VF stats from PF. As far as I can see this
> just gets queue stats, does this really needs to be PMD specific API,
> isn't this something generic?
Yes. That is right. It returns a count of number of packets which were not
transmitted
because it did not pass the MAC/VLAN spoof check. It does not necessarily
mean "failure to transmit" and so I don't think it is right to map it to
oerrors.
So in the current form I don't see a way to make a generic function out of
it.
[dpdk-dev] [PATCH] net/fm10k: initialize link status in device start
If port LSC interrupt is configured, application will read link
status directly, so driver need to prepare that value in advance.
Fixes: 9ae6068c86da ("fm10k: add dev start/stop")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Wang
---
drivers/net/fm10k/fm10k_ethdev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a742eec..54bf10c 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -84,6 +84,8 @@ static void fm10k_MAC_filter_set(struct rte_eth_dev *dev,
static void fm10k_set_rx_function(struct rte_eth_dev *dev);
static void fm10k_set_tx_function(struct rte_eth_dev *dev);
static int fm10k_check_ftag(struct rte_devargs *devargs);
+static int fm10k_link_update(struct rte_eth_dev *dev,
+ __rte_unused int wait_to_complete);
struct fm10k_xstats_name_off {
char name[RTE_ETH_XSTATS_NAME_SIZE];
@@ -1166,6 +1168,9 @@ static inline int fm10k_glort_valid(struct fm10k_hw *hw)
if (!(dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_VMDQ_FLAG))
fm10k_vlan_filter_set(dev, hw->mac.default_vid, true);
+ if (dev->data->dev_conf.intr_conf.lsc != 0)
+ fm10k_link_update(dev, 0);
+
return 0;
}
--
1.8.3.1
[dpdk-dev] [PATCH v3] net/e1000: fix checksum valid flags error
This problem is caused by a missing set of E1000_RXCSUM_CRCOFL
in eth_igb_rx_init(), it should be set to enable SCTP packet
L4 checksum.If it is not set, the printf message in cksum fwd
about L4 SCTP cksum flag is error.for example, even if the sctp
packet is not do L4 checksum, the print message is always
PKT_RX_L4_CKSUM_GOOD.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Wei Zhao
---
Changes in v2:
add more log for details.
Changes in v3:
fix a typo error.
---
drivers/net/e1000/igb_rxtx.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index b3b601b..1c80a2a 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -2402,9 +2402,11 @@ eth_igb_rx_init(struct rte_eth_dev *dev)
/* Enable both L3/L4 rx checksum offload */
if (dev->data->dev_conf.rxmode.hw_ip_checksum)
- rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
+ rxcsum |= (E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
else
- rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL);
+ rxcsum &= ~(E1000_RXCSUM_IPOFL | E1000_RXCSUM_TUOFL |
+ E1000_RXCSUM_CRCOFL);
E1000_WRITE_REG(hw, E1000_RXCSUM, rxcsum);
/* Setup the Receive Control Register. */
--
2.7.4
Re: [dpdk-dev] [PATCH 00/11] net/e1000: Consistent filter API
Hi, Ferruh > -Original Message- > From: Yigit, Ferruh > Sent: Monday, May 29, 2017 7:01 PM > To: Zhao1, Wei ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/11] net/e1000: Consistent filter API > > On 5/23/2017 8:12 AM, Wei Zhao wrote: > > The patches mainly finish following functions: > > 1) Store and restore all kinds of filters. > > 2) Parse all kinds of filters. > > 3) Add flow validate function. > > 4) Add flow create function. > > 5) Add flow destroy function. > > 6) Add flow flush function. > > > > zhao wei (11): > > net/e1000: store and restore TCP SYN filter > > net/e1000: restore n-tuple filter > > net/e1000: restore ether type filter > > net/e1000: restore flex type filter > > net/e1000: parse n-tuple filter > > net/e1000: parse ethertype filter > > net/e1000: parse TCP SYN filter > > net/e1000: parse flex filter > > net/e1000: create consistent filter > > net/e1000: destroy consistent filter > > net/e1000: flush all the filter > > Hi Wei, > > Patchset doesn't apply on top of latest next-net, can you please rebase it? > > Also there are various checkpatch warnings reported, can you please address > them? > I will rebase these patch and fix checkpatch warnings in v2 later. > Thanks, > ferruh
Re: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe pmd
Hi Radu,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Radu Nicolau
> Sent: Monday, May 29, 2017 11:23 PM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh; Iremonger, Bernard; Nicolau, Radu
> Subject: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe
> pmd
>
> Moved all bypass functions to ixgbe pmd and removed function pointers
> from the eth_dev_ops struct.
>
> Changes in v2:
> CONFIG_RTE_NIC_BYPASS removed, new option in the IXGBE section added,
> CONFIG_RTE_LIBRTE_IXGBE_BYPASS.
> Updated test-pmd to always include the bypass commands.
>
> Signed-off-by: Radu Nicolau
> diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> index e8fc9a6..efcaf68 100644
> --- a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> @@ -908,3 +908,109 @@ rte_pmd_ixgbe_set_tc_bw_alloc(uint8_t port,
>
> return 0;
> }
> +
> +#ifdef RTE_LIBRTE_IXGBE_BYPASS
> +int
> +rte_pmd_ixgbe_bypass_init(uint8_t port_id) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
Please reference the existing code to check "is_ixgbe_supported" here. Because
this API may be called by APP directly.
The same comments for all the other APIs below.
> +
> + dev = &rte_eth_devices[port_id];
> + ixgbe_bypass_init(dev);
> + return 0;
> +}
> +
> +int
> +rte_pmd_ixgbe_bypass_state_show(uint8_t port_id, uint32_t *state) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_state_show(dev, state); }
> +
> +int
> +rte_pmd_ixgbe_bypass_state_set(uint8_t port_id, uint32_t *new_state) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_state_store(dev, new_state); }
> +
> +int
> +rte_pmd_ixgbe_bypass_event_show(uint8_t port_id,
> + uint32_t event,
> + uint32_t *state)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_event_show(dev, event, state); }
> +
> +int
> +rte_pmd_ixgbe_bypass_event_store(uint8_t port_id,
> + uint32_t event,
> + uint32_t state)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_event_store(dev, event, state); }
> +
> +int
> +rte_pmd_ixgbe_bypass_wd_timeout_store(uint8_t port_id, uint32_t
> +timeout) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_wd_timeout_store(dev, timeout); }
> +
> +int
> +rte_pmd_ixgbe_bypass_ver_show(uint8_t port_id, uint32_t *ver) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_ver_show(dev, ver); }
> +
> +int
> +rte_pmd_ixgbe_bypass_wd_timeout_show(uint8_t port_id, uint32_t
> +*wd_timeout) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_wd_timeout_show(dev, wd_timeout); }
> +
> +int
> +rte_pmd_ixgbe_bypass_wd_reset(uint8_t port_id) {
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> + dev = &rte_eth_devices[port_id];
> + return ixgbe_bypass_wd_reset(dev);
> +}
Re: [dpdk-dev] [PATCH v3] net/e1000: fix checksum valid flags error
Hi,
> -Original Message-
> From: Zhao1, Wei
> Sent: Wednesday, May 31, 2017 11:03 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo; Zhao1, Wei
> Subject: [PATCH v3] net/e1000: fix checksum valid flags error
>
> This problem is caused by a missing set of E1000_RXCSUM_CRCOFL in
> eth_igb_rx_init(), it should be set to enable SCTP packet
> L4 checksum.If it is not set, the printf message in cksum fwd about L4 SCTP
> cksum flag is error.for example, even if the sctp packet is not do L4
> checksum,
> the print message is always PKT_RX_L4_CKSUM_GOOD.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Wei Zhao
Acked-by: Wenzhuo Lu
Re: [dpdk-dev] [PATCH 2/3] drivers/net: add support for IF-MIB and EtherLike-MIB for i40e
Hi Michal, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Michal Jastrzebski > Sent: Monday, May 22, 2017 10:32 PM > To: dev@dpdk.org > Cc: Pattan, Reshma ; Jain, Deepak K > ; Van Haaren, Harry > ; Jastrzebski, MichalX K > ; Azarewicz, PiotrX T > > Subject: [dpdk-dev] [PATCH 2/3] drivers/net: add support for IF-MIB and > EtherLike-MIB for i40e > > If-MIB xstats: > ifNumber > ifIndex > ifType > ifMtu > ifSpeed > ifPhysAddress > ifOperStatus > ifLastChange > ifHighSpeed > ifConnectorPresent > ifCounterDiscontinuityTime > > EtherLike-MIB xstats: > dot3PauseOperMode > dot3StatsDuplexStatus > dot3StatsRateControlAbility > dot3StatsRateControlStatus > dot3ControlFunctionsSupported > > Signed-off-by: Piotr Azarewicz > Signed-off-by: Michal Jastrzebski > --- Could you help to detail the purpose of the patch? seems you want to get some interface and link info instead of statistics.
Re: [dpdk-dev] Why DPDK is not using compressed TRIE for LPM6?
Hi Cristian, We thought of using compressed trie because in worst case it will become the simple trie but in general cases if will avoid very costly memory operation of accessing a new node. On 29-05-2017 18:12, Dumitrescu, Cristian wrote: -Original Message- From: Richardson, Bruce Sent: Monday, May 29, 2017 10:30 AM To: cs5120...@cse.iitd.ac.in Cc: dev@dpdk.org; Dumitrescu, Cristian Subject: Re: [dpdk-dev] Why DPDK is not using compressed TRIE for LPM6? On Sat, May 27, 2017 at 12:34:57AM +0530, Atul Shree wrote: > Hello All, > > I was doing some experiments related to LPM6 look up and I have added 20K > entries in the table. By looking at the rte_lpm6_lookup() code I found an > opportunity to compress the TRIE and there is a significant improvement > after compression. > Hi Atul, As far as I can recall, we already implemented a sort of tree compression in LPM for IPv6, but it might not be exactly what you have in mind, as there are multiple ways to compress a tree. It's been a while since I looked into this, so please bear with me for the next few clarifying questions: 1. Can you please provide a link to a good paper/article describing your algorithm. Our algorithm is well explained in this link. http://www.mathcs.emory.edu/~cheung/Courses/323/Syllabus/Text/trie02.html as well as on Wikipedia https://en.wikipedia.org/wiki/Radix_tree. 2. Can you summarize the key improvement for LPM6 as result of using this algorithm. Is this a performance improvement, how/why is it achieved, it is a general improvement benefiting all use-cases or just a specific subset? We have used the prefixes from the link https://github.com/efficient/gopt/blob/ipv6/data_dump/ipv6/uniq_ipv6_rib_201409. But this is just to demonstrate. Our idea have nothing to do with this dataset. We were getting more than 50% throughput improvement on this dataset. Our compressed trie was able to save around 0.5 lookups per prefix on average. There is always some some trade off involved with one or other data structure. This will give very high throughput on average. Haven't tested on worst case scenarios. Implementing this algorithm in DPDK will boils down to two choices i) Intel wants to perform better in worst case or ii) much better in average case. Thanks, Cristian Thank you Atul
