[dpdk-dev] Updating bnx2x firmware

[Martinx - ジェームズ]

On 24 March 2016 at 19:03, Harish Patil  wrote:

> >
> >Guys,
> >
> > Currently, the bnx2x.c driver looks for the following firmware files
> >(when
> >PMD is enabled for it):
> >
> >---
> >$ ~/sources/dpdk/dpdk-2.2.0/drivers/net/bnx2x$ grep lib\/firmware *
> >bnx2x.c:#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.2.51.0.fw"
> >bnx2x.c:#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.2.51.0.fw"
> >---
> >
> > Files bnx2x-e1h-7.2.51.0.fw and bnx2x-e2-7.2.51.0.fw.
> >
> >
> > However, on Ubuntu 16.04, the package linux-firmware comes with:
> >
> >---
> >$ dpkg -L linux-firmware | grep -i bnx2x
> >/lib/firmware/bnx2x/bnx2x-e1h-7.12.30.0.fw
> >/lib/firmware/bnx2x/bnx2x-e1-7.12.30.0.fw
> >/lib/firmware/bnx2x/bnx2x-e1-7.13.1.0.fw
> >/lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw
> >/lib/firmware/bnx2x/bnx2x-e1h-7.13.1.0.fw
> >/lib/firmware/bnx2x/bnx2x-e2-7.13.1.0.fw
> >---
> >
> >
> > Is it okay to just point bnx2x.c to a new version and rebuild it ?
> >
> > For example: bnx2x-e1h-7.13.1.0.fw and bnx2x-e2-7.13.1.0.fw ?
> >
> >
> > I would prefer to not manually download old firmware from Github:
> >
> > https://github.com/cernekee/linux-firmware/tree/master/bnx2x
> >
> >
> >Thanks,
> >Thiago
> >
>
> Hi Thiago
> Any reason why you don?t prefer to get the required FW file from other
> source?
>
> You can certainly download it from:
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre
> e/bnx2x
>
> Any other FW is an untested combination.
>
> Thanks,
> Harish
>

Hi Harish,

 Sure, I can download the firmware files, no problem... I just prefer to
stick with the packages/files from the distribution that I'm using (Ubuntu
16.04) but, on this case, I'll follow your recommendation.

 I don't know why Ubuntu removed the previous firmware files out from
"linux-firmware" package...

 Thanks for posting the git.kernel.org link!

Best,
Thiago

[dpdk-dev] [PATCH] mk: show version as a decimal integer

[Thomas Monjalon]

In order to ease packaging support of changes in DPDK build system,
introduce a decimal integer to compare version numbers.
It does not show the minor numbers as it is not meaningful for packaging.

Usage for DPDK 16.04:
% make showversionum
1604

Signed-off-by: Thomas Monjalon 
---
 mk/rte.sdkconfig.mk | 7 +++
 mk/rte.sdkroot.mk   | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index 564a5c3..a3acfe6 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -42,6 +42,13 @@ showversion:
else echo $$(($$5 - 16)); fi; \
fi

+.PHONY: showversionum
+showversionum:
+   @set -- \
+   $$(sed -rne 's,^#define 
RTE_VER_[A-Z_]*[[:space:]]+([0-9]+).*,\1,p' \
+   
$(RTE_SRCDIR)/lib/librte_eal/common/include/rte_version.h); \
+   printf '%02d%02d\n' "$$1" "$$2"
+
 INSTALL_CONFIGS := $(sort $(filter-out %~,\
$(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\
$(wildcard $(RTE_SRCDIR)/config/defconfig_*
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 2424dce..55a9d8a 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -85,8 +85,8 @@ export ROOTDIRS-y ROOTDIRS- ROOTDIRS-n
 .PHONY: default
 default: all

-.PHONY: config showconfigs showversion
-config showconfigs showversion:
+.PHONY: config showconfigs showversion showversionum
+config showconfigs showversion showversionum:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkconfig.mk $@

 .PHONY: test fast_test ring_test mempool_test perf_test coverage
-- 
2.7.0

[dpdk-dev] [PATCH] scripts: improve quiet checkpatch

[Thomas Monjalon]

2015-12-13 03:37, Thomas Monjalon:
> The option --no-summary will remove this line in quiet mode:
>   total: 1 errors, 0 warnings, 7 lines checked
> 
> Signed-off-by: Thomas Monjalon 

Applied

[dpdk-dev] [PATCH] scripts: fix checkpatch help

[Thomas Monjalon]

2016-02-16 15:36, Olivier Matz:
> When started without defining DPDK_CHECKPATCH_PATH, the usage was not
> displayed.
> 
> Signed-off-by: Olivier Matz 

Applied, thanks

[dpdk-dev] Updating bnx2x firmware

[Harish Patil]

>
>Guys,
>
> Currently, the bnx2x.c driver looks for the following firmware files
>(when
>PMD is enabled for it):
>
>---
>$ ~/sources/dpdk/dpdk-2.2.0/drivers/net/bnx2x$ grep lib\/firmware *
>bnx2x.c:#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.2.51.0.fw"
>bnx2x.c:#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.2.51.0.fw"
>---
>
> Files bnx2x-e1h-7.2.51.0.fw and bnx2x-e2-7.2.51.0.fw.
>
>
> However, on Ubuntu 16.04, the package linux-firmware comes with:
>
>---
>$ dpkg -L linux-firmware | grep -i bnx2x
>/lib/firmware/bnx2x/bnx2x-e1h-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1-7.13.1.0.fw
>/lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw
>/lib/firmware/bnx2x/bnx2x-e1h-7.13.1.0.fw
>/lib/firmware/bnx2x/bnx2x-e2-7.13.1.0.fw
>---
>
>
> Is it okay to just point bnx2x.c to a new version and rebuild it ?
>
> For example: bnx2x-e1h-7.13.1.0.fw and bnx2x-e2-7.13.1.0.fw ?
>
>
> I would prefer to not manually download old firmware from Github:
>
> https://github.com/cernekee/linux-firmware/tree/master/bnx2x
>
>
>Thanks,
>Thiago
>

Hi Thiago
Any reason why you don?t prefer to get the required FW file from other
source?

You can certainly download it from:
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre
e/bnx2x

Any other FW is an untested combination.

Thanks,
Harish

[dpdk-dev] [PATCH 0/2] tools/setup.sh fixes

[Thomas Monjalon]

2016-03-14 17:45, Jerin Jacob:
> - added support to work with systems other than 2MB page size
> - added support to work with built-in kernel modules
> 
> 
> Jerin Jacob (2):
>   tools/setup.sh: remove 2MB huge page size hard-cording
>   tools/setup.sh: Support built-in kernel modules

Applied, thanks

[dpdk-dev] [PATCH v2] tools/dpdk_nic_bind: fix flake8 warnings

[Thomas Monjalon]

> > flake8 checks were run for both python 2.7 and 3.4
> > 
> > There were some style issues as:
> > - Line width > 79
> > - No double blank line before function definition
> > - No double blank space before inline comment
> > - Some other minor issues
> > 
> > Signed-off-by: Mauricio Vasquez B
> > 
> 
> Acked-by: John McNamara 

Applied, thanks

[dpdk-dev] [PATCH] Remove the extra blank lines in the output

[Thomas Monjalon]

2015-12-08 12:52, Keith Wiles:
> The output for the core list included an extra linefeed making
> the number of lines displayed much larger then required.
> 
> Signed-off-by: Keith Wiles 

Applied, thanks

[dpdk-dev] [PATCH] autotests: fix pmd ring

[Thomas Monjalon]

2016-03-15 13:25, Olivier Matz:
> This test expects that a vdev is instanciated on the command
> line. If it's not the case, just skip this part.
> 
> Signed-off-by: Olivier Matz 

Applied, thanks

[dpdk-dev] [PATCH] autotests: display command line when starting

[Thomas Monjalon]

2016-03-15 13:25, Olivier Matz:
> It's useful for debug purposes to see the command line used by
> autotest.py.
> 
> Signed-off-by: Olivier Matz 

Applied, thanks

[dpdk-dev] [PATCH v2 0/3] Extend list of supported algorithms in L2fwd-crypto

[Thomas Monjalon]

2016-03-22 21:23, Pablo de Lara:
> New cipher/authentication algorithms are supported in cryptodev,
> so L2fwd-crypto needs to have the list of supported algorithms updated.
> 
> Changes in v2:
> - Added other two algorithms
> - Modified offset and length in bits for SNOW3G algorithms
> 
> Pablo de Lara (3):
>   l2fwd-crypto: add SNOW3G algorithms
>   l2fwd-crypto: add AES GCM in auth algo list
>   l2fwd-crypto: add NULL in cipher/auth algo list

Applied, thanks

[dpdk-dev] [PATCH v2] l2fwd-crypto: fix incorrect command line help

[Thomas Monjalon]

> > Previous cdev parameter was changed to cdev_type, to select a crypto device
> > type preference (HW/SW/ANY), instead of the device itself (QAT/AESNI...).
> > Also deleted cdev duplicated parameter from the help.
> > 
> > Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
> > 
> > Signed-off-by: Pablo de Lara 
> > Acked-by: Fiona Trahe 
> > ---
> > 
> > Changes in v2:
> > - Removed duplicated parameter in command line help
> > 
> >  examples/l2fwd-crypto/main.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> Acked-by: Fiona Trahe 

Applied, thanks.

[dpdk-dev] Updating bnx2x firmware

[Martinx - ジェームズ]

Guys,

 Currently, the bnx2x.c driver looks for the following firmware files (when
PMD is enabled for it):

---
$ ~/sources/dpdk/dpdk-2.2.0/drivers/net/bnx2x$ grep lib\/firmware *
bnx2x.c:#define FW_NAME_57711 "/lib/firmware/bnx2x/bnx2x-e1h-7.2.51.0.fw"
bnx2x.c:#define FW_NAME_57810 "/lib/firmware/bnx2x/bnx2x-e2-7.2.51.0.fw"
---

 Files bnx2x-e1h-7.2.51.0.fw and bnx2x-e2-7.2.51.0.fw.


 However, on Ubuntu 16.04, the package linux-firmware comes with:

---
$ dpkg -L linux-firmware | grep -i bnx2x
/lib/firmware/bnx2x/bnx2x-e1h-7.12.30.0.fw
/lib/firmware/bnx2x/bnx2x-e1-7.12.30.0.fw
/lib/firmware/bnx2x/bnx2x-e1-7.13.1.0.fw
/lib/firmware/bnx2x/bnx2x-e2-7.12.30.0.fw
/lib/firmware/bnx2x/bnx2x-e1h-7.13.1.0.fw
/lib/firmware/bnx2x/bnx2x-e2-7.13.1.0.fw
---


 Is it okay to just point bnx2x.c to a new version and rebuild it ?

 For example: bnx2x-e1h-7.13.1.0.fw and bnx2x-e2-7.13.1.0.fw ?


 I would prefer to not manually download old firmware from Github:

 https://github.com/cernekee/linux-firmware/tree/master/bnx2x


Thanks,
Thiago

[dpdk-dev] [PATCH 1/2] szedata2: new poll mode driver

[Matej Vido]

D?a 21.03.2016 o 18:45 Stephen Hemminger nap?sal(a):
> On Fri, 19 Jun 2015 10:25:00 +0200
> Matej Vido  wrote:
>
>> +static struct ether_addr eth_addr = {
>> +.addr_bytes = { 0, 0, 0, 0x1, 0x2, 0x3 }
>> +};
> ...
>
>> static int
>> rte_szedata2_eth_dev_init(struct rte_eth_dev *dev)
>> {
> ..
>>  /* Allocate space for one mac address */
>>  data->mac_addrs = rte_zmalloc(data->name, sizeof(struct ether_addr),
>>  RTE_CACHE_LINE_SIZE);
>>  if (data->mac_addrs == NULL) {
>>  RTE_LOG(ERR, PMD, "Could not alloc space for MAC address!\n");
>>  munmap(dev->pci_dev->mem_resource[PCI_RESOURCE_NUMBER].addr,
>>  dev->pci_dev->mem_resource[PCI_RESOURCE_NUMBER].len);
>>  return -EINVAL;
>>  }
>>
>>  ether_addr_copy(_addr, data->mac_addrs);
> If your hardware has no permanent MAC address, then please use 
> eth_random_addr()
> to make one on boot, rather than having a bogus static value.
Hi,

I will use it.

Thanks,
Matej

[dpdk-dev] [PATCH 2/2 v6] i40e: Add floating VEB support in i40e

[Zhe Tao]

This patch add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
the floating VEB. When connect to the floating VEB a new floating VEB is
created. Now all the VFs need to connect to floating VEB or legacy VEB,
cannot connect to both of them. The PF and VMDQ,FD VSIs still connect to
the old legacy VEB/VEPA.

All the VEB/VEPA concepts are not specific for FVL, they are defined in the
802.1Qbg spec.

Now the floating VEB feature is only avaiable in the specific version of FW.

Signed-off-by: Zhe Tao 
---
 doc/guides/nics/i40e.rst   |   7 +++
 doc/guides/rel_notes/release_16_04.rst |   2 +
 drivers/net/i40e/i40e_ethdev.c | 110 ++---
 drivers/net/i40e/i40e_ethdev.h |   2 +
 drivers/net/i40e/i40e_pf.c |  11 +++-
 5 files changed, 109 insertions(+), 23 deletions(-)

diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 4019b41..520ea09 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -366,3 +366,10 @@ Delete all flow director rules on a port:

testpmd> flush_flow_director 0

+Floating VEB
+~
+FVL can support floating VEB feature.
+To enable this feature, the user should pass a devargs parameter to the EAL
+like "-w 84:00.0,enable_floating=1", and the application will make sure the PMD
+will use the floating VEB feature for all the VFs created by this PF device.
+
diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 9922bcb..1545872 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -248,6 +248,8 @@ This section should contain new features added in this 
release. Sample format:

   New application implementing an IPsec Security Gateway.

+* **Added floating VEB support for FVL.**
+

 Resolved Issues
 ---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 01f1d3d..87801d3 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3734,21 +3734,27 @@ i40e_veb_release(struct i40e_veb *veb)
struct i40e_vsi *vsi;
struct i40e_hw *hw;

-   if (veb == NULL || veb->associate_vsi == NULL)
+   if (veb == NULL)
return -EINVAL;

if (!TAILQ_EMPTY(>head)) {
PMD_DRV_LOG(ERR, "VEB still has VSI attached, can't remove");
return -EACCES;
}
+   /* associate_vsi field is NULL for floating VEB */
+   if (veb->associate_vsi != NULL) {
+   vsi = veb->associate_vsi;
+   hw = I40E_VSI_TO_HW(vsi);

-   vsi = veb->associate_vsi;
-   hw = I40E_VSI_TO_HW(vsi);
+   vsi->uplink_seid = veb->uplink_seid;
+   vsi->veb = NULL;
+   } else {
+   veb->associate_pf->main_vsi->floating_veb = NULL;
+   hw = I40E_VSI_TO_HW(veb->associate_pf->main_vsi);
+   }

-   vsi->uplink_seid = veb->uplink_seid;
i40e_aq_delete_element(hw, veb->seid, NULL);
rte_free(veb);
-   vsi->veb = NULL;
return I40E_SUCCESS;
 }

@@ -3760,9 +3766,9 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
int ret;
struct i40e_hw *hw;

-   if (NULL == pf || vsi == NULL) {
+   if (NULL == pf) {
PMD_DRV_LOG(ERR, "veb setup failed, "
-   "associated VSI shouldn't null");
+   "associated PF shouldn't null");
return NULL;
}
hw = I40E_PF_TO_HW(pf);
@@ -3774,11 +3780,19 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
}

veb->associate_vsi = vsi;
+   veb->associate_pf = pf;
TAILQ_INIT(>head);
-   veb->uplink_seid = vsi->uplink_seid;
+   veb->uplink_seid = vsi ? vsi->uplink_seid : 0;

-   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
-   I40E_DEFAULT_TCMAP, false, >seid, false, NULL);
+   /* create floating veb if vsi is NULL */
+   if (vsi != NULL) {
+   ret = i40e_aq_add_veb(hw, veb->uplink_seid, vsi->seid,
+ I40E_DEFAULT_TCMAP, false,
+ >seid, false, NULL);
+   } else {
+   ret = i40e_aq_add_veb(hw, 0, 0, I40E_DEFAULT_TCMAP,
+ true, >seid, false, NULL);
+   }

if (ret != I40E_SUCCESS) {
PMD_DRV_LOG(ERR, "Add veb failed, aq_err: %d",
@@ -3794,10 +3808,10 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
hw->aq.asq_last_status);
goto fail;
}
-
/* Get VEB bandwidth, to be implemented */
/* Now associated vsi binding to the VEB, set uplink to this VEB */
-   vsi->uplink_seid = veb->seid;
+   if (vsi)
+   vsi->uplink_seid = veb->seid;

return veb;
 fail:
@@ -3830,12 

[dpdk-dev] [PATCH 1/2 v6] i40e: support floating VEB config

[Zhe Tao]

Add the new floating related argument option in the devarg.
Using this parameter, all the samples can decide whether to use legacy VEB/VEPA
or floating VEB.
To enable this feature, the user should pass a devargs parameter to the EAL
like "-w 84:00.0,enable_floating=1", and the application will make sure the PMD
will use the floating VEB feature for all the VFs created by this PF device.

Signed-off-by: Zhe Tao 
---
 drivers/net/i40e/i40e_ethdev.c | 44 ++
 drivers/net/i40e/i40e_ethdev.h |  6 ++
 2 files changed, 50 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 6fdae57..01f1d3d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -739,6 +739,44 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
  " frames from VSIs.");
 }

+static int i40e_check_floating_handler(__rte_unused const char *key,
+  const char *value,
+  __rte_unused void *opaque)
+{
+   if (strcmp(value, "1"))
+   return -1;
+
+   return 0;
+}
+
+static int
+i40e_check_floating(struct rte_devargs *devargs)
+{
+   struct rte_kvargs *kvlist;
+   const char *floating_key = "enable_floating";
+
+   if (devargs == NULL)
+   return 0;
+
+   kvlist = rte_kvargs_parse(devargs->args, NULL);
+   if (kvlist == NULL)
+   return 0;
+
+   if (!rte_kvargs_count(kvlist, floating_key)) {
+   rte_kvargs_free(kvlist);
+   return 0;
+   }
+   /* Floating is enabled when there's key-value pair: enable_floating=1 */
+   if (rte_kvargs_process(kvlist, floating_key,
+  i40e_check_floating_handler, NULL) < 0) {
+   rte_kvargs_free(kvlist);
+   return 0;
+   }
+   rte_kvargs_free(kvlist);
+
+   return 1;
+}
+
 static int
 eth_i40e_dev_init(struct rte_eth_dev *dev)
 {
@@ -829,6 +867,12 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
 ((hw->nvm.version >> 4) & 0xff),
 (hw->nvm.version & 0xf), hw->nvm.eetrack);

+   /* Need the special FW version support floating VEB */
+   if (hw->aq.fw_maj_ver >= FLOATING_FW_MAJ) {
+   pf->floating = i40e_check_floating(pci_dev->devargs);
+   } else {
+   pf->floating = false;
+   }
/* Clear PXE mode */
i40e_clear_pxe_mode(hw);

diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index 1c75672..7dc6936 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -36,6 +36,7 @@

 #include 
 #include 
+#include 

 #define I40E_VLAN_TAG_SIZE4

@@ -171,6 +172,10 @@ enum i40e_flxpld_layer_idx {
 #define I40E_QUEUE_ITR_INTERVAL_DEFAULT 32 /* 32 us */
 #define I40E_QUEUE_ITR_INTERVAL_MAX 8160 /* 8160 us */

+/* Special FW support this floating VEB feature */
+#define FLOATING_FW_MAJ 5
+#define FLOATING_FW_MIN 0
+
 struct i40e_adapter;

 /**
@@ -446,6 +451,7 @@ struct i40e_pf {
struct i40e_fc_conf fc_conf; /* Flow control conf */
struct i40e_mirror_rule_list mirror_list;
uint16_t nb_mirror_rule;   /* The number of mirror rules */
+   uint16_t floating; /* The flag to use the floating VEB */
 };

 enum pending_msg {
-- 
2.1.4

[dpdk-dev] [PATCH 0/2 v6] i40e: Add floating VEB support for i40e

[Zhe Tao]

This patch-set add the support for floating VEB in i40e.
All the VFs VSIs can decide whether to connect to the legacy VEB/VEPA or
the floating VEB. When connect to the floating VEB a new floating VEB is
created. Now all the VFs need to connect to floating VEB or legacy VEB,
cannot connect to both of them. The PF and VMDQ,FD VSIs connect to
the old legacy VEB/VEPA.

All the VEB/VEPA concepts are not specific for FVL, they are defined in the
802.1Qbg spec.

This floating VEB only take effects on the specific version F/W.

Zhe Tao (2):
  support floating VEB config
  Add floating VEB support in i40e

 doc/guides/nics/i40e.rst   |   7 ++
 doc/guides/rel_notes/release_16_04.rst |   2 +
 drivers/net/i40e/i40e_ethdev.c | 154 -
 drivers/net/i40e/i40e_ethdev.h |   8 ++
 drivers/net/i40e/i40e_pf.c |  11 ++-
 5 files changed, 159 insertions(+), 23 deletions(-)

V2: Added the release notes and changed commit log. 
V3: Changed the VSI release operation. 
V4: Added the FW version check otherwise it will cause the segment fault.
V5: Edited the code for new share code APIs
V6: Changed the floating VEB configuration method 

-- 
2.1.4

[dpdk-dev] Question on examples/multi_process app

[Harish Patil]

>
>
>> >
>> >> -Original Message-
>> >> From: Richardson, Bruce
>> >> Sent: Wednesday, March 23, 2016 11:45 AM
>> >> To: Ananyev, Konstantin
>> >> Cc: Harish Patil; dev at dpdk.org
>> >> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >>
>> >> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
>> >> > Hi everyone,
>> >> >
>> >> > > -Original Message-
>> >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>> >>Richardson
>> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> >> > > To: Harish Patil
>> >> > > Cc: dev at dpdk.org
>> >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> >> > >
>> >> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>> >> > > > Hi,
>> >> > > > I have a question regarding symmetric_mp and mp_server
>> >>applications under
>> >> > > > examples/multi_process. In those apps,
>> >>rte_eth_promiscuous_enable() is
>> >> > > > called before rte_eth_dev_start(). Is this the correct way to
>> >>initialize
>> >> > > > the port/device? As per the description in
>> >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>> >> > > >
>> >> > > > "The functions exported by the application Ethernet API to
>>setup
>> >>a device
>> >> > > > designated by its port identifier must be invoked in the
>> >>following order:
>> >> > > >
>> >> > > > * rte_eth_dev_configure()
>> >> > > > * rte_eth_tx_queue_setup()
>> >> > > > * rte_eth_rx_queue_setup()
>> >> > > > * rte_eth_dev_start()
>> >> > > >
>> >> > > > Then, the network application can invoke, in any order, the
>> >>functions
>> >> > > > exported by the Ethernet API to get the MAC address of a given
>> >>device, to
>> >> > > > get the speed and the status of a device physical link, to
>> >> > > > receive/transmit [burst of] packets, and so on.?
>> >> > > >
>> >> > > > So should I consider this as an application issue or whether
>>the
>> >>PMD is
>> >> > > > expected to handle it? If PMD is to handle it, then should the
>> >>PMD be:
>> >> > > >
>> >> > > > 1) Rejecting the Promisc config? OR
>> >> > > > 2) Cache the config and apply when dev_start() is called at
>>later
>> >>point?
>> >> >
>> >> > Yes as I remember 2) is done.
>> >> > dev_start() invokes rte_eth_dev_config_restore(), which restores
>> >> > promisc mode, mac addresses, etc.
>> >> >
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Harish
>> >> > > >
>> >> > > Good question. I think most/all of the Intel adapters, - for
>>which
>> >>the app was
>> >> > > originally written, way back in the day when there were only 2
>>PMDs
>> >>in DPDK :)
>> >> > > - will handle the promiscuous mode call either before or after
>>the
>> >>dev start.
>> >> > > Assuming that's the case, and if it makes life easier for other
>> >>driver writers,
>> >> > > we should indeed standardize on one supported way of doing
>>things -
>> >>the way
>> >> > > specified in the documentation being that one way, I would guess.
>> >> > >
>> >> > > So, e1000, ixgbe maintainers - do you see any issues with forcing
>> >>the promiscuous
>> >> > > mode set API to be called after the call to dev_start()?
>> >> >
>> >> > Not sure, why do we need to enforce that restriction?
>> >> > Is there any problem with current way?
>> 
>> Yes, at least with the our driver/firmware interface. The port/device
>> bring-up is carried out in a certain order which requires port config
>>like
>> promisc mode is called after dev_start().
>> 
>> >>
>> >> It complicates things for driver writers is all,
>> >
>> >Not sure how?
>> >All this replay is done at rte_ethdev layer.
>> >Honestly, so far I don't remember any complaint about promisc on/off.
>> >
>> >> and conflicts slightly with
>> >> what is stated in the docs.
>> >
>> >Update the docs? :)
>> 
>> Anyway, please let me know what you guys decide? If the app is changed
>> then nothing needs to done on driver side. Otherwise I have to think of
>> how to handle this.
>> 
>
>So you are saying that for your device if dev_ops->promiscuous_enable()
>is called before dev_ops->dev_start(), it would cause  a problem right?
>Konstantin 
>
>

Yes, with the way it is implemented currently it would pose a problem.
Please note that it can be addressed in the driver, not an issue. However,
I wanted to be sure if the app behavior is correct. Either ways, please
let me know - I can take care of both.

Thanks,
Harish

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Matej Vido]

D?a 17.03.2016 o 19:08 Thomas Monjalon nap?sal(a):
> There are still too few tests and reviews, especially for
> autonegotiation with Intel devices (patch #6).
> I would not be surprised to see some bugs in this rework.
>
> The capabilities must be adapted per device. It can be
> improved in a separate patch.
>
> It will be integrated in 16.04-rc2.
> Please test and review shortly, thanks!
>
> [...]
Tested-by: Matej Vido 

Correct speed is displayed for COMBO-100G card.

Regards,
Matej

[dpdk-dev] [PATCH v3 0/4] arm: detect NEON by RTE_MACHINE_CPUFLAG_NEON flag only

[Thomas Monjalon]

2016-03-19 20:58, Jan Viktorin:
> Hello,
> 
> finally, I've broken the original patch into 4 pieces as it solves more issues
> and not just a single one.
> 
> * As Thomas have already mentioned, the CONFIG_RTE_ARCH_ARM_NEON is 
> confusing. 
>   So, I've decided to remove it entirely and provide another option for a more
>   specific purpose: CONFIG_RTE_ARCH_ARM_NEON_MEMCPY.
> 
> * The RTE_MACHINE_CPUFLAG_NEON detection is now based on __ARM_NEON as only
>   this compiler definition gives us the arm_neon.h and is compatible with
>   arm64. In DPDK, the RTE_MACHINE_CPUFLAG_NEON should be prefered over the
>   __ARM_NEON. I'd recommend the same for x86 code (__SSE2__)... 
> 
> History:
> v2
> * fix l3fwm_em.c to refer RTE_MACHINE_CPUFLAG_NEON instead of __ARM_NEON
> 
> v3
> * divided into 4 patches as there are more independent problems
> * compiles well for armv7
> * (probably) fixes RTE_MACHINE_CPUFLAG_NEON detection on arm64

Applied with discussed changes.

[dpdk-dev] [PATCH v2] ixgbe: disable icc compile warning

[Ananyev, Konstantin]

> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, March 24, 2016 5:35 PM
> To: dev at dpdk.org
> Cc: Stephen Hemminger; Ananyev, Konstantin; Yigit, Ferruh
> Subject: [PATCH v2] ixgbe: disable icc compile warning
> 
> icc (icc (ICC) 16.0.1 20151021) is generating following compile error:
> "
>   CC ixgbe_rxtx.o
>   .../drivers/net/ixgbe/ixgbe_rxtx.c(153): error #3656: variable
>   "free" may be used before its value is set
>   (nb_free > 0 && m->pool != free[0]->pool)) {
>^
> "
> 
> Indeed this is a false positive and code is correct.
> "nb_free" check prevents the free[] access before its value set.
> 
> Disabling this icc warning (#3656) for file ixgbe_rxtx.c.
> 
> Signed-off-by: Ferruh Yigit 
> ---
>  drivers/net/ixgbe/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
> index c032775..50bf51c 100644
> --- a/drivers/net/ixgbe/Makefile
> +++ b/drivers/net/ixgbe/Makefile
> @@ -49,6 +49,8 @@ ifeq ($(CC), icc)
>  #
>  CFLAGS_BASE_DRIVER = -wd174 -wd593 -wd869 -wd981 -wd2259
> 
> +CFLAGS_ixgbe_rxtx.o += -wd3656
> +
>  else ifeq ($(CC), clang)
>  #
>  # CFLAGS for clang
> --

Acked-by: Konstantin Ananyev 

> 2.5.0

[dpdk-dev] [PATCH v4 0/3] Fix incorrect max TX queue numbers for ixgbe

[Bruce Richardson]

On Thu, Mar 24, 2016 at 05:44:58PM +, Bruce Richardson wrote:
> On Thu, Mar 24, 2016 at 03:22:01PM +, Pablo de Lara wrote:
> > IXGBE supports 128 TX queues. However, the full 128 queues
> > are only available in VT and DCB mode.
> > In normal default "none" mode (VT/DCB off) the maximum number
> > of available queues is only 64.
> > IXGBE doesn't check the mode when reporting the available
> > number of queues. If a queue larger than 64 is used in default mode,
> > the TX packets will be dropped silently.
> > 
> > This patchset:
> > 
> > - Modifies the device info to show the correct maximum number of available 
> > TX queues,
> >   depending on the mode.
> > 
> > - Adds a check to forbid using a queue number larger than 64
> >   during device configuration (in default mode), so that the problem is
> >   reported as early as possible.
> > 
> > - It also changes the order of where the dev_conf parameters are copied
> >   into the dev structure so that the correct maximum number of queues
> >   is reported for the correct mode.
> > 
> > Changes in v4:
> > - Split the patch in three smaller patches
> > - Updated release notes document
> > 
> > Changes in v3:
> > - Fixed wrong set of TX queues for 82596EB
> > 
> > Changes in v2:
> > 
> > - Reorder memcpy of device configuration in rte_eth_dev_configure(),
> >   so function gets the correct maximum number of queues
> >   (depending on the operation mode), before checking the
> >   requested number of queues.
> > - Renamed new macro
> > - Reworded/wrapped commit message
> > 
> > Pablo de Lara (1):
> >   ethdev: copy device configuration earlier
> > 
> > Wenzhuo Lu (2):
> >   ixgbe: fix incorrect tx queue number assignment
> >   ixgbe: fix incorrect max tx queue number
> > 
> All three patches are fixes, so all three should have "Fixes" lines in them.
> Please remember for next time!
> 
> Thanks,
> /Bruce

Applied to dpdk-next-net/rel_16_04, with added fixes lines in each case.

/Bruce

[dpdk-dev] [PATCH v4 0/3] Fix incorrect max TX queue numbers for ixgbe

[Bruce Richardson]

On Thu, Mar 24, 2016 at 03:22:01PM +, Pablo de Lara wrote:
> IXGBE supports 128 TX queues. However, the full 128 queues
> are only available in VT and DCB mode.
> In normal default "none" mode (VT/DCB off) the maximum number
> of available queues is only 64.
> IXGBE doesn't check the mode when reporting the available
> number of queues. If a queue larger than 64 is used in default mode,
> the TX packets will be dropped silently.
> 
> This patchset:
> 
> - Modifies the device info to show the correct maximum number of available TX 
> queues,
>   depending on the mode.
> 
> - Adds a check to forbid using a queue number larger than 64
>   during device configuration (in default mode), so that the problem is
>   reported as early as possible.
> 
> - It also changes the order of where the dev_conf parameters are copied
>   into the dev structure so that the correct maximum number of queues
>   is reported for the correct mode.
> 
> Changes in v4:
> - Split the patch in three smaller patches
> - Updated release notes document
> 
> Changes in v3:
> - Fixed wrong set of TX queues for 82596EB
> 
> Changes in v2:
> 
> - Reorder memcpy of device configuration in rte_eth_dev_configure(),
>   so function gets the correct maximum number of queues
>   (depending on the operation mode), before checking the
>   requested number of queues.
> - Renamed new macro
> - Reworded/wrapped commit message
> 
> Pablo de Lara (1):
>   ethdev: copy device configuration earlier
> 
> Wenzhuo Lu (2):
>   ixgbe: fix incorrect tx queue number assignment
>   ixgbe: fix incorrect max tx queue number
> 
All three patches are fixes, so all three should have "Fixes" lines in them.
Please remember for next time!

Thanks,
/Bruce

[dpdk-dev] [PATCH v2] ixgbe: disable icc compile warning

[Ferruh Yigit]

icc (icc (ICC) 16.0.1 20151021) is generating following compile error:
"
  CC ixgbe_rxtx.o
  .../drivers/net/ixgbe/ixgbe_rxtx.c(153): error #3656: variable
  "free" may be used before its value is set
  (nb_free > 0 && m->pool != free[0]->pool)) {
 ^
"

Indeed this is a false positive and code is correct.
"nb_free" check prevents the free[] access before its value set.

Disabling this icc warning (#3656) for file ixgbe_rxtx.c.

Signed-off-by: Ferruh Yigit 
---
 drivers/net/ixgbe/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index c032775..50bf51c 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -49,6 +49,8 @@ ifeq ($(CC), icc)
 #
 CFLAGS_BASE_DRIVER = -wd174 -wd593 -wd869 -wd981 -wd2259

+CFLAGS_ixgbe_rxtx.o += -wd3656
+
 else ifeq ($(CC), clang)
 #
 # CFLAGS for clang
-- 
2.5.0

[dpdk-dev] [PATCH v2] l2fwd-crypto: fix incorrect command line help

[Trahe, Fiona]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, March 24, 2016 1:40 PM
> To: dev at dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo
> Subject: [dpdk-dev] [PATCH v2] l2fwd-crypto: fix incorrect command line help
> 
> Previous cdev parameter was changed to cdev_type, to select a crypto device
> type preference (HW/SW/ANY), instead of the device itself (QAT/AESNI...).
> Also deleted cdev duplicated parameter from the help.
> 
> Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
> 
> Signed-off-by: Pablo de Lara 
> Acked-by: Fiona Trahe 
> ---
> 
> Changes in v2:
> - Removed duplicated parameter in command line help
> 
>  examples/l2fwd-crypto/main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Acked-by: Fiona Trahe 

[dpdk-dev] [PATCH v4 3/3] ixgbe: fix incorrect max tx queue number

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, March 24, 2016 3:22 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo ; Richardson, Bruce
> ; De Lara Guarch, Pablo
> 
> Subject: [dpdk-dev] [PATCH v4 3/3] ixgbe: fix incorrect max tx queue
> number
> 
> From: Wenzhuo Lu 
> 
> IXGBE supports 128 TX queues. However, the full 128 queues are only
> available in VT and DCB mode.
> In normal default "none" mode (VT/DCB off) the maximum number of available
> queues is only 64.
> IXGBE doesn't check the mode when reporting the available number of
> queues. If a queue larger than 64 is used in default mode, the TX packets
> will be dropped silently.
> 
> This change adds a check to forbid using a queue number larger than 64
> during device configuration (in default mode), so that the problem is
> reported as early as possible.
> 
> Signed-off-by: Wenzhuo Lu 
> Signed-off-by: Pablo de Lara 

Acked-by: John McNamara 

[dpdk-dev] [PATCH v4 2/3] ethdev: copy device configuration earlier

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, March 24, 2016 3:22 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo ; Richardson, Bruce
> ; De Lara Guarch, Pablo
> 
> Subject: [dpdk-dev] [PATCH v4 2/3] ethdev: copy device configuration
> earlier
> 
> In rte_eth_dev_configure(), device configuration was copied after
> requesting the device information, to check the maximum number of RX/TX
> queues. Since this number may change depending on the device
> configuration, the memcpy of it has to be performed before requesting the
> device information.
> 
> Signed-off-by: Pablo de Lara 


Acked-by: John McNamara 

[dpdk-dev] [PATCH v4 1/3] ixgbe: fix incorrect tx queue number assignment

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Thursday, March 24, 2016 3:22 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo ; Richardson, Bruce
> 
> Subject: [dpdk-dev] [PATCH v4 1/3] ixgbe: fix incorrect tx queue number
> assignment
> 
> From: Wenzhuo Lu 

Acked-by: John McNamara 

[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

[Lazaros Koromilas]

On Mon, Mar 21, 2016 at 3:49 PM, Wiles, Keith  wrote:
>>Hi Lazaros,
>>
>>Thanks for this patch. To me, this is a valuable enhancement.
>>Please find some comments inline.
>>
>>On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
>>> The mempool cache is only available to EAL threads as a per-lcore
>>> resource. Change this so that the user can create and provide their own
>>> cache on mempool get and put operations. This works with non-EAL threads
>>> too. This commit introduces new API calls with the 'with_cache' suffix,
>>> while the current ones default to the per-lcore local cache.
>>>
>>> Signed-off-by: Lazaros Koromilas 
>>> ---
>>>  lib/librte_mempool/rte_mempool.c |  65 +-
>>>  lib/librte_mempool/rte_mempool.h | 442 
>>> ---
>>>  2 files changed, 467 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/lib/librte_mempool/rte_mempool.c 
>>> b/lib/librte_mempool/rte_mempool.c
>>> index f8781e1..cebc2b7 100644
>>> --- a/lib/librte_mempool/rte_mempool.c
>>> +++ b/lib/librte_mempool/rte_mempool.c
>>> @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
>>> size_t elt_sz,
>>>  return usz;
>>>  }
>>>
>>> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>
>>I wonder if this wouldn't cause a conflict with Keith's patch
>>that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
>>See: http://www.dpdk.org/dev/patchwork/patch/10492/
>
> Hi Lazaros,
>
> The patch I submitted keeps the mempool cache structure (pointers and 
> variables) and only allocates the cache if specified by the caller to use a 
> cache. This means to me the caller could fill in the cache pointer and values 
> into the mempool structure to get a cache without a lot of extra code. If we 
> added a set of APIs to fill in these structure variables would that not give 
> you the external cache support. I have not really looked at the patch to 
> verify this will work, but it sure seems like it.
>
> So my suggestion the caller can just create a mempool without a cache and 
> then call a set of APIs to fill in his cache values, does that not work?
>
> If we can do this it reduces the API and possible the ABI changes to mempool 
> as the new cache create routines and APIs could be in a new file I think, 
> which just updates the mempool structure correctly.

Hi Keith,

The main benefit of having an external cache is to allow mempool users
(threads) to maintain a local cache even though they don't have a
valid lcore_id (non-EAL threads). The fact that cache access is done
by indexing with the lcore_id is what makes it difficult...

What could happen is only have external caches somehow, but that hurts
the common case where you want an automatic cache.
Or a cache registration mechanism (overkill?).

So, I'm going to work on the comments and send out a v2 asap. Thanks everyone!

Lazaros.

>
>>
>>As this patch is already acked for 16.07, I think that your v2
>>could be rebased on top of it to avoid conflicts when Thomas will apply
>>it.
>>
>>By the way, I also encourage you to have a look at other works in
>>progress in mempool:
>>http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
>>http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
>>
>>
>
> Regards,
> Keith
>
>
>
>

[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

[Lazaros Koromilas]

Hi Konstantin,

On Mon, Mar 21, 2016 at 3:15 PM, Ananyev, Konstantin
 wrote:
>
> Hi lads,
>
>>
>> Hi Lazaros,
>>
>> Thanks for this patch. To me, this is a valuable enhancement.
>> Please find some comments inline.
>
> Yep, patch seems interesting.
> One question - what would be the usage model for get/put_with_cache functions 
> for non-EAL threads?
> I meant for each non-EAL thread user will need to maintain an array (or list 
> or some other structure)
> of pair  to make sure that the cache always 
> matches the mempool,
> correct?

Yes, the user would have to also keep track of the caches. On the use
case, the original idea was to enable caches for threads that run on
the same core. There are cases that this can work, as described in the
programming guide, section on multiple pthreads. Even with two EAL
threads, we currently cannot have multiple caches on a single core,
unless we use the --lcores long option to separate lcore id (which
really is a thread id here) from the actual core affinity.

So the cache should be a member of the thread and not the mempool, in
my opinion. It has to be consistently used with the same mempool
though.

> Again, for non-EAL threads don't we need some sort of invalidate_cache()
> that would put all mbufs in the cache back to the pool?
> For thread termination case or so?

I think also EAL threads benefit from an invalidate() function call.
This can be part of free() that Olivier proposed.

Thanks!
Lazaros.

>
>>
>> On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
>> > The mempool cache is only available to EAL threads as a per-lcore
>> > resource. Change this so that the user can create and provide their own
>> > cache on mempool get and put operations. This works with non-EAL threads
>> > too. This commit introduces new API calls with the 'with_cache' suffix,
>> > while the current ones default to the per-lcore local cache.
>> >
>> > Signed-off-by: Lazaros Koromilas 
>> > ---
>> >  lib/librte_mempool/rte_mempool.c |  65 +-
>> >  lib/librte_mempool/rte_mempool.h | 442 
>> > ---
>> >  2 files changed, 467 insertions(+), 40 deletions(-)
>> >
>> > diff --git a/lib/librte_mempool/rte_mempool.c 
>> > b/lib/librte_mempool/rte_mempool.c
>> > index f8781e1..cebc2b7 100644
>> > --- a/lib/librte_mempool/rte_mempool.c
>> > +++ b/lib/librte_mempool/rte_mempool.c
>> > @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
>> > size_t elt_sz,
>> > return usz;
>> >  }
>> >
>> > +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>
>> I wonder if this wouldn't cause a conflict with Keith's patch
>> that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
>> See: http://www.dpdk.org/dev/patchwork/patch/10492/
>>
>> As this patch is already acked for 16.07, I think that your v2
>> could be rebased on top of it to avoid conflicts when Thomas will apply
>> it.
>>
>> By the way, I also encourage you to have a look at other works in
>> progress in mempool:
>> http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
>> http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
>>
>>
>> > +static void
>> > +mempool_cache_init(struct rte_mempool_cache *cache, uint32_t size)
>> > +{
>> > +   cache->size = size;
>> > +   cache->flushthresh = CALC_CACHE_FLUSHTHRESH(size);
>> > +   cache->len = 0;
>> > +}
>> > +
>> > +/*
>> > + * Creates and initializes a cache for objects that are retrieved from and
>> > + * returned to an underlying mempool. This structure is identical to the
>> > + * structure included inside struct rte_mempool.
>> > + */
>>
>> On top of Keith's patch, this comment may be reworked as the cache
>> structure is not included in the mempool structure anymore.
>>
>> nit: I think the imperative form is preferred
>>
>>
>> > +struct rte_mempool_cache *
>> > +rte_mempool_cache_create(uint32_t size)
>
> I suppose extra socket_id parameter is needed, so you can call
> zmalloc_socket() beneath.
>
>> > +{
>> > +   struct rte_mempool_cache *cache;
>> > +
>> > +   if (size > RTE_MEMPOOL_CACHE_MAX_SIZE) {
>> > +   rte_errno = EINVAL;
>> > +   return NULL;
>> > +   }
>> > +
>> > +   cache = rte_zmalloc("MEMPOOL_CACHE", sizeof(*cache), 
>> > RTE_CACHE_LINE_SIZE);
>> > +   if (cache == NULL) {
>> > +   RTE_LOG(ERR, MEMPOOL, "Cannot allocate mempool cache!\n");
>>
>> I would remove the '!'
>>
>>
>>
>> > @@ -587,10 +624,18 @@ rte_mempool_xmem_create(const char *name, unsigned 
>> > n, unsigned elt_size,
>> > mp->elt_size = objsz.elt_size;
>> > mp->header_size = objsz.header_size;
>> > mp->trailer_size = objsz.trailer_size;
>> > -   mp->cache_size = cache_size;
>> > -   mp->cache_flushthresh = CALC_CACHE_FLUSHTHRESH(cache_size);
>> > +   mp->cache_size = cache_size; /* Keep this for backwards compat. */
>>
>> I'm wondering if this should be kept for compat or if it makes sense
>> to keep it. The question is: do we want the cache_size to be a parameter
>> of the mempool or should it be 

[dpdk-dev] [PATCH v4 3/3] ixgbe: fix incorrect max tx queue number

[Pablo de Lara]

From: Wenzhuo Lu 

IXGBE supports 128 TX queues. However, the full 128 queues
are only available in VT and DCB mode.
In normal default "none" mode (VT/DCB off) the maximum number
of available queues is only 64.
IXGBE doesn't check the mode when reporting the available
number of queues. If a queue larger than 64 is used in default mode,
the TX packets will be dropped silently.

This change adds a check to forbid using a queue number larger than 64
during device configuration (in default mode), so that the problem is
reported as early as possible.

Signed-off-by: Wenzhuo Lu 
Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_16_04.rst |  6 ++
 drivers/net/ixgbe/ixgbe_ethdev.c   | 26 ++
 drivers/net/ixgbe/ixgbe_ethdev.h   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 9922bcb..d0d5c89 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -302,6 +302,12 @@ Drivers
   The driver now set the MDIO clock speed prior to initializing PHY ops and
   again after the MAC reset.

+* **ixgbe: Fixed maximum number of available TX queues.**
+
+  In IXGBE, the maximum number of TX queues varies depending on the NIC 
operating
+  mode. This was not being updated in the device information, providing
+  an incorrect number in some cases.
+
 * **i40e: Generated MAC address for each VFs.**

   It generates a MAC address for each VFs during PF host initialization,
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 0d867fc..bfd8cb3 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1861,6 +1861,7 @@ static int
 ixgbe_check_mq_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_conf *dev_conf = >data->dev_conf;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint16_t nb_rx_q = dev->data->nb_rx_queues;
uint16_t nb_tx_q = dev->data->nb_tx_queues;

@@ -2002,6 +2003,21 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
}
+
+   /*
+* When DCB/VT is off, maximum number of queues changes,
+* except for 82598EB, which remains constant.
+*/
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE &&
+   hw->mac.type != ixgbe_mac_82598EB) {
+   if (nb_tx_q > IXGBE_NONE_MODE_TX_NB_QUEUES) {
+   PMD_INIT_LOG(ERR,
+"Neither VT nor DCB are enabled, "
+"nb_tx_q > %d.",
+IXGBE_NONE_MODE_TX_NB_QUEUES);
+   return -EINVAL;
+   }
+   }
}
return 0;
 }
@@ -2856,9 +2872,19 @@ static void
 ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct rte_eth_conf *dev_conf = >data->dev_conf;

dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
+   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+   /*
+* When DCB/VT is off, maximum number of queues changes,
+* except for 82598EB, which remains constant.
+*/
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE &&
+   hw->mac.type != ixgbe_mac_82598EB)
+   dev_info->max_tx_queues = IXGBE_NONE_MODE_TX_NB_QUEUES;
+   }
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 5c3aa16..691c62f 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -61,6 +61,7 @@
 #define IXGBE_MAX_RX_QUEUE_NUM 128
 #define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
 #define IXGBE_DCB_NB_QUEUES  IXGBE_MAX_RX_QUEUE_NUM
+#define IXGBE_NONE_MODE_TX_NB_QUEUES 64

 #ifndef NBBY
 #define NBBY   8   /* number of bits in a byte */
-- 
2.5.5

[dpdk-dev] [PATCH v4 2/3] ethdev: copy device configuration earlier

[Pablo de Lara]

In rte_eth_dev_configure(), device configuration was copied
after requesting the device information, to check the
maximum number of RX/TX queues. Since this number may change
depending on the device configuration, the memcpy of it
has to be performed before requesting the device information.

Signed-off-by: Pablo de Lara 
---
 lib/librte_ether/rte_ethdev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8721a6b..b941b0d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -901,6 +901,9 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
return -EBUSY;
}

+   /* Copy the dev_conf parameter into the dev structure */
+   memcpy(>data->dev_conf, dev_conf, sizeof(dev->data->dev_conf));
+
/*
 * Check that the numbers of RX and TX queues are not greater
 * than the maximum number of RX and TX queues supported by the
@@ -925,9 +928,6 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
return -EINVAL;
}

-   /* Copy the dev_conf parameter into the dev structure */
-   memcpy(>data->dev_conf, dev_conf, sizeof(dev->data->dev_conf));
-
/*
 * If link state interrupt is enabled, check that the
 * device supports it.
-- 
2.5.5

[dpdk-dev] [PATCH v4 1/3] ixgbe: fix incorrect tx queue number assignment

[Pablo de Lara]

From: Wenzhuo Lu 

Internal variable containing the number of TX queues for a device,
was being incorrectly assigned the number of RX queues, instead of TX.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index d4d883a..0d867fc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1862,7 +1862,7 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_conf *dev_conf = >data->dev_conf;
uint16_t nb_rx_q = dev->data->nb_rx_queues;
-   uint16_t nb_tx_q = dev->data->nb_rx_queues;
+   uint16_t nb_tx_q = dev->data->nb_tx_queues;

if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
/* check multi-queue mode */
-- 
2.5.5

[dpdk-dev] [PATCH v4 0/3] Fix incorrect max TX queue numbers for ixgbe

[Pablo de Lara]

IXGBE supports 128 TX queues. However, the full 128 queues
are only available in VT and DCB mode.
In normal default "none" mode (VT/DCB off) the maximum number
of available queues is only 64.
IXGBE doesn't check the mode when reporting the available
number of queues. If a queue larger than 64 is used in default mode,
the TX packets will be dropped silently.

This patchset:

- Modifies the device info to show the correct maximum number of available TX 
queues,
  depending on the mode.

- Adds a check to forbid using a queue number larger than 64
  during device configuration (in default mode), so that the problem is
  reported as early as possible.

- It also changes the order of where the dev_conf parameters are copied
  into the dev structure so that the correct maximum number of queues
  is reported for the correct mode.

Changes in v4:
- Split the patch in three smaller patches
- Updated release notes document

Changes in v3:
- Fixed wrong set of TX queues for 82596EB

Changes in v2:

- Reorder memcpy of device configuration in rte_eth_dev_configure(),
  so function gets the correct maximum number of queues
  (depending on the operation mode), before checking the
  requested number of queues.
- Renamed new macro
- Reworded/wrapped commit message

Pablo de Lara (1):
  ethdev: copy device configuration earlier

Wenzhuo Lu (2):
  ixgbe: fix incorrect tx queue number assignment
  ixgbe: fix incorrect max tx queue number

 doc/guides/rel_notes/release_16_04.rst |  6 ++
 drivers/net/ixgbe/ixgbe_ethdev.c   | 22 +-
 drivers/net/ixgbe/ixgbe_ethdev.h   |  1 +
 lib/librte_ether/rte_ethdev.c  |  6 +++---
 4 files changed, 31 insertions(+), 4 deletions(-)

-- 
2.5.5

[dpdk-dev] [PATCH v3] ixgbe: add check for tx queue number

[Pablo de Lara]

From: Wenzhuo Lu 

IXGBE supports 128 TX queues. However, the full 128 queues
are only available in VT and DCB mode.
In normal default "none" mode (VT/DCB off) the maximum number
of available queues is only 64
(except for 82598EB, which is 32 for all modes).

IXGBE doesn't check the mode when reporting the available
number of queues. If a queue larger than 64 is used in default mode,
the TX packets will be dropped silently.

This change adds a check to forbid using a queue number larger than 64
during device configuration (in default mode), so that the problem is
reported as early as possible.
It also changes the order of where the dev_conf parameters are copied
into the dev structure so that the correct maximum number of queues
is reported for the correct mode.

Signed-off-by: Wenzhuo Lu 
Signed-off-by: Pablo de Lara 
---

Respin for automated testing.
Will send a v4 splitting the patch.

Changes in v3:
- Fixed wrong set of TX queues for 82596EB

Changes in v2:

- Reorder memcpy of device configuration in rte_eth_dev_configure(),
  so function gets the correct maximum number of queues
  (depending on the operation mode), before checking the
  requested number of queues.
- Renamed new macro
- Reworded/wrapped commit message

 drivers/net/ixgbe/ixgbe_ethdev.c | 28 +++-
 drivers/net/ixgbe/ixgbe_ethdev.h |  1 +
 lib/librte_ether/rte_ethdev.c|  6 +++---
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index d4d883a..bfd8cb3 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1861,8 +1861,9 @@ static int
 ixgbe_check_mq_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_conf *dev_conf = >data->dev_conf;
+   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint16_t nb_rx_q = dev->data->nb_rx_queues;
-   uint16_t nb_tx_q = dev->data->nb_rx_queues;
+   uint16_t nb_tx_q = dev->data->nb_tx_queues;

if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
/* check multi-queue mode */
@@ -2002,6 +2003,21 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
}
+
+   /*
+* When DCB/VT is off, maximum number of queues changes,
+* except for 82598EB, which remains constant.
+*/
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE &&
+   hw->mac.type != ixgbe_mac_82598EB) {
+   if (nb_tx_q > IXGBE_NONE_MODE_TX_NB_QUEUES) {
+   PMD_INIT_LOG(ERR,
+"Neither VT nor DCB are enabled, "
+"nb_tx_q > %d.",
+IXGBE_NONE_MODE_TX_NB_QUEUES);
+   return -EINVAL;
+   }
+   }
}
return 0;
 }
@@ -2856,9 +2872,19 @@ static void
 ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 {
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+   struct rte_eth_conf *dev_conf = >data->dev_conf;

dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
+   if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+   /*
+* When DCB/VT is off, maximum number of queues changes,
+* except for 82598EB, which remains constant.
+*/
+   if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE &&
+   hw->mac.type != ixgbe_mac_82598EB)
+   dev_info->max_tx_queues = IXGBE_NONE_MODE_TX_NB_QUEUES;
+   }
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register */
dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register */
dev_info->max_mac_addrs = hw->mac.num_rar_entries;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 5c3aa16..691c62f 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -61,6 +61,7 @@
 #define IXGBE_MAX_RX_QUEUE_NUM 128
 #define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
 #define IXGBE_DCB_NB_QUEUES  IXGBE_MAX_RX_QUEUE_NUM
+#define IXGBE_NONE_MODE_TX_NB_QUEUES 64

 #ifndef NBBY
 #define NBBY   8   /* number of bits in a byte */
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8721a6b..b941b0d 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -901,6 +901,9 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, 
uint16_t nb_tx_q,
return -EBUSY;
}

+   /* Copy the dev_conf parameter into the dev structure */
+   

[dpdk-dev] [PATCH v2 2/2] igb: fix the wrong address of device data pointer

[Wenzhuo Lu]

In the function set_rx_mode, the pointer of device data points
to the wrong address as found in ixgbe code.

Fixes: be2d648a2dd3("igb: add PF support")
Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/igb_pf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/e1000/igb_pf.c b/drivers/net/e1000/igb_pf.c
index 95204e9..7f45a44 100644
--- a/drivers/net/e1000/igb_pf.c
+++ b/drivers/net/e1000/igb_pf.c
@@ -218,8 +218,7 @@ int igb_pf_host_configure(struct rte_eth_dev *eth_dev)
 static void
 set_rx_mode(struct rte_eth_dev *dev)
 {
-   struct rte_eth_dev_data *dev_data =
-   (struct rte_eth_dev_data*)dev->data->dev_private;
+   struct rte_eth_dev_data *dev_data = dev->data;
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t fctrl, vmolr = E1000_VMOLR_BAM | E1000_VMOLR_AUPE;
uint16_t vfn = dev_num_vf(dev);
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/2] ixgbe: fix the wrong address of device data pointer

[Wenzhuo Lu]

There's an issue reported. In the scenario DPDK PF + DPDK VF,
if the VF port is closed, PF port cannot receive packets.
I found at that time the promicuous mode is disabled on the PF
port. But it should be enabled.
When VF port is closed, it will send a message to its PF port to
reset it. During this, PF port will also reset its own
promicuous mode. Which promiscuous mode should be set depends on
the parameter stored in the device data. In the function
set_rx_mode, the pointer of device data points to the wrong
address. So, the promiscuous mode is wrong.

Fixes: 00e30184daa0("ixgbe: add PF support")
Signed-off-by: Wenzhuo Lu 
Reported-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_pf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index b854c72..a540343 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -312,8 +312,7 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
 static void
 set_rx_mode(struct rte_eth_dev *dev)
 {
-   struct rte_eth_dev_data *dev_data =
-   (struct rte_eth_dev_data*)dev->data->dev_private;
+   struct rte_eth_dev_data *dev_data = dev->data;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
u32 fctrl, vmolr = IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE;
uint16_t vfn = dev_num_vf(dev);
-- 
1.9.3

[dpdk-dev] [PATCH v2 0/2] fix the wrong address of device data pointer

[Wenzhuo Lu]

In the function set_rx_mode, the pointer of device data points
to the wrong address.

v2:
- Remove the unnecessary cast.

Wenzhuo Lu (2):
  ixgbe: fix the wrong address of device data pointer
  igb: fix the wrong address of device data pointer

 drivers/net/e1000/igb_pf.c   | 3 +--
 drivers/net/ixgbe/ixgbe_pf.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

[Wiles, Keith]

>On Mon, Mar 21, 2016 at 3:49 PM, Wiles, Keith  wrote:
>>>Hi Lazaros,
>>>
>>>Thanks for this patch. To me, this is a valuable enhancement.
>>>Please find some comments inline.
>>>
>>>On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
 The mempool cache is only available to EAL threads as a per-lcore
 resource. Change this so that the user can create and provide their own
 cache on mempool get and put operations. This works with non-EAL threads
 too. This commit introduces new API calls with the 'with_cache' suffix,
 while the current ones default to the per-lcore local cache.

 Signed-off-by: Lazaros Koromilas 
 ---
  lib/librte_mempool/rte_mempool.c |  65 +-
  lib/librte_mempool/rte_mempool.h | 442 
 ---
  2 files changed, 467 insertions(+), 40 deletions(-)

 diff --git a/lib/librte_mempool/rte_mempool.c 
 b/lib/librte_mempool/rte_mempool.c
 index f8781e1..cebc2b7 100644
 --- a/lib/librte_mempool/rte_mempool.c
 +++ b/lib/librte_mempool/rte_mempool.c
 @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, 
 size_t elt_sz,
  return usz;
  }

 +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
>>>
>>>I wonder if this wouldn't cause a conflict with Keith's patch
>>>that removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
>>>See: http://www.dpdk.org/dev/patchwork/patch/10492/
>>
>> Hi Lazaros,
>>
>> The patch I submitted keeps the mempool cache structure (pointers and 
>> variables) and only allocates the cache if specified by the caller to use a 
>> cache. This means to me the caller could fill in the cache pointer and 
>> values into the mempool structure to get a cache without a lot of extra 
>> code. If we added a set of APIs to fill in these structure variables would 
>> that not give you the external cache support. I have not really looked at 
>> the patch to verify this will work, but it sure seems like it.
>>
>> So my suggestion the caller can just create a mempool without a cache and 
>> then call a set of APIs to fill in his cache values, does that not work?
>>
>> If we can do this it reduces the API and possible the ABI changes to mempool 
>> as the new cache create routines and APIs could be in a new file I think, 
>> which just updates the mempool structure correctly.
>
>Hi Keith,
>
>The main benefit of having an external cache is to allow mempool users
>(threads) to maintain a local cache even though they don't have a
>valid lcore_id (non-EAL threads). The fact that cache access is done
>by indexing with the lcore_id is what makes it difficult...
>
>What could happen is only have external caches somehow, but that hurts
>the common case where you want an automatic cache.
>Or a cache registration mechanism (overkill?).
>
>So, I'm going to work on the comments and send out a v2 asap. Thanks everyone!

Hi Lazaros,

I look forward seeing the next version as I have some concerns, but I do not 
think I am seeing the big picture or reason for the change.

Part of my goal with the patch I sent was to remove ifdefs in the code as much 
as possible, so please try to reduce the ifdefs too.

>
>Lazaros.
>
>>
>>>
>>>As this patch is already acked for 16.07, I think that your v2
>>>could be rebased on top of it to avoid conflicts when Thomas will apply
>>>it.
>>>
>>>By the way, I also encourage you to have a look at other works in
>>>progress in mempool:
>>>http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
>>>http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
>>>
>>>
>>
>> Regards,
>> Keith
>>
>>
>>
>>
>


Regards,
Keith

[dpdk-dev] [PATCH v2] i40e: fix ipv6 TSO issue for tx function

[Bruce Richardson]

On Wed, Mar 23, 2016 at 11:27:50AM +0800, Zhe Tao wrote:
> Issue:
> when using the following CLI in testpmd to enable ipv6 TSO feature
> =
> set verbose 1
> csum set ip hw 0
> csum set udp hw 0
> csum set tcp hw 0
> csum set sctp hw 0
> csum set outer-ip hw 0
> csum parse_tunnel on 0
> tso set 800 0
> set fwd csum
> 
> start
> =

The "===" lines in the message are confusing patchwork. For a new version of
this patch can you indent the commands rather than putting the "===" above and 
below. E.g.

 Issue:
 when using the following CLI in testpmd to enable ipv6 TSO feature

set verbose 1
csum set ip hw 0
csum set udp hw 0


Thanks,
/Bruce

[dpdk-dev] [PATCH] bond: use existing enslaved device queues

[Eric Kinzie]

This solves issues when an active device is added to a bond.

If a device to be enslaved already has transmit and/or receive queues
allocated, use those and then create any additional queues that are
necessary.

Fixes: 2efb58cbab6e ("bond: new link bonding library")

Signed-off-by: Eric Kinzie 
---
 drivers/net/bonding/rte_eth_bond_pmd.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c 
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 011150a..7472e9d 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1305,6 +1305,8 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
struct bond_rx_queue *bd_rx_q;
struct bond_tx_queue *bd_tx_q;

+   uint16_t old_nb_tx_queues = slave_eth_dev->data->nb_tx_queues;
+   uint16_t old_nb_rx_queues = slave_eth_dev->data->nb_rx_queues;
int errval;
uint16_t q_id;

@@ -1345,7 +1347,9 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
}

/* Setup Rx Queues */
-   for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
+   /* Use existing queues, if any */
+   for (q_id = old_nb_rx_queues;
+q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
bd_rx_q = (struct bond_rx_queue 
*)bonded_eth_dev->data->rx_queues[q_id];

errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id, 
q_id,
@@ -1361,7 +1365,9 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
}

/* Setup Tx Queues */
-   for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
+   /* Use existing queues, if any */
+   for (q_id = old_nb_tx_queues;
+q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
bd_tx_q = (struct bond_tx_queue 
*)bonded_eth_dev->data->tx_queues[q_id];

errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id, 
q_id,
-- 
1.7.10.4

[dpdk-dev] [PATCH] mempool: allow for user-owned mempool caches

[Venkatesan, Venky]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lazaros Koromilas
> Sent: Thursday, March 24, 2016 7:36 AM
> To: Wiles, Keith 
> Cc: Olivier Matz ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mempool: allow for user-owned mempool
> caches
> 
> On Mon, Mar 21, 2016 at 3:49 PM, Wiles, Keith 
> wrote:
> >>Hi Lazaros,
> >>
> >>Thanks for this patch. To me, this is a valuable enhancement.
> >>Please find some comments inline.
> >>
> >>On 03/10/2016 03:44 PM, Lazaros Koromilas wrote:
> >>> The mempool cache is only available to EAL threads as a per-lcore
> >>> resource. Change this so that the user can create and provide their
> >>> own cache on mempool get and put operations. This works with non-EAL
> >>> threads too. This commit introduces new API calls with the
> >>> 'with_cache' suffix, while the current ones default to the per-lcore local
> cache.
> >>>
> >>> Signed-off-by: Lazaros Koromilas 
> >>> ---
> >>>  lib/librte_mempool/rte_mempool.c |  65 +-
> >>> lib/librte_mempool/rte_mempool.h | 442
> >>> ---
> >>>  2 files changed, 467 insertions(+), 40 deletions(-)
> >>>
> >>> diff --git a/lib/librte_mempool/rte_mempool.c
> >>> b/lib/librte_mempool/rte_mempool.c
> >>> index f8781e1..cebc2b7 100644
> >>> --- a/lib/librte_mempool/rte_mempool.c
> >>> +++ b/lib/librte_mempool/rte_mempool.c
> >>> @@ -375,6 +375,43 @@ rte_mempool_xmem_usage(void *vaddr,
> uint32_t elt_num, size_t elt_sz,
> >>>  return usz;
> >>>  }
> >>>
> >>> +#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
> >>
> >>I wonder if this wouldn't cause a conflict with Keith's patch that
> >>removes some #ifdefs RTE_MEMPOOL_CACHE_MAX_SIZE.
> >>See: http://www.dpdk.org/dev/patchwork/patch/10492/
> >
> > Hi Lazaros,
> >
> > The patch I submitted keeps the mempool cache structure (pointers and
> variables) and only allocates the cache if specified by the caller to use a
> cache. This means to me the caller could fill in the cache pointer and values
> into the mempool structure to get a cache without a lot of extra code. If we
> added a set of APIs to fill in these structure variables would that not give 
> you
> the external cache support. I have not really looked at the patch to verify 
> this
> will work, but it sure seems like it.
> >
> > So my suggestion the caller can just create a mempool without a cache and
> then call a set of APIs to fill in his cache values, does that not work?
> >
> > If we can do this it reduces the API and possible the ABI changes to
> mempool as the new cache create routines and APIs could be in a new file I
> think, which just updates the mempool structure correctly.
> 
> Hi Keith,
> 
> The main benefit of having an external cache is to allow mempool users
> (threads) to maintain a local cache even though they don't have a valid
> lcore_id (non-EAL threads). The fact that cache access is done by indexing
> with the lcore_id is what makes it difficult...

Hi Lazaros, 

Alternative suggestion: This could actually be very simply done via creating an 
EAL API to register and return an lcore_id for a thread wanting to use DPDK 
services. That way, you could simply create your pthread, call the 
eal_register_thread() function that assigns an lcore_id to the caller (and 
internally sets up the per_lcore variable. 

The advantage of doing it this way is that you could extend it to other things 
other than the mempool that may need an lcore_id setup.

Regards,
-Venky

> 
> What could happen is only have external caches somehow, but that hurts the
> common case where you want an automatic cache.
> Or a cache registration mechanism (overkill?).
> 
> So, I'm going to work on the comments and send out a v2 asap. Thanks
> everyone!
> 
> Lazaros.
> 
> >
> >>
> >>As this patch is already acked for 16.07, I think that your v2 could
> >>be rebased on top of it to avoid conflicts when Thomas will apply it.
> >>
> >>By the way, I also encourage you to have a look at other works in
> >>progress in mempool:
> >>http://www.dpdk.org/ml/archives/dev/2016-March/035107.html
> >>http://www.dpdk.org/ml/archives/dev/2016-March/035201.html
> >>
> >>
> >
> > Regards,
> > Keith
> >
> >
> >
> >

[dpdk-dev] [PATCH v2] i40e: fix ipv6 TSO issue for tx function

[Bruce Richardson]

On Wed, Mar 23, 2016 at 11:27:50AM +0800, Zhe Tao wrote:
> Issue:
> when using the following CLI in testpmd to enable ipv6 TSO feature
> =
> set verbose 1
> csum set ip hw 0
> csum set udp hw 0
> csum set tcp hw 0
> csum set sctp hw 0
> csum set outer-ip hw 0
> csum parse_tunnel on 0
> tso set 800 0
> set fwd csum
> 
> start
> =
> 
> We will not get we want, the ipv6 packets sent out from IXIA can be received 
> by
> i40e, but cannot forward to another port.
> The root cause is when HW doing the TSO offload for packets, it not only 
> depends
> on the context descriptor to define the MSS and TSO payload size, it also
> need to know whether this packets is ipv4 or ipv6, ipv4 need the header csum,
> but ipv6 doesn't need the csum. We need to use the i40e_txd_enable_checksum to
> set the ipv6 type flag into the data descriptor when the packets are for
> ipv6 TSO.  
>  
> Fixes: e3f0151f (i40e: enable Tx checksum only for offloaded packets)
> 
> Signed-off-by: Zhe Tao 
> ---
> v2: change condition check for ipv6 TSO checksum offload
> use a more clear check method which include both ipv4 & ipv6 TSO
> 
> 
>  drivers/net/i40e/i40e_rxtx.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 1488f2f..3422ec2 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -73,9 +73,16 @@
>  
>  #define I40E_TXD_CMD (I40E_TX_DESC_CMD_EOP | I40E_TX_DESC_CMD_RS)
>  
> +/* need to add the TSO flag to the checksum offload mask
> + * even the packets like ipv6 doesn't need the checksum for ip header
> + * but the FW need to know whether this TCP packets is ipv4 or ipv6,
> + * so add this kind of information in the checksum offload field in the
> + * normal data descriptor.
> + */
>  #define I40E_TX_CKSUM_OFFLOAD_MASK (  \
>   PKT_TX_IP_CKSUM |\
>   PKT_TX_L4_MASK | \
> + PKT_TX_TCP_SEG | \
>   PKT_TX_OUTER_IP_CKSUM)
>  
>  static uint16_t i40e_xmit_pkts_simple(void *tx_queue,
> -- 

To be honest, I'm a little confused by the patch description and the comment
added into the code. The commit message talks about flagging to the HW whether
a packet is IPv4 or IPv6. However, the change made is to add a TCP segmentation
bit to an offload mask - something that seems irrelevant to telling if something
is IPv4 or v6.

As for the comment itself. The comment reads like a commit message for a patch,
rather than as the comment on a macro. The comment talks exclusively about the
TSO part of the mask, and ignores the other values in it. It also suffers the
same problem as the commit message of not explaining how a TSO flag ties in
with identifying IPv4 or v6.

Could you please reword the commit message and rework the comment to be a proper
comment on the whole macro and resubmit the patch. 

Thanks,
/Bruce

[dpdk-dev] [PATCH 2/2] igb: fix the wrong address of device data pointer

[Wenzhuo Lu]

In the function set_rx_mode, the pointer of device data points
to the wrong address as found in ixgbe code.

Fixes: be2d648a2dd3("igb: add PF support")
Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/igb_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/e1000/igb_pf.c b/drivers/net/e1000/igb_pf.c
index 95204e9..9dafbc4 100644
--- a/drivers/net/e1000/igb_pf.c
+++ b/drivers/net/e1000/igb_pf.c
@@ -219,7 +219,7 @@ static void
 set_rx_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_dev_data *dev_data =
-   (struct rte_eth_dev_data*)dev->data->dev_private;
+   (struct rte_eth_dev_data *)dev->data;
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t fctrl, vmolr = E1000_VMOLR_BAM | E1000_VMOLR_AUPE;
uint16_t vfn = dev_num_vf(dev);
-- 
1.9.3

[dpdk-dev] [PATCH 1/2] ixgbe: fix the wrong address of device data pointer

[Wenzhuo Lu]

There's an issue reported. In the scenario DPDK PF + DPDK VF,
if the VF port is closed, PF port cannot receive packets.
I found at that time the promicuous mode is disabled on the PF
port. But it should be enabled.
When VF port is closed, it will send a message to its PF port to
reset it. During this, PF port will also reset its own
promicuous mode. Which promiscuous mode should be set depends on
the parameter stored in the device data. In the function
set_rx_mode, the pointer of device data points to the wrong
address. So, the promiscuous mode is wrong.

Fixes: 00e30184daa0("ixgbe: add PF support")
Signed-off-by: Wenzhuo Lu 
Reported-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_pf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index b854c72..0f8ad55 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -313,7 +313,7 @@ static void
 set_rx_mode(struct rte_eth_dev *dev)
 {
struct rte_eth_dev_data *dev_data =
-   (struct rte_eth_dev_data*)dev->data->dev_private;
+   (struct rte_eth_dev_data *)dev->data;
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
u32 fctrl, vmolr = IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE;
uint16_t vfn = dev_num_vf(dev);
-- 
1.9.3

[dpdk-dev] [PATCH 0/2] fix the wrong address of device data pointer

[Wenzhuo Lu]

In the function set_rx_mode, the pointer of device data points
to the wrong address.

Wenzhuo Lu (2):
  ixgbe: fix the wrong address of device data pointer
  igb: fix the wrong address of device data pointer

 drivers/net/e1000/igb_pf.c   | 2 +-
 drivers/net/ixgbe/ixgbe_pf.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH] hash: fix typo in Doxygen comment

[Pablo de Lara]

rte_hash_set_cmp_func() had an incorrect Doxygen comment
for one of its parameters.

Fixes: 95da2f8e9c61 ("hash: customize compare function")

Signed-off-by: Pablo de Lara 
---
 lib/librte_hash/rte_hash.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index 85fc416..add3414 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -114,7 +114,7 @@ rte_hash_create(const struct rte_hash_parameters *params);
  * in multi-process mode.
  *
  * @param h
- *   Hash table to reset
+ *   Hash table to change the function
  * @param func
  *   New compare function
  */
-- 
2.5.5

[dpdk-dev] arch check in example dpdk_qat

[Thomas Monjalon]

2016-03-24 11:58, De Lara Guarch, Pablo:
> 
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Thursday, March 24, 2016 11:01 AM
> > To: De Lara Guarch, Pablo
> > Cc: Richardson, Bruce; dev at dpdk.org
> > Subject: Re: arch check in example dpdk_qat
> > 
> > 2016-03-24 10:50, De Lara Guarch, Pablo:
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > When reading examples/dpdk_qat/Makefile, we can see this check:
> > > >
> > > > ifneq ($(CONFIG_RTE_ARCH),"x86_64")
> > > > ifneq ($(LBITS),i686)
> > > > $(error The RTE_TARGET chosen is not compatible with this
> > environment
> > > > \
> > > > (x86_64), for this application. Please change the definition of 
> > > > the \
> > > > RTE_TARGET environment variable, or run the application on a 
> > > > 32-bit
> > > > OS)
> > > > endif
> > > > endif
> > > >
> > > > Is it on purpose to limit the 32-bit support to i686 only?
> > > > Instead of the message "run the application on a 32-bit OS", should it 
> > > > be
> > > > "on an i686 OS"?
> > >
> > > i686 OS looks fine to me. Basically, when this app was made, the only 
> > > 32-bit
> > target was i686,
> > 
> > What about i386, i486, i586 builds ?
> 
> We only support i686, no other 32-bit architectures.

So we need a small patch :)

[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment

[De Lara Guarch, Pablo]

Hi,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ??
> Sent: Tuesday, March 15, 2016 1:03 AM
> To: Dhananjaya Eadala
> Cc: Richardson, Bruce; De Lara Guarch, Pablo; Qiu, Michael; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-
> process environment
> 
> Thanks so much for your patch! Your patch exactly solves my bug. :)

I just sent an alternative patch to solve the issue, without requiring #ifdefs.
Could you take a look at it and check that works for you?

Thanks,
Pablo

[dpdk-dev] [PATCH] hash: fix to support multi process

[Pablo de Lara]

Hash library used a function pointer to choose a different
key compare function, depending on the key size.
As a result, multiple processes could not use the same hash table,
as the function addresses vary from one process to another.

Instead, a jump table is used, so each process has its own
function addresses, accessing this table with an index stored
in the hash table (note that using a custom key compare function
is not supported in multi-process mode).

Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation")

Signed-off-by: Pablo de Lara 
---
 doc/guides/rel_notes/release_16_04.rst |  5 ++
 lib/librte_hash/rte_cuckoo_hash.c  | 85 ++
 2 files changed, 71 insertions(+), 19 deletions(-)

diff --git a/doc/guides/rel_notes/release_16_04.rst 
b/doc/guides/rel_notes/release_16_04.rst
index 2785b29..c4359dd 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -351,6 +351,11 @@ Libraries
   Fix crc32c hash functions to return a valid crc32c value for data lengths
   not multiple of 4 bytes.

+* **hash: Fixed hash library to support multi-process mode.**
+
+  Fix hash library to support multi-process mode, using a jump table,
+  instead of storing a function pointer to the key compare function.
+
 * **librte_port: Fixed segmentation fault for ring and ethdev writer nodrop.**

   Fixed core dump issue on txq and swq when dropless is set to yes.
diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 71b5b76..38c19ab 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -102,6 +102,41 @@ EAL_REGISTER_TAILQ(rte_hash_tailq)

 #define LCORE_CACHE_SIZE   8

+/*
+ * All different options to select a key compare function,
+ * based on the key size and custom function.
+ */
+enum cmp_jump_table_case {
+   KEY_CUSTOM = 0,
+   KEY_16_BYTES,
+   KEY_32_BYTES,
+   KEY_48_BYTES,
+   KEY_64_BYTES,
+   KEY_80_BYTES,
+   KEY_96_BYTES,
+   KEY_112_BYTES,
+   KEY_128_BYTES,
+   KEY_OTHER_BYTES,
+   NUM_KEY_CMP_CASES,
+};
+
+/*
+ * Table storing all different key compare functions
+ * (multi-process supported)
+ */
+rte_hash_cmp_eq_t cmp_jump_table[NUM_KEY_CMP_CASES] = {
+   NULL,
+   rte_hash_k16_cmp_eq,
+   rte_hash_k32_cmp_eq,
+   rte_hash_k48_cmp_eq,
+   rte_hash_k64_cmp_eq,
+   rte_hash_k80_cmp_eq,
+   rte_hash_k96_cmp_eq,
+   rte_hash_k112_cmp_eq,
+   rte_hash_k128_cmp_eq,
+   memcmp
+};
+
 struct lcore_cache {
unsigned len; /**< Cache len */
void *objs[LCORE_CACHE_SIZE]; /**< Cache objects */
@@ -115,7 +150,10 @@ struct rte_hash {
uint32_t key_len;   /**< Length of hash key. */
rte_hash_function hash_func;/**< Function used to calculate hash. */
uint32_t hash_func_init_val;/**< Init value used by hash_func. */
-   rte_hash_cmp_eq_t rte_hash_cmp_eq; /**< Function used to compare keys. 
*/
+   rte_hash_cmp_eq_t rte_hash_custom_cmp_eq;
+   /**< Custom function used to compare keys. */
+   enum cmp_jump_table_case cmp_jump_table_idx;
+   /**< Indicates which compare function to use. */
uint32_t bucket_bitmask;/**< Bitmask for getting bucket index
from hash signature. */
uint32_t key_entry_size; /**< Size of each key entry. */
@@ -187,7 +225,16 @@ rte_hash_find_existing(const char *name)

 void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func)
 {
-   h->rte_hash_cmp_eq = func;
+   h->rte_hash_custom_cmp_eq = func;
+}
+
+static inline int
+rte_hash_cmp_eq(const void *key1, const void *key2, const struct rte_hash *h)
+{
+   if (h->cmp_jump_table_idx == KEY_CUSTOM)
+   return h->rte_hash_custom_cmp_eq(key1, key2, h->key_len);
+   else
+   return cmp_jump_table[h->cmp_jump_table_idx](key1, key2, 
h->key_len);
 }

 struct rte_hash *
@@ -292,35 +339,35 @@ rte_hash_create(const struct rte_hash_parameters *params)
/* Select function to compare keys */
switch (params->key_len) {
case 16:
-   h->rte_hash_cmp_eq = rte_hash_k16_cmp_eq;
+   h->cmp_jump_table_idx = KEY_16_BYTES;
break;
case 32:
-   h->rte_hash_cmp_eq = rte_hash_k32_cmp_eq;
+   h->cmp_jump_table_idx = KEY_32_BYTES;
break;
case 48:
-   h->rte_hash_cmp_eq = rte_hash_k48_cmp_eq;
+   h->cmp_jump_table_idx = KEY_48_BYTES;
break;
case 64:
-   h->rte_hash_cmp_eq = rte_hash_k64_cmp_eq;
+   h->cmp_jump_table_idx = KEY_64_BYTES;
break;
case 80:
-   h->rte_hash_cmp_eq = rte_hash_k80_cmp_eq;
+   h->cmp_jump_table_idx = KEY_80_BYTES;
break;
case 96:
- 

[dpdk-dev] [PATCH v2] l2fwd-crypto: fix incorrect command line help

[Pablo de Lara]

Previous cdev parameter was changed to cdev_type,
to select a crypto device type preference (HW/SW/ANY),
instead of the device itself (QAT/AESNI...).
Also deleted cdev duplicated parameter from the help.

Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")

Signed-off-by: Pablo de Lara 
Acked-by: Fiona Trahe 
---

Changes in v2:
- Removed duplicated parameter in command line help

 examples/l2fwd-crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 762d22a..ba0dcba 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -762,14 +762,14 @@ l2fwd_launch_one_lcore(void *arg)
 static void
 l2fwd_crypto_usage(const char *prgname)
 {
-   printf("%s [EAL options] -- --cdev TYPE [optional parameters]\n"
+   printf("%s [EAL options] --\n"
"  -p PORTMASK: hexadecimal bitmask of ports to configure\n"
"  -q NQ: number of queue (=ports) per lcore (default is 1)\n"
"  -s manage all ports from single lcore"
"  -t PERIOD: statistics will be refreshed each PERIOD seconds"
" (0 to disable, 10 default, 86400 maximum)\n"

-   "  --cdev AESNI_MB / QAT\n"
+   "  --cdev_type HW / SW / ANY\n"
"  --chain HASH_CIPHER / CIPHER_HASH\n"

"  --cipher_algo ALGO\n"
-- 
2.5.5

[dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help

[De Lara Guarch, Pablo]

> -Original Message-
> From: Trahe, Fiona
> Sent: Tuesday, March 22, 2016 3:08 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: Doherty, Declan; De Lara Guarch, Pablo
> Subject: RE: [dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help
> 
> 
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> > Sent: Tuesday, March 22, 2016 1:21 PM
> > To: dev at dpdk.org
> > Cc: Doherty, Declan; De Lara Guarch, Pablo
> > Subject: [dpdk-dev] [PATCH] l2fwd-crypto: fix incorrect parameter in help
> >
> > Previous cdev parameter was changed to cdev_type, to select a crypto
> device
> > type preference (HW/SW/ANY), instead of the device itself (QAT/AESNI...).
> >
> > Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
> >
> > Signed-off-by: Pablo de Lara 
> Acked-by: Fiona Trahe 

Self-NACK. The cdev parameter in the command line help is duplicated,
so I will use this patch to fix it.

[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization

[Michael Frasca]

Jing,

Thanks for your assistance. The experiment that you have built should allow you
to observe the bug. In [5], I would expect that queue 0 receives roughly 1/4 of
the packets that you sending, assuming the input packets have varied IP
addresses. Can you measure what % of packets are actually being received in this
single queue setup (after first running a 4-queue setup)?

When trying to running with only one RX queue, the fm10k retains the same RSS
hash function and redirection table that was configured from a previous run. As
a result, some packets are still being directed to other receive queues. I have
confirmed this by polling the queue specific stats, which I retrieved via
rte_eth_xstats_get().

Looking at fm10k_dev_rss_configure(), one should see that there is no
modification of fm10k registers when nb_rx_queues == 1. As far as I can tell,
this is the reason that only a certain partition of packets are being receive in
a single queue setup (after first running a multi-queue configuration).

I am unable to access my development environment today, but if you need, I can
later craft a patch to l3fwd that shows the measurement of packets received at
each queue.

Thanks,
Mike


> On Mar 24, 2016, at 2:40 AM, Chen, Jing D  wrote:
> 
> Hi, Frasca,
> 
> 
> 
>> -Original Message-
>> From: Michael Frasca [mailto:michael.frasca at oracle.com 
>> ]
>> Sent: Wednesday, March 23, 2016 9:43 PM
>> To: Chen, Jing D
>> Cc: dev at dpdk.org 
>> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device
>> initialization
>> 
>> Hi Jing,
>> 
>> I ran into this issue while trying to run experiments with different RSS
>> configurations (no RSS being one cases). It is not clear to me that setting 
>> this
>> register to zero is the best way to disable RSS.
>> 
>> After digging further, I have a theory that I'm having this issues because 
>> I've
>> only attached my DPDK application to SR-IOV ports. In
>> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the
>> DGLORT
>> decoder. However, it appears that this is only invoked for physical 
>> functions.
>> 
>> Could this be my problem? Is it required that I bind to the physical function
>> if I want to properly manipulate RSS?
>> 
>> Thanks,
>> Mike
>> 
> I don't know exactly what problem you ran into. I think we needn't worry 
> about 
> those DGLORT setting when using VF device.
> 
> I've followed steps to use SRIOV device with RSS enabled and disabled, both
> are worked well from my side after applying your patch. Below is my setup.
> 
> 1. PF with Linux driver "fm10k-next_0.19.3".
> 2. DPDK with latest code from master branch, apply your patch.
> 3. Use 1 VF device created by kernel driver.
> 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
> --config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)""
>with RSS enabled. After sending packets, I can see all 4 queues received 
> packets.
> 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
> --config="(0,0,2)""
>with RSS disabled. After sending packets, I can see queue 0 received 
> packets.
> 
> Can you explain what actual problem is?
> We can talk offline.

[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

[Olivier Matz]

Hi Bruce,

On 03/24/2016 01:20 PM, Bruce Richardson wrote:
>> @@ -734,12 +734,12 @@ dev_configure(struct rte_eth_dev *dev)
>>  }
>>  if (rxqs_n == priv->rxqs_n)
>>  return 0;
>> -if ((rxqs_n & (rxqs_n - 1)) != 0) {
>> -ERROR("%p: invalid number of RX queues (%u),"
>> -  " must be a power of 2",
>> +if (!rte_is_power_of_2(rxqs_n)) {
>> +WARN("%p: number of RX queues (%u), must be a"
>> +  " power of 2: remaining queues will be inactive",
> 
> I'm not sure how clear this warning message is. To the reader there are no
> extra "remaining" queues referred to, as it's not stated that the driver is
> allocating extra queues. How about e.g.:
> 
> WARN("%p: number of RX queues on device must by a power of 2. Allocating %u
>   queues, of which %u will be active. Remaining queues will be 
> inactive"...)
> 

You're right, I'll send a v2 with a clearer message.

Regards,
Olivier

[dpdk-dev] [PATCH v2 0/2] fix the wrong address of device data pointer

[Bruce Richardson]

On Thu, Mar 24, 2016 at 03:07:44PM +0800, Wenzhuo Lu wrote:
> In the function set_rx_mode, the pointer of device data points
> to the wrong address.
> 
> v2:
> - Remove the unnecessary cast.
> 
> Wenzhuo Lu (2):
>   ixgbe: fix the wrong address of device data pointer
>   igb: fix the wrong address of device data pointer
> 
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] ixgbe: fix vector RX can't always set packet_type properly

[Bruce Richardson]

On Wed, Mar 23, 2016 at 10:54:23AM +0800, Liang, Cunming wrote:
> Hi,
> 
> On 3/22/2016 10:30 PM, Konstantin Ananyev wrote:
> >Fixes: 39625417585 ("mbuf: redefine packet type")
> >
> >Current vector RX can't always set packet_type properly.
> >To be more specific:
> >a) it never sets RTE_PTYPE_L2_ETHER
> >b) it doesn't handle tunnel ipv4/ipv6 case correctly.
> >c) it doesn't check is IXGBE_RXDADV_PKTTYPE_ETQF set or not.
> >While a) is pretty easy to fix, b) and c) are not that straightforward
> >in terms of SIMD ops (specially b).
> >So far I wasn't able to make vRX support packet_type properly without
> >noticeable performance loss.
> >So for now, just remove that functionality at all from vector RX and
> >update dev_supported_ptypes_get().
> >
> >Signed-off-by: Konstantin Ananyev 
> >---
> >  drivers/net/ixgbe/ixgbe_ethdev.c   |  4 +---
> >  drivers/net/ixgbe/ixgbe_rxtx_vec.c | 34 +++---
> >  2 files changed, 12 insertions(+), 26 deletions(-)
> >
> >
> Acked-by: Liang Cunming 

Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested

[Bruce Richardson]

On Mon, Mar 21, 2016 at 05:08:04PM +0100, Olivier Matz wrote:
> When using RSS, the number of rxqs has to be a power of two.
> This is a problem because there is no API is dpdk that makes
> the application aware of that.
> 
> A good compromise is to allow the application to request a
> number of rxqs that is not a power of 2, but having inactive
> queues that will never receive packets. In this configuration,
> a warning will be issued to users to let them know that
> this is not an optimal configuration.
> 
> Signed-off-by: Olivier Matz 
> ---
>  drivers/net/mlx4/mlx4.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index cc4e9aa..eaf06db 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -698,7 +698,7 @@ txq_cleanup(struct txq *txq);
>  
>  static int
>  rxq_setup(struct rte_eth_dev *dev, struct rxq *rxq, uint16_t desc,
> -   unsigned int socket, const struct rte_eth_rxconf *conf,
> +   unsigned int socket, int inactive, const struct rte_eth_rxconf *conf,
> struct rte_mempool *mp);
>  
>  static void
> @@ -734,12 +734,12 @@ dev_configure(struct rte_eth_dev *dev)
>   }
>   if (rxqs_n == priv->rxqs_n)
>   return 0;
> - if ((rxqs_n & (rxqs_n - 1)) != 0) {
> - ERROR("%p: invalid number of RX queues (%u),"
> -   " must be a power of 2",
> + if (!rte_is_power_of_2(rxqs_n)) {
> + WARN("%p: number of RX queues (%u), must be a"
> +   " power of 2: remaining queues will be inactive",

I'm not sure how clear this warning message is. To the reader there are no
extra "remaining" queues referred to, as it's not stated that the driver is
allocating extra queues. How about e.g.:

WARN("%p: number of RX queues on device must by a power of 2. Allocating %u
queues, of which %u will be active. Remaining queues will be 
inactive"...)

/Bruce

[dpdk-dev] [PATCH] mlx4: check if port is configured for Ethernet

[Bruce Richardson]

On Tue, Mar 22, 2016 at 11:34:26AM +0100, Adrien Mazarguil wrote:
> Notify user otherwise. A similar check has already been added to mlx5 in
> commit "mlx5: check port is configured as ethernet device".
> 
> Signed-off-by: Adrien Mazarguil 
> ---
Applied to dpdk-next-net/rel_16_04

/Bruce

[dpdk-dev] Bug in i40e PMD for flexible payload

[Bruce Richardson]

On Wed, Mar 23, 2016 at 01:44:46PM -0500, Michael Habibi wrote:
> We are using the i40 implementation to configure flow director with
> flexible payload rules. When setting up rules, it allows you to set a value
> to 63 to disable the rule (NONUSE_FLX_PIT_DEST_OFF). However, the macro in
> question is always adding an offset value 50
> (I40E_FLX_OFFSET_IN_FIELD_VECTOR). This doesn't work when you use it in
> conjunction with NONUSE_FLX_PIT_DEST_OFF to disable it, because instead of
> taking 63 as is, it does 63 + 50 and breaks the functionality.
> 
> We used the following fix and it appears to work. Just sharing with the
> DPDK team in case they want to bring it in.
>
Thanks for this. Can you perhaps resubmit this fix in the form of an official
patch to DPDK, including a proper sign-off on it. The details for contributing
patches to DPDK is documented here: 
http://dpdk.org/doc/guides/contributing/patches.html

Without a signoff, we can't take in your code and use it.

Regards,
/Bruce

[dpdk-dev] arch check in example dpdk_qat

[Thomas Monjalon]

2016-03-24 10:50, De Lara Guarch, Pablo:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > When reading examples/dpdk_qat/Makefile, we can see this check:
> > 
> > ifneq ($(CONFIG_RTE_ARCH),"x86_64")
> > ifneq ($(LBITS),i686)
> > $(error The RTE_TARGET chosen is not compatible with this 
> > environment
> > \
> > (x86_64), for this application. Please change the definition of the 
> > \
> > RTE_TARGET environment variable, or run the application on a 32-bit
> > OS)
> > endif
> > endif
> > 
> > Is it on purpose to limit the 32-bit support to i686 only?
> > Instead of the message "run the application on a 32-bit OS", should it be
> > "on an i686 OS"?
> 
> i686 OS looks fine to me. Basically, when this app was made, the only 32-bit 
> target was i686,

What about i386, i486, i586 builds ?

> and the app needs the QAT driver to be running in 32 bits, if DPDK target is 
> 32-bit.

[dpdk-dev] arch check in example dpdk_qat

[De Lara Guarch, Pablo]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, March 24, 2016 11:01 AM
> To: De Lara Guarch, Pablo
> Cc: Richardson, Bruce; dev at dpdk.org
> Subject: Re: arch check in example dpdk_qat
> 
> 2016-03-24 10:50, De Lara Guarch, Pablo:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > When reading examples/dpdk_qat/Makefile, we can see this check:
> > >
> > > ifneq ($(CONFIG_RTE_ARCH),"x86_64")
> > > ifneq ($(LBITS),i686)
> > > $(error The RTE_TARGET chosen is not compatible with this
> environment
> > > \
> > > (x86_64), for this application. Please change the definition of 
> > > the \
> > > RTE_TARGET environment variable, or run the application on a 
> > > 32-bit
> > > OS)
> > > endif
> > > endif
> > >
> > > Is it on purpose to limit the 32-bit support to i686 only?
> > > Instead of the message "run the application on a 32-bit OS", should it be
> > > "on an i686 OS"?
> >
> > i686 OS looks fine to me. Basically, when this app was made, the only 32-bit
> target was i686,
> 
> What about i386, i486, i586 builds ?

We only support i686, no other 32-bit architectures.
> 
> > and the app needs the QAT driver to be running in 32 bits, if DPDK target is
> 32-bit.

[dpdk-dev] Question on examples/multi_process app

[Ananyev, Konstantin]

> >
> >> -Original Message-
> >> From: Richardson, Bruce
> >> Sent: Wednesday, March 23, 2016 11:45 AM
> >> To: Ananyev, Konstantin
> >> Cc: Harish Patil; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] Question on examples/multi_process app
> >>
> >> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
> >> > Hi everyone,
> >> >
> >> > > -Original Message-
> >> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> >>Richardson
> >> > > Sent: Tuesday, March 22, 2016 9:38 PM
> >> > > To: Harish Patil
> >> > > Cc: dev at dpdk.org
> >> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
> >> > >
> >> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
> >> > > > Hi,
> >> > > > I have a question regarding symmetric_mp and mp_server
> >>applications under
> >> > > > examples/multi_process. In those apps,
> >>rte_eth_promiscuous_enable() is
> >> > > > called before rte_eth_dev_start(). Is this the correct way to
> >>initialize
> >> > > > the port/device? As per the description in
> >> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
> >> > > >
> >> > > > "The functions exported by the application Ethernet API to setup
> >>a device
> >> > > > designated by its port identifier must be invoked in the
> >>following order:
> >> > > >
> >> > > > * rte_eth_dev_configure()
> >> > > > * rte_eth_tx_queue_setup()
> >> > > > * rte_eth_rx_queue_setup()
> >> > > > * rte_eth_dev_start()
> >> > > >
> >> > > > Then, the network application can invoke, in any order, the
> >>functions
> >> > > > exported by the Ethernet API to get the MAC address of a given
> >>device, to
> >> > > > get the speed and the status of a device physical link, to
> >> > > > receive/transmit [burst of] packets, and so on.?
> >> > > >
> >> > > > So should I consider this as an application issue or whether the
> >>PMD is
> >> > > > expected to handle it? If PMD is to handle it, then should the
> >>PMD be:
> >> > > >
> >> > > > 1) Rejecting the Promisc config? OR
> >> > > > 2) Cache the config and apply when dev_start() is called at later
> >>point?
> >> >
> >> > Yes as I remember 2) is done.
> >> > dev_start() invokes rte_eth_dev_config_restore(), which restores
> >> > promisc mode, mac addresses, etc.
> >> >
> >> > > >
> >> > > > Thanks,
> >> > > > Harish
> >> > > >
> >> > > Good question. I think most/all of the Intel adapters, - for which
> >>the app was
> >> > > originally written, way back in the day when there were only 2 PMDs
> >>in DPDK :)
> >> > > - will handle the promiscuous mode call either before or after the
> >>dev start.
> >> > > Assuming that's the case, and if it makes life easier for other
> >>driver writers,
> >> > > we should indeed standardize on one supported way of doing things -
> >>the way
> >> > > specified in the documentation being that one way, I would guess.
> >> > >
> >> > > So, e1000, ixgbe maintainers - do you see any issues with forcing
> >>the promiscuous
> >> > > mode set API to be called after the call to dev_start()?
> >> >
> >> > Not sure, why do we need to enforce that restriction?
> >> > Is there any problem with current way?
> 
> Yes, at least with the our driver/firmware interface. The port/device
> bring-up is carried out in a certain order which requires port config like
> promisc mode is called after dev_start().
> 
> >>
> >> It complicates things for driver writers is all,
> >
> >Not sure how?
> >All this replay is done at rte_ethdev layer.
> >Honestly, so far I don't remember any complaint about promisc on/off.
> >
> >> and conflicts slightly with
> >> what is stated in the docs.
> >
> >Update the docs? :)
> 
> Anyway, please let me know what you guys decide? If the app is changed
> then nothing needs to done on driver side. Otherwise I have to think of
> how to handle this.
> 

So you are saying that for your device if dev_ops->promiscuous_enable()
is called before dev_ops->dev_start(), it would cause  a problem right?
Konstantin 

[dpdk-dev] [PATCH v2 0/5] virtio support for container

[Tan, Jianfeng]

Hi Neil,

On 3/24/2016 3:17 AM, Neil Horman wrote:
> On Fri, Feb 05, 2016 at 07:20:23PM +0800, Jianfeng Tan wrote:
>> v1->v2:
>>   - Rebase on the patchset of virtio 1.0 support.
>>   - Fix cannot create non-hugepage memory.
>>   - Fix wrong size of memory region when "single-file" is used.
>>   - Fix setting of offset in virtqueue to use virtual address.
>>   - Fix setting TUNSETVNETHDRSZ in vhost-user's branch.
>>   - Add mac option to specify the mac address of this virtual device.
>>   - Update doc.
>>
>> This patchset is to provide high performance networking interface (virtio)
>> for container-based DPDK applications. The way of starting DPDK apps in
>> containers with ownership of NIC devices exclusively is beyond the scope.
>> The basic idea here is to present a new virtual device (named eth_cvio),
>> which can be discovered and initialized in container-based DPDK apps using
>> rte_eal_init(). To minimize the change, we reuse already-existing virtio
>> frontend driver code (driver/net/virtio/).
>>   
>> Compared to QEMU/VM case, virtio device framework (translates I/O port r/w
>> operations into unix socket/cuse protocol, which is originally provided in
>> QEMU), is integrated in virtio frontend driver. So this converged driver
>> actually plays the role of original frontend driver and the role of QEMU
>> device framework.
>>   
>> The major difference lies in how to calculate relative address for vhost.
>> The principle of virtio is that: based on one or multiple shared memory
>> segments, vhost maintains a reference system with the base addresses and
>> length for each segment so that an address from VM comes (usually GPA,
>> Guest Physical Address) can be translated into vhost-recognizable address
>> (named VVA, Vhost Virtual Address). To decrease the overhead of address
>> translation, we should maintain as few segments as possible. In VM's case,
>> GPA is always locally continuous. In container's case, CVA (Container
>> Virtual Address) can be used. Specifically:
>> a. when set_base_addr, CVA address is used;
>> b. when preparing RX's descriptors, CVA address is used;
>> c. when transmitting packets, CVA is filled in TX's descriptors;
>> d. in TX and CQ's header, CVA is used.
>>   
>> How to share memory? In VM's case, qemu always shares all physical layout
>> to backend. But it's not feasible for a container, as a process, to share
>> all virtual memory regions to backend. So only specified virtual memory
>> regions (with type of shared) are sent to backend. It's a limitation that
>> only addresses in these areas can be used to transmit or receive packets.
>>
>> Known issues
>>
>> a. When used with vhost-net, root privilege is required to create tap
>> device inside.
>> b. Control queue and multi-queue are not supported yet.
>> c. When --single-file option is used, socket_id of the memory may be
>> wrong. (Use "numactl -N x -m x" to work around this for now)
>>   
>> How to use?
>>
>> a. Apply this patchset.
>>
>> b. To compile container apps:
>> $: make config RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
>> $: make install RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
>> $: make -C examples/l2fwd RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
>> $: make -C examples/vhost RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
>>
>> c. To build a docker image using Dockerfile below.
>> $: cat ./Dockerfile
>> FROM ubuntu:latest
>> WORKDIR /usr/src/dpdk
>> COPY . /usr/src/dpdk
>> ENV PATH "$PATH:/usr/src/dpdk/examples/l2fwd/build/"
>> $: docker build -t dpdk-app-l2fwd .
>>
>> d. Used with vhost-user
>> $: ./examples/vhost/build/vhost-switch -c 3 -n 4 \
>>  --socket-mem 1024,1024 -- -p 0x1 --stats 1
>> $: docker run -i -t -v :/var/run/usvhost \
>>  -v /dev/hugepages:/dev/hugepages \
>>  dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
>>  --vdev=eth_cvio0,path=/var/run/usvhost -- -p 0x1
>>
>> f. Used with vhost-net
>> $: modprobe vhost
>> $: modprobe vhost-net
>> $: docker run -i -t --privileged \
>>  -v /dev/vhost-net:/dev/vhost-net \
>>  -v /dev/net/tun:/dev/net/tun \
>>  -v /dev/hugepages:/dev/hugepages \
>>  dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
>>  --vdev=eth_cvio0,path=/dev/vhost-net -- -p 0x1
>>
>> By the way, it's not necessary to run in a container.
>>
>> Signed-off-by: Huawei Xie 
>> Signed-off-by: Jianfeng Tan 
>>
>> Jianfeng Tan (5):
>>mem: add --single-file to create single mem-backed file
>>mem: add API to obtain memory-backed file info
>>virtio/vdev: add embeded device emulation
>>virtio/vdev: add a new vdev named eth_cvio
>>docs: add release note for virtio for container
>>
>>   config/common_linuxapp |   5 +
>>   doc/guides/rel_notes/release_2_3.rst   |   4 +
>>   drivers/net/virtio/Makefile|   4 +
>>   drivers/net/virtio/vhost.h | 194 +++
>>   drivers/net/virtio/vhost_embedded.c| 809 
>> +
>>   drivers/net/virtio/virtio_ethdev.c 

[dpdk-dev] arch check in example dpdk_qat

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, March 23, 2016 11:04 AM
> To: Richardson, Bruce; De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: arch check in example dpdk_qat
> 
> When reading examples/dpdk_qat/Makefile, we can see this check:
> 
> ifneq ($(CONFIG_RTE_ARCH),"x86_64")
> ifneq ($(LBITS),i686)
> $(error The RTE_TARGET chosen is not compatible with this environment
> \
> (x86_64), for this application. Please change the definition of the \
> RTE_TARGET environment variable, or run the application on a 32-bit
> OS)
> endif
> endif
> 
> Is it on purpose to limit the 32-bit support to i686 only?
> Instead of the message "run the application on a 32-bit OS", should it be
> "on an i686 OS"?

i686 OS looks fine to me. Basically, when this app was made, the only 32-bit 
target was i686,
and the app needs the QAT driver to be running in 32 bits, if DPDK target is 
32-bit.

Thanks,
Pablo

[dpdk-dev] [PATCH 1/2 v5] i40e: support floating VEB config

[Zhe Tao]

On Wed, Mar 23, 2016 at 01:51:09PM +0100, Thomas Monjalon wrote:
> 2016-03-23 20:27, Zhe Tao:
> > Add the new floating related argument option in the EAL.
> > Using this parameter, all the samples can decide whether to use legacy 
> > VEB/VEPA
> > or floating VEB.
> > Even the floating argument is provided in the EAL, but this floating
> > feature are only support for FVL so far.
> > 
> > Signed-off-by: Zhe Tao 
> > ---
> >  doc/guides/testpmd_app_ug/run_app.rst  | 4 
> >  lib/librte_eal/common/eal_common_options.c | 4 
> >  lib/librte_eal/common/eal_internal_cfg.h   | 1 +
> >  lib/librte_eal/common/eal_options.h| 2 ++
> >  4 files changed, 11 insertions(+)
> 
> The label of this patch is "i40e" but it doesn't touch i40e.
> Actually it is an EAL change but there should not be related to EAL.
> It seems to be a config option of the device.
> Please check how ftag has been enabled in fm10k:
>   dpdk.org/browse/dpdk/commit/?id=7958b1310d5e
very good suggestion, thanks for the advice

[dpdk-dev] [PATCH v2 0/5] virtio support for container

[Neil Horman]

On Thu, Mar 24, 2016 at 11:10:50AM +0800, Tan, Jianfeng wrote:
> Hi Neil,
> 
> On 3/24/2016 3:17 AM, Neil Horman wrote:
> >On Fri, Feb 05, 2016 at 07:20:23PM +0800, Jianfeng Tan wrote:
> >>v1->v2:
> >>  - Rebase on the patchset of virtio 1.0 support.
> >>  - Fix cannot create non-hugepage memory.
> >>  - Fix wrong size of memory region when "single-file" is used.
> >>  - Fix setting of offset in virtqueue to use virtual address.
> >>  - Fix setting TUNSETVNETHDRSZ in vhost-user's branch.
> >>  - Add mac option to specify the mac address of this virtual device.
> >>  - Update doc.
> >>
> >>This patchset is to provide high performance networking interface (virtio)
> >>for container-based DPDK applications. The way of starting DPDK apps in
> >>containers with ownership of NIC devices exclusively is beyond the scope.
> >>The basic idea here is to present a new virtual device (named eth_cvio),
> >>which can be discovered and initialized in container-based DPDK apps using
> >>rte_eal_init(). To minimize the change, we reuse already-existing virtio
> >>frontend driver code (driver/net/virtio/).
> >>Compared to QEMU/VM case, virtio device framework (translates I/O port r/w
> >>operations into unix socket/cuse protocol, which is originally provided in
> >>QEMU), is integrated in virtio frontend driver. So this converged driver
> >>actually plays the role of original frontend driver and the role of QEMU
> >>device framework.
> >>The major difference lies in how to calculate relative address for vhost.
> >>The principle of virtio is that: based on one or multiple shared memory
> >>segments, vhost maintains a reference system with the base addresses and
> >>length for each segment so that an address from VM comes (usually GPA,
> >>Guest Physical Address) can be translated into vhost-recognizable address
> >>(named VVA, Vhost Virtual Address). To decrease the overhead of address
> >>translation, we should maintain as few segments as possible. In VM's case,
> >>GPA is always locally continuous. In container's case, CVA (Container
> >>Virtual Address) can be used. Specifically:
> >>a. when set_base_addr, CVA address is used;
> >>b. when preparing RX's descriptors, CVA address is used;
> >>c. when transmitting packets, CVA is filled in TX's descriptors;
> >>d. in TX and CQ's header, CVA is used.
> >>How to share memory? In VM's case, qemu always shares all physical layout
> >>to backend. But it's not feasible for a container, as a process, to share
> >>all virtual memory regions to backend. So only specified virtual memory
> >>regions (with type of shared) are sent to backend. It's a limitation that
> >>only addresses in these areas can be used to transmit or receive packets.
> >>
> >>Known issues
> >>
> >>a. When used with vhost-net, root privilege is required to create tap
> >>device inside.
> >>b. Control queue and multi-queue are not supported yet.
> >>c. When --single-file option is used, socket_id of the memory may be
> >>wrong. (Use "numactl -N x -m x" to work around this for now)
> >>How to use?
> >>
> >>a. Apply this patchset.
> >>
> >>b. To compile container apps:
> >>$: make config RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> >>$: make install RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> >>$: make -C examples/l2fwd RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> >>$: make -C examples/vhost RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
> >>
> >>c. To build a docker image using Dockerfile below.
> >>$: cat ./Dockerfile
> >>FROM ubuntu:latest
> >>WORKDIR /usr/src/dpdk
> >>COPY . /usr/src/dpdk
> >>ENV PATH "$PATH:/usr/src/dpdk/examples/l2fwd/build/"
> >>$: docker build -t dpdk-app-l2fwd .
> >>
> >>d. Used with vhost-user
> >>$: ./examples/vhost/build/vhost-switch -c 3 -n 4 \
> >>--socket-mem 1024,1024 -- -p 0x1 --stats 1
> >>$: docker run -i -t -v :/var/run/usvhost \
> >>-v /dev/hugepages:/dev/hugepages \
> >>dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
> >>--vdev=eth_cvio0,path=/var/run/usvhost -- -p 0x1
> >>
> >>f. Used with vhost-net
> >>$: modprobe vhost
> >>$: modprobe vhost-net
> >>$: docker run -i -t --privileged \
> >>-v /dev/vhost-net:/dev/vhost-net \
> >>-v /dev/net/tun:/dev/net/tun \
> >>-v /dev/hugepages:/dev/hugepages \
> >>dpdk-app-l2fwd l2fwd -c 0x4 -n 4 -m 1024 --no-pci \
> >>--vdev=eth_cvio0,path=/dev/vhost-net -- -p 0x1
> >>
> >>By the way, it's not necessary to run in a container.
> >>
> >>Signed-off-by: Huawei Xie 
> >>Signed-off-by: Jianfeng Tan 
> >>
> >>Jianfeng Tan (5):
> >>   mem: add --single-file to create single mem-backed file
> >>   mem: add API to obtain memory-backed file info
> >>   virtio/vdev: add embeded device emulation
> >>   virtio/vdev: add a new vdev named eth_cvio
> >>   docs: add release note for virtio for container
> >>
> >>  config/common_linuxapp |   5 +
> >>  doc/guides/rel_notes/release_2_3.rst   |   4 +
> >>  drivers/net/virtio/Makefile|   4 +
> >>  drivers/net/virtio/vhost.h   

[dpdk-dev] [PATCH v2 2/7] drivers/net/e1000: Fix missing brackets

[Panu Matilainen]

On 03/24/2016 02:35 AM, Lu, Wenzhuo wrote:
> Hi Thomas, Aaron,
>>> Wenzhuo, do you agree to fix the base driver here?
> Honestly I find the logic has some problem and maybe more changes needed. I'm 
> talking with our kernel driver contactors to make sure they have no concern 
> about  my idea.
> And Aaron, do we really need to fix this code? For I find this function is 
> not called. So it has no real impact to us. Could we just wait until kernel 
> driver fixes it and leverage the new version? Thanks.

It breaks the build with gcc >= 6.0 due to -Werror so yes we need to fix 
it, one way or the other.

As spelled out in an earlier mail 
(http://dpdk.org/ml/archives/dev/2016-March/034290.html), for somebody 
building with gcc >= 6.0 the options basically are:
1) disable the driver entirely
2) build with -Wno-error
3) paper over it with local warning disablers
4) patch the thing locally

If the offending function really is not used at all in DPDK context then 
3) is an entirely valid option for an upstream solution, ie something 
like (untested)

--- a/drivers/net/e1000/Makefile
+++ b/drivers/net/e1000/Makefile
@@ -54,6 +54,9 @@ else
  #
  CFLAGS_BASE_DRIVER = -Wno-uninitialized -Wno-unused-parameter
  CFLAGS_BASE_DRIVER += -Wno-unused-variable
+ifeq ($(shell test $(GCC_VERSION) -ge 60 && echo 1), 1)
+CFLAGS_BASE_DRIVER += -Wno-misleading-indentation
+endif
  endif

  #


- Panu -

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Marc]

On 24 March 2016 at 07:21, Xu, Qian Q  wrote:

> Marc
>
> I didn?t quite get your points, I observed that after applying this
> patchset, all intel nic can?t be started, maybe something wrong happened
> when you check the duplex/autoneg value for different NICs. If we want to
> merge the patchset in RC2, we need fix them. Maybe not an easy job in
> several days.
>

Is this test#1 one of the tests contained in the DPDK repository or is it
an internal test?

Marc


>
>
>
>
> Thanks
>
> Qian
>
>
>
> *From:* marc.sune at gmail.com [mailto:marc.sune at gmail.com] *On Behalf Of *
> Marc
> *Sent:* Thursday, March 24, 2016 4:54 AM
> *To:* Xu, Qian Q
> *Cc:* Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin;
> Richardson, Bruce; dev at dpdk.org
>
> *Subject:* Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API
> refactoring
>
>
>
> Qian,
>
>
>
> On 23 March 2016 at 02:18, Xu, Qian Q  wrote:
>
> We have tested with intel nic and found port can't be started for all
> nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please
> check and fix it.
>
>
> Thanks
> Qian
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, March 23, 2016 3:59 AM
> To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin
> Cc: marcdevel at gmail.com; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API
> refactoring
>
> 2016-03-17 19:08, Thomas Monjalon:
> > There are still too few tests and reviews, especially for
> > autonegotiation with Intel devices (patch #6).
> > I would not be surprised to see some bugs in this rework.
>
> Any feedback about autoneg in e1000/ixgbe/i40e?
> Has it been tested before its integration in RC2?
>
> > The capabilities must be adapted per device. It can be improved in a
> > separate patch.
> >
> > It will be integrated in 16.04-rc2.
> > Please test and review shortly, thanks!
>
>
>
> -- Forwarded message --
> From: "Xu, Qian Q" 
> To: "Cao, Waterman" , "Glynn, Michael J" <
> michael.j.glynn at intel.com>
> Cc: "Richardson, Bruce" , "Zhu, Heqing" <
> heqing.zhu at intel.com>, "O'Driscoll, Tim" ,
> "Mcnamara, John" , "Xu, HuilongX" <
> huilongx.xu at intel.com>, "Fu, JingguoX" , "Xu, 
> Qian
> Q" , "Zhang, Helin" 
> Date: Tue, 22 Mar 2016 06:41:37 +
> Subject: RE: DPDK link speed with Intel devices
> Hi, all
> We have worked out the basic test cases for the patchset.
> 1. Test the link speed on major Intel NICs to see if the speed is right.
> 2. Test the auto-negoation on major Intel NICs to ensure it's working.
> Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW)
>
> When we run the Test#1 for all major NICs. We found that all these NIC
> port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is
> applied, all INTEL port can't be start, terrible things!
>
> Interactive-mode selected
> Configuring Port 0 (socket 0)
> PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440
> hw_ring=0x7f13e99e5480 dma_addr=0x8299e5480
> PMD: ixgbe_set_tx_function(): Using simple tx code path
> PMD: ixgbe_set_tx_function(): Vector tx enabled.
> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080
> sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380
> PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation
> disabled
> Fail to start port 0
> Configuring Port 1 (socket 0)
> PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
> PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation
> disabled
>
>
>
>
>
> Just to double-check; is the test#1 adapted to the _new_ API that ethdev
> has to set link speeds? For the output it seems autoneg is disabled =>
> fixed speed, hence the new bitmaps have to be used.
>
>
>
> (I am not claiming patchset is bug free; there might be issues still)
>
>
>
> Regards
>
> marc
>
>
>
> Fail to start port 1
> Please stop the ports first
> Done
>
> Thanks
> Qian
>
>
> -Original Message-
> From: Cao, Waterman
> Sent: Tuesday, March 22, 2016 11:06 AM
> To: Glynn, Michael J
> Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu,
> Qian Q; Cao, Waterman
> Subject: RE: DPDK link speed with Intel devices
>
> Hi Mike,
>
> We just knew this patch set last week.
> Since this patch set is required to test with a lot of NIC,  we
> need more document from Dev about this patch.
> Currently, Qian is working on with Wenzhuo on it now.
>
> Waterman
>
>
> -Original Message-
> From: Glynn, Michael J
> Sent: Tuesday, March 22, 2016 1:31 AM
> To: Cao, Waterman 
> Cc: Richardson, Bruce ; Zhu, Heqing <
> heqing.zhu at intel.com>; O'Driscoll, Tim ;
> Mcnamara, John 
> Subject: FW: DPDK link speed with Intel devices
> Importance: High
>
> Hi Waterman, all

[dpdk-dev] [PATCH v2] ixgbe: add check for tx queue number

[Fischetti, Antonio]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, March 23, 2016 3:29 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo ; De Lara Guarch, Pablo
> 
> Subject: [dpdk-dev] [PATCH v2] ixgbe: add check for tx queue number
> 
> IXGBE supports 128 TX queues. However, the full 128 queues
> are only available in VT and DCB mode.
> In normal default "none" mode (VT/DCB off) the maximum number
> of available queues is only 64.
> IXGBE doesn't check the mode when reporting the available
> number of queues. If a queue larger than 64 is used in default mode,
> the TX packets will be dropped silently.
> 
> This change adds a check to forbid using a queue number larger than 64
> during device configuration (in default mode), so that the problem is
> reported as early as possible.
> It also changes the order of where the dev_conf parameters are copied
> into the dev structure so that the correct maximum number of queues
> is reported for the correct mode.
> 
> Signed-off-by: Wenzhuo Lu 
> Signed-off-by: Pablo de Lara 

Tested-by: Antonio Fischetti 

[dpdk-dev] Suggestions for the dpdk stable tree

[Christian Ehrhardt]

Hi,
there is a stable tree for dpdk 2.2 at http://dpdk.org/browse/dpdk-stable/
But it is still at the 2.2 Release status.

I was working on testing 2.2 and needed to pull in some patches from post
2.2 release to fix issues.
After that I started to "scan" the git log what else might apply to a clean
and uncritical addition to a dpdp-2.2 as "stability backports".

I had a focus on identifying:
- only patches to components that are enabled in our packaging (well that
is close to the default conf so it should be ok for you as well)
- issues that have a real chance to occur
- patches that are small, so review is not overly complex
- apply without manual adaption (offset ok to some extend, no fuzz, no
manual fix)
I realized that I should suggest that list of patches to you to consider
adding it to the stable tree.
So therefore for you to consider:


commit d3a274ce9dee28118b8647e0db72ef0f4b6a6323

app/testpmd: handle SIGINT and SIGTERM

commit 308df2bfba3d238fc1d2d16cc10c84681803b408

Handle SIGINT and SIGTERM in l3fwd.

commit da82ee17e6ea99bf2931383ac33b0caccaaaefce

tools: fix unbinding failure handling

commit 16c1814c802c205f6d3c32e3d3d10de9f87e7f22

tools: support Python 3 in bind script

commit bb9f408550d13af6c1da104b0d9d9b9837f69bde

tools: support binding to built-in kernel modules


commit 6e7caa1ad9d597fed0a49468af25ae6e68b8c443

eal/linux: support built-in kernel modules


commit 86f36ff9578b5f3d697c8fcf6072dcb70e2b246f

mempool: fix leak when creation fails


commit ca67ed289a76f38d6c4a4021985a36eaf1d77e28

vhost: fix leak of fds and mmaps


commit fa11a8a7251e14eca0a4190128732386f13551bd

port: fix crash for ring writer nodrop

commit 04f366906ab395c8047bebfc1ddea244dfcb40f5

port: fix crash for ethdev writer nodrop


commit c7a4ff80722e9237a4c504106d21ba5ca27d8df2

i40e: fix overflow

commit 097e920c32bf19cf918cc071525f33b0abdeebaf

i40e: fix inverted check for no refcount

commit 330aa319382aec9ea595f9ebcb9a3c44647ad66c

i40e: fix VLAN filtering

commit 9f44dd3d8ad447c7f797a9564d30a15e5ab7f72b

i40e/base: fix missing check for stopped admin queue

commit 8a8807369ffafef90c410279b4b2645d2d7a7483

i40e/base: fix driver load failure


commit 7656a546c0609f3205558a5d48352c82607d38d3

fm10k: fix VLAN flag in scattered Rx


commit c6fb0e55585206a89f6db396de860e6e844cad06

pcap: fix captured frame length


commit 6e02723754fb2b341701ac438486b2dfea98b523

bonding: fix detach of bonded device

commit df3e8ad73f4c92b4eb8f49ff33271d4a09e6a04a

bonding: fix detach of slave devices

commit 786c990a11e6e6592dfdee02840877070aa3a79a

bonding: copy entire config structure in mode 4

commit 6698820b5f6d955b6af2b916e1074db236d4f5a2

bonding: do not ignore multicast in mode 4

commit 8997a10bfcad789d000debaac4cd85cd3db57997

bonding: fix active slaves with no primary

commit 7a7122edf1c8d63e516d1b2c2eff6fa9b54e0f82

bonding: do not activate slave twice

commit 2186fff3675d4e774cecc8f918c05063e0367d28

bonding: fix crash when no slave device


commit 3b1e3e4e362453df8cecbc6d481444be8b84326e

virtio: fix descriptors pointing to the same buffer

commit c680a4a88c4312068f60937a7ba51eac8211c9a6

virtio: fix crash in statistics functions

commit 9a0615af7746485d73d10561cc0743bc2fcd4bf7

virtio: fix restart


Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

[dpdk-dev] [PATCH v2] ixgbe: add check for tx queue number

[Fischetti, Antonio]

Hi, I tested this patch with OVS+DPDK on a 72 lcores board with an 
Intel 82599ES 10 Gb NIC. It works fine.

Now when I call 'rte_eth_dev_info_get()' it returns correctly the number
of available Tx queues for the default mode, i.e. 64 when no VT and no
DCB is set.
Also, if I attempt to request more than the available queues via
'rte_eth_dev_configure()' it correctly returns -EINVAL error.

I checked it works with both DPDK v2.2.0 and the latest master branch.

Without this patch there was a misbehavior: when OVS queried for the
number of available Tx queues, 128 was returned. As a consequence
OVS was requesting 73 Tx queues, even though just 64 were really 
available. No error was returned. Of course any transmission was
failing when OVS attempted to use queues with ID >= 64.

Regards,
Antonio

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, March 23, 2016 3:29 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo ; De Lara Guarch, Pablo
> 
> Subject: [dpdk-dev] [PATCH v2] ixgbe: add check for tx queue number
> 
> IXGBE supports 128 TX queues. However, the full 128 queues
> are only available in VT and DCB mode.
> In normal default "none" mode (VT/DCB off) the maximum number
> of available queues is only 64.
> IXGBE doesn't check the mode when reporting the available
> number of queues. If a queue larger than 64 is used in default mode,
> the TX packets will be dropped silently.
> 
> This change adds a check to forbid using a queue number larger than 64
> during device configuration (in default mode), so that the problem is
> reported as early as possible.
> It also changes the order of where the dev_conf parameters are copied
> into the dev structure so that the correct maximum number of queues
> is reported for the correct mode.
> 
> Signed-off-by: Wenzhuo Lu 
> Signed-off-by: Pablo de Lara 
> ---
> 
> Changes in v2:
> 
> - Reorder memcpy of device configuration in rte_eth_dev_configure(),
>   so function gets the correct maximum number of queues
>   (depending on the operation mode), before checking the
>   requested number of queues.
> - Renamed new macro
> - Reworded/wrapped commit message
> 
>  drivers/net/ixgbe/ixgbe_ethdev.c | 17 -
>  drivers/net/ixgbe/ixgbe_ethdev.h |  1 +
>  lib/librte_ether/rte_ethdev.c|  6 +++---
>  3 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index d4d883a..c799b47 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1862,7 +1862,7 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
>  {
>   struct rte_eth_conf *dev_conf = >data->dev_conf;
>   uint16_t nb_rx_q = dev->data->nb_rx_queues;
> - uint16_t nb_tx_q = dev->data->nb_rx_queues;
> + uint16_t nb_tx_q = dev->data->nb_tx_queues;
> 
>   if (RTE_ETH_DEV_SRIOV(dev).active != 0) {
>   /* check multi-queue mode */
> @@ -2002,6 +2002,16 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
>   return -EINVAL;
>   }
>   }
> +
> + if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE) {
> + if (nb_tx_q > IXGBE_NONE_MODE_TX_NB_QUEUES) {
> + PMD_INIT_LOG(ERR,
> +  "Neither VT nor DCB are enabled, "
> +  "nb_tx_q > %d.",
> +
> IXGBE_NONE_MODE_TX_NB_QUEUES);
> + return -EINVAL;
> + }
> + }
>   }
>   return 0;
>  }
> @@ -2856,9 +2866,14 @@ static void
>  ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
> *dev_info)
>  {
>   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
> + struct rte_eth_conf *dev_conf = >data->dev_conf;
> 
>   dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
>   dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
> + if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
> + if (dev_conf->txmode.mq_mode == ETH_MQ_TX_NONE)
> + dev_info->max_tx_queues =
> IXGBE_NONE_MODE_TX_NB_QUEUES;
> + }
>   dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL register
> */
>   dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS register
> */
>   dev_info->max_mac_addrs = hw->mac.num_rar_entries;
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index 5c3aa16..691c62f 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -61,6 +61,7 @@
>  #define IXGBE_MAX_RX_QUEUE_NUM   128
>  #define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
>  #define IXGBE_DCB_NB_QUEUES  IXGBE_MAX_RX_QUEUE_NUM
> +#define IXGBE_NONE_MODE_TX_NB_QUEUES 64
> 
>  #ifndef NBBY
>  #define NBBY 8   /* number of bits in a byte */
> diff --git 

[dpdk-dev] [PATCH v2 2/2] igb: fix the wrong address of device data pointer

[Wu, Jingjing]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, March 24, 2016 3:08 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v2 2/2] igb: fix the wrong address of device data
> pointer
> 
> In the function set_rx_mode, the pointer of device data points to the wrong
> address as found in ixgbe code.
> 
> Fixes: be2d648a2dd3("igb: add PF support")
> Signed-off-by: Wenzhuo Lu 
Acked-by: Jingjing Wu 

[dpdk-dev] [PATCH v2 1/2] ixgbe: fix the wrong address of device data pointer

[Wu, Jingjing]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, March 24, 2016 3:08 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH v2 1/2] ixgbe: fix the wrong address of device
> data pointer
> 
> There's an issue reported. In the scenario DPDK PF + DPDK VF, if the VF port
> is closed, PF port cannot receive packets.
> I found at that time the promicuous mode is disabled on the PF port. But it
> should be enabled.
> When VF port is closed, it will send a message to its PF port to reset it. 
> During
> this, PF port will also reset its own promicuous mode. Which promiscuous
> mode should be set depends on the parameter stored in the device data. In
> the function set_rx_mode, the pointer of device data points to the wrong
> address. So, the promiscuous mode is wrong.
> 
> Fixes: 00e30184daa0("ixgbe: add PF support")
> Signed-off-by: Wenzhuo Lu 
> Reported-by: Bernard Iremonger 
Acked-by: Jingjing Wu 

[dpdk-dev] [PATCH 1/2] ixgbe: fix the wrong address of device data pointer

[Lu, Wenzhuo]

Hi Jingjing,

> >  set_rx_mode(struct rte_eth_dev *dev)
> >  {
> > struct rte_eth_dev_data *dev_data =
> > -   (struct rte_eth_dev_data*)dev->data->dev_private;
> > +   (struct rte_eth_dev_data *)dev->data;
> Cast is unnecessary here.
O, didn't notice that. Will send a V2. Thanks.

> 
> /Jingjing

[dpdk-dev] Question on examples/multi_process app

[Harish Patil]

>
>
>
>
>> -Original Message-
>> From: Richardson, Bruce
>> Sent: Wednesday, March 23, 2016 11:45 AM
>> To: Ananyev, Konstantin
>> Cc: Harish Patil; dev at dpdk.org
>> Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> 
>> On Wed, Mar 23, 2016 at 11:09:17AM +, Ananyev, Konstantin wrote:
>> > Hi everyone,
>> >
>> > > -Original Message-
>> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
>>Richardson
>> > > Sent: Tuesday, March 22, 2016 9:38 PM
>> > > To: Harish Patil
>> > > Cc: dev at dpdk.org
>> > > Subject: Re: [dpdk-dev] Question on examples/multi_process app
>> > >
>> > > On Tue, Mar 22, 2016 at 08:03:42PM +, Harish Patil wrote:
>> > > > Hi,
>> > > > I have a question regarding symmetric_mp and mp_server
>>applications under
>> > > > examples/multi_process. In those apps,
>>rte_eth_promiscuous_enable() is
>> > > > called before rte_eth_dev_start(). Is this the correct way to
>>initialize
>> > > > the port/device? As per the description in
>> > > > http://dpdk.org/doc/api/rte__ethdev_8h.html:
>> > > >
>> > > > "The functions exported by the application Ethernet API to setup
>>a device
>> > > > designated by its port identifier must be invoked in the
>>following order:
>> > > >
>> > > > * rte_eth_dev_configure()
>> > > > * rte_eth_tx_queue_setup()
>> > > > * rte_eth_rx_queue_setup()
>> > > > * rte_eth_dev_start()
>> > > >
>> > > > Then, the network application can invoke, in any order, the
>>functions
>> > > > exported by the Ethernet API to get the MAC address of a given
>>device, to
>> > > > get the speed and the status of a device physical link, to
>> > > > receive/transmit [burst of] packets, and so on.?
>> > > >
>> > > > So should I consider this as an application issue or whether the
>>PMD is
>> > > > expected to handle it? If PMD is to handle it, then should the
>>PMD be:
>> > > >
>> > > > 1) Rejecting the Promisc config? OR
>> > > > 2) Cache the config and apply when dev_start() is called at later
>>point?
>> >
>> > Yes as I remember 2) is done.
>> > dev_start() invokes rte_eth_dev_config_restore(), which restores
>> > promisc mode, mac addresses, etc.
>> >
>> > > >
>> > > > Thanks,
>> > > > Harish
>> > > >
>> > > Good question. I think most/all of the Intel adapters, - for which
>>the app was
>> > > originally written, way back in the day when there were only 2 PMDs
>>in DPDK :)
>> > > - will handle the promiscuous mode call either before or after the
>>dev start.
>> > > Assuming that's the case, and if it makes life easier for other
>>driver writers,
>> > > we should indeed standardize on one supported way of doing things -
>>the way
>> > > specified in the documentation being that one way, I would guess.
>> > >
>> > > So, e1000, ixgbe maintainers - do you see any issues with forcing
>>the promiscuous
>> > > mode set API to be called after the call to dev_start()?
>> >
>> > Not sure, why do we need to enforce that restriction?
>> > Is there any problem with current way?

Yes, at least with the our driver/firmware interface. The port/device
bring-up is carried out in a certain order which requires port config like
promisc mode is called after dev_start().

>> 
>> It complicates things for driver writers is all,
>
>Not sure how?
>All this replay is done at rte_ethdev layer.
>Honestly, so far I don't remember any complaint about promisc on/off.
>
>> and conflicts slightly with
>> what is stated in the docs.
>
>Update the docs? :)

Anyway, please let me know what you guys decide? If the app is changed
then nothing needs to done on driver side. Otherwise I have to think of
how to handle this.

>
>> 
>> /Bruce
>

[dpdk-dev] [PATCH 1/2] ixgbe: fix the wrong address of device data pointer

[Wu, Jingjing]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Thursday, March 24, 2016 2:37 PM
> To: dev at dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH 1/2] ixgbe: fix the wrong address of device data
> pointer
> 
> There's an issue reported. In the scenario DPDK PF + DPDK VF, if the VF port
> is closed, PF port cannot receive packets.
> I found at that time the promicuous mode is disabled on the PF port. But it
> should be enabled.
> When VF port is closed, it will send a message to its PF port to reset it. 
> During
> this, PF port will also reset its own promicuous mode. Which promiscuous
> mode should be set depends on the parameter stored in the device data. In
> the function set_rx_mode, the pointer of device data points to the wrong
> address. So, the promiscuous mode is wrong.
> 
> Fixes: 00e30184daa0("ixgbe: add PF support")
> Signed-off-by: Wenzhuo Lu 
> Reported-by: Bernard Iremonger 
> ---
>  drivers/net/ixgbe/ixgbe_pf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
> index b854c72..0f8ad55 100644
> --- a/drivers/net/ixgbe/ixgbe_pf.c
> +++ b/drivers/net/ixgbe/ixgbe_pf.c
> @@ -313,7 +313,7 @@ static void
>  set_rx_mode(struct rte_eth_dev *dev)
>  {
>   struct rte_eth_dev_data *dev_data =
> - (struct rte_eth_dev_data*)dev->data->dev_private;
> + (struct rte_eth_dev_data *)dev->data;
Cast is unnecessary here.

/Jingjing
>   struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
>   u32 fctrl, vmolr = IXGBE_VMOLR_BAM | IXGBE_VMOLR_AUPE;
>   uint16_t vfn = dev_num_vf(dev);
> --
> 1.9.3

[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization

[Chen, Jing D]

Hi, Frasca,



> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Wednesday, March 23, 2016 9:43 PM
> To: Chen, Jing D
> Cc: dev at dpdk.org
> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device
> initialization
> 
> Hi Jing,
> 
> I ran into this issue while trying to run experiments with different RSS
> configurations (no RSS being one cases). It is not clear to me that setting 
> this
> register to zero is the best way to disable RSS.
> 
> After digging further, I have a theory that I'm having this issues because 
> I've
> only attached my DPDK application to SR-IOV ports. In
> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the
> DGLORT
> decoder. However, it appears that this is only invoked for physical functions.
> 
> Could this be my problem? Is it required that I bind to the physical function
> if I want to properly manipulate RSS?
> 
> Thanks,
> Mike
> 
I don't know exactly what problem you ran into. I think we needn't worry about 
those DGLORT setting when using VF device.

I've followed steps to use SRIOV device with RSS enabled and disabled, both
are worked well from my side after applying your patch. Below is my setup.

1. PF with Linux driver "fm10k-next_0.19.3".
2. DPDK with latest code from master branch, apply your patch.
3. Use 1 VF device created by kernel driver.
4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
--config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)""
with RSS enabled. After sending packets, I can see all 4 queues received 
packets.
5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 
--config="(0,0,2)""
with RSS disabled. After sending packets, I can see queue 0 received 
packets.

Can you explain what actual problem is?
We can talk offline.

[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring

[Xu, Qian Q]

Marc
I didn?t quite get your points, I observed that after applying this patchset, 
all intel nic can?t be started, maybe something wrong happened when you check 
the duplex/autoneg value for different NICs. If we want to merge the patchset 
in RC2, we need fix them. Maybe not an easy job in several days.


Thanks
Qian

From: marc.sune at gmail.com [mailto:marc.s...@gmail.com] On Behalf Of Marc
Sent: Thursday, March 24, 2016 4:54 AM
To: Xu, Qian Q
Cc: Thomas Monjalon; Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin; 
Richardson, Bruce; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API 
refactoring

Qian,

On 23 March 2016 at 02:18, Xu, Qian Q mailto:qian.q.xu 
at intel.com>> wrote:
We have tested with intel nic and found port can't be started for all 
nics:ixgbe/i40e/igb/bonding, see attached mail for more details. Please check 
and fix it.


Thanks
Qian

-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On 
Behalf Of Thomas Monjalon
Sent: Wednesday, March 23, 2016 3:59 AM
To: Ananyev, Konstantin; Lu, Wenzhuo; Zhang, Helin
Cc: marcdevel at gmail.com; Richardson, Bruce; 
dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API 
refactoring

2016-03-17 19:08, Thomas Monjalon:
> There are still too few tests and reviews, especially for
> autonegotiation with Intel devices (patch #6).
> I would not be surprised to see some bugs in this rework.

Any feedback about autoneg in e1000/ixgbe/i40e?
Has it been tested before its integration in RC2?

> The capabilities must be adapted per device. It can be improved in a
> separate patch.
>
> It will be integrated in 16.04-rc2.
> Please test and review shortly, thanks!


-- Forwarded message --
From: "Xu, Qian Q" mailto:qian.q...@intel.com>>
To: "Cao, Waterman" mailto:waterman.cao at 
intel.com>>, "Glynn, Michael J" mailto:michael.j.glynn at intel.com>>
Cc: "Richardson, Bruce" mailto:bruce.richardson 
at intel.com>>, "Zhu, Heqing" mailto:heqing.zhu at 
intel.com>>, "O'Driscoll, Tim" mailto:tim.odriscoll 
at intel.com>>, "Mcnamara, John" mailto:john.mcnamara at intel.com>>, "Xu, HuilongX" mailto:huilongx.xu at intel.com>>, "Fu, JingguoX" mailto:jingguox.fu at intel.com>>, "Xu, Qian Q" mailto:qian.q.xu at intel.com>>, "Zhang, Helin" mailto:helin.zhang at intel.com>>
Date: Tue, 22 Mar 2016 06:41:37 +
Subject: RE: DPDK link speed with Intel devices
Hi, all
We have worked out the basic test cases for the patchset.
1. Test the link speed on major Intel NICs to see if the speed is right.
2. Test the auto-negoation on major Intel NICs to ensure it's working.
Nic covered: ixgbe, igb, i40e, fm10k, bonding(SW), virtio(SW)

When we run the Test#1 for all major NICs. We found that all these NIC 
port(igb, ixgbe, i40e, fm10k) can't be started. Pls check, if the patch is 
applied, all INTEL port can't be start, terrible things!

Interactive-mode selected
Configuring Port 0 (socket 0)
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f13e99e3440 hw_ring=0x7f13e99e5480 
dma_addr=0x8299e5480
PMD: ixgbe_set_tx_function(): Using simple tx code path
PMD: ixgbe_set_tx_function(): Vector tx enabled.
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f13ffcb8080 
sw_sc_ring=0x7f13ffcbaac0 hw_ring=0x7f13e99d3380 dma_addr=0x8299d3380
PMD: ixgbe_dev_start(): Invalid link_speeds for port 0; autonegotiation disabled
Fail to start port 0
Configuring Port 1 (socket 0)
PMD: i40e_set_tx_function_flag(): Vector tx can be enabled on this txq.
PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are 
satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation disabled


Just to double-check; is the test#1 adapted to the _new_ API that ethdev has to 
set link speeds? For the output it seems autoneg is disabled => fixed speed, 
hence the new bitmaps have to be used.

(I am not claiming patchset is bug free; there might be issues still)

Regards
marc

Fail to start port 1
Please stop the ports first
Done

Thanks
Qian


-Original Message-
From: Cao, Waterman
Sent: Tuesday, March 22, 2016 11:06 AM
To: Glynn, Michael J
Cc: Richardson, Bruce; Zhu, Heqing; O'Driscoll, Tim; Mcnamara, John; Xu, Qian 
Q; Cao, Waterman
Subject: RE: DPDK link speed with Intel devices

Hi Mike,

We just knew this patch set last week.
Since this patch set is required to test with a lot of NIC,  we need 
more document from Dev about this patch.
Currently, Qian is working on with Wenzhuo on it now.

Waterman


-Original Message-
From: Glynn, Michael J
Sent: Tuesday, March 22, 2016 1:31 AM
To: Cao, Waterman mailto:waterman.cao at intel.com>>
Cc: Richardson, Bruce mailto:bruce.richardson at 
intel.com>>; Zhu, Heqing mailto:heqing.zhu at 
intel.com>>; O'Driscoll, Tim mailto:tim.odriscoll 
at intel.com>>; Mcnamara, John 

[dpdk-dev] testpmd could not start up with vmxnet3 port

[Yong Wang]

On 3/23/16, 8:55 AM, "Thomas Monjalon"  wrote:



>2016-03-23 05:57, Yong Wang:
>> From: Ding, HengX
>> > Testpmd will fail to start up with vmxnet3 port.
>[...]
>> Currently vmxnet3?s default_txconf.txq_flags is set to the following, which 
>> is used by testpmd
>> as there is no explicit txconf passed when initializing tx queue:
>> 
>> dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
>> ETH_TXQ_FLAGS_NOOFFLOADS;
>
>In vmxnet3_dev_tx_queue_setup:
>if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMS) !=
>ETH_TXQ_FLAGS_NOXSUMSCTP) {
>PMD_INIT_LOG(ERR, "SCTP checksum offload not supported");
>return -EINVAL;
>}
>It means we cannot disable TCP or UDP checksum offload.
>ETH_TXQ_FLAGS_NOXSUMS = NOXSUMSCTP + NOXSUMUDP + NOXSUMTCP
>
>I think it should be:
>if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMSCTP) !=
>ETH_TXQ_FLAGS_NOXSUMSCTP) {

I understand this. As I pointed out, such checks are not consistently
enforced as far as I can tell.  Other than Intel drivers, no other
drivers claim DEV_TX_OFFLOAD_SCTP_CKSUM but only vmxnet3 really
checks this. Also, what?s not clear to me is that why do we need
this negative check if we have rx_offload_capa and tx_offload_capa?


Anyway, I?ll send out a patch to fix this.

>
>> With the referred patch that introduced l4 cksum offload, we should update 
>> the default txq
>> flags check accordingly.  Heng, can you post the error logs to confirm this 
>> is indeed the cause
>> of the error you reported?
>
>The default conf is ETH_TXQ_FLAGS_NOOFFLOADS (= NOVLANOFFL + NOXSUMS).
>Yes you can update the default conf, *and* fix the check above.
>
>> Related to this, I saw that the check for NOMULTISEGS has been removed and 
>> the check for
>> NOVLANOFF was never implemented.  Should we just remove the offload flags 
>> check as well
>> as I don?t see much value of this check.  Basically we know that the device 
>> does not support
>> certain offload and we have to set those flags to let the device initialize. 
>> But doing this does
>> nothing to prevent users to request these non-supported offload.  I also saw 
>> another thread
>> discussing better device capability APIs and hopefully this will not be 
>> needed then
>
>These checks are important to throw an error if an offload is requested
>but not supported.

[dpdk-dev] [PATCH v3 00/10] qede: Add qede PMD

[Rasesh Mody]

Hi Bruce,

> From: Richardson, Bruce [mailto:bruce.richardson at intel.com]
> Sent: Tuesday, March 22, 2016 4:21 AM
> 
> I've had a quick scan over this patchset, and as you've probably seen I've
> made some public comments on it. General comments on the whole
> patchset are:
> * Please run checkpatch on the patchset and clear up as many issues as you
> can. There are a number of typos called out which especially must be fixed.
> Both myself and Thomas always run checkpatch against patches before
> applying them. [I suggest using Thomas's checkpatches.sh script to do the
> checks as it disables many unnecessary warnings from checkpatch]
> * Please put in commit descriptions for all patches bar those doing trivial
> things. The first three patches probably don't need a commit message, but
> the rest do.

 * We had run checkpatch script from dpdk on v1 submission, checkpatch.pl from 
3.15 kernel and had addressed all the check patch issues.
 * However, we got a recommendation "Running checkpatch with --ignore  
PREFER_KERNEL_TYPES,LINE_SPACING,PARENTHESIS_ALIGNMENT,BIT_MACRO,NETWORKING_BLOCK_COMMENT_STYLE,SPLIT_STRING,COMPARISON_TO_NULL,CONCATENATED_STRING".
 With v2 we used these ignore options with checkpatch.pl from 4.5 kernel and 
addressed checkpatch reported errors/warnings/checks. However, the spellcheck 
was missing from both the submissions.
 * With v3 there was no code change(meant for dpdk-next-net)

We'll address spellchecks and other issues that may have been additionally 
found by latest checkpatch scripts. We'll also add the commit message to make 
the patches descriptive and submit v4 patch set.

Thanks!
Rasesh 

> /Bruce
> 
> > -Original Message-
> > From: Rasesh Mody [mailto:rasesh.mody at qlogic.com]
> > Sent: Saturday, March 19, 2016 12:53 AM
> > To: thomas.monjalon at 6wind.com; Richardson, Bruce
> > 
> > Cc: dev at dpdk.org; ameen.rahman at qlogic.com; harish.patil at qlogic.com;
> > sony.chacko at qlogic.com; Rasesh Mody 
> > Subject: [PATCH v3 00/10] qede: Add qede PMD
> >
> > Submitting v3 patch series for QEDE PMD. There is no code change from
> > v2 series except PMD version change. Earlier we had generated and
> > tested the
> > v2 series against dpdk tree then latest.
> >
> > The v3 series includes:
> >  - Patches generated and tested against latest dpdk-next-net
> >  - Reworked MAINTAINERS patch to make it apply cleanly
> >  - Incorporated Overview.rst update in the documentation patch
> >
> > Please Apply.
> >
> > Thanks!
> > Rasesh
> >
> > Rasesh Mody (10):
> >   qede: Add maintainers
> >   qede: Add documentation
> >   qede: Add license file
> >   qede: Add base driver
> >   qede: Add core driver
> >   qede: Add L2 support
> >   qede: Add SRIOV support
> >   qede: Add attention support
> >   qede: Add DCBX support
> >   qede: Enable PMD build
> >
> >  MAINTAINERS |7 +
> >  config/common_base  |   14 +
> >  doc/guides/nics/index.rst   |1 +
> >  doc/guides/nics/overview.rst|   78 +-
> >  doc/guides/nics/qede.rst|  340 +
> >  drivers/net/Makefile|1 +
> >  drivers/net/qede/LICENSE.qede_pmd   |   28 +
> >  drivers/net/qede/Makefile   |   95 +
> >  drivers/net/qede/base/bcm_osal.c|  178 +
> >  drivers/net/qede/base/bcm_osal.h|  395 +
> >  drivers/net/qede/base/common_hsi.h  |  714 ++
> >  drivers/net/qede/base/ecore.h   |  746 ++
> >  drivers/net/qede/base/ecore_attn_values.h   |13287
> > +++
> >  drivers/net/qede/base/ecore_chain.h |  724 ++
> >  drivers/net/qede/base/ecore_cxt.c   | 1961 
> >  drivers/net/qede/base/ecore_cxt.h   |  157 +
> >  drivers/net/qede/base/ecore_cxt_api.h   |   79 +
> >  drivers/net/qede/base/ecore_dcbx.c  |  887 ++
> >  drivers/net/qede/base/ecore_dcbx.h  |   55 +
> >  drivers/net/qede/base/ecore_dcbx_api.h  |  160 +
> >  drivers/net/qede/base/ecore_dev.c   | 3578 
> >  drivers/net/qede/base/ecore_dev_api.h   |  497 +
> >  drivers/net/qede/base/ecore_gtt_reg_addr.h  |   42 +
> >  drivers/net/qede/base/ecore_gtt_values.h|   33 +
> >  drivers/net/qede/base/ecore_hsi_common.h| 1912 
> >  drivers/net/qede/base/ecore_hsi_eth.h   | 1912 
> >  drivers/net/qede/base/ecore_hsi_tools.h | 1081 +++
> >  drivers/net/qede/base/ecore_hw.c|  992 ++
> >  drivers/net/qede/base/ecore_hw.h|  269 +
> >  drivers/net/qede/base/ecore_hw_defs.h   |   49 +
> >  drivers/net/qede/base/ecore_init_fw_funcs.c | 1275 +++
> > drivers/net/qede/base/ecore_init_fw_funcs.h |  263 +
> >  drivers/net/qede/base/ecore_init_ops.c  |  599 ++
> >  drivers/net/qede/base/ecore_init_ops.h  |  103 +
> >  drivers/net/qede/base/ecore_int.c   | 2225 +
> >  drivers/net/qede/base/ecore_int.h   |  234 +
> >  

[dpdk-dev] [PATCH v2 2/7] drivers/net/e1000: Fix missing brackets

[Lu, Wenzhuo]

Hi Thomas, Aaron,
> > Wenzhuo, do you agree to fix the base driver here?
Honestly I find the logic has some problem and maybe more changes needed. I'm 
talking with our kernel driver contactors to make sure they have no concern 
about  my idea.
And Aaron, do we really need to fix this code? For I find this function is not 
called. So it has no real impact to us. Could we just wait until kernel driver 
fixes it and leverage the new version? Thanks.