[dpdk-dev] [PATCH] net/ixgbe: Wrong PCI ids for PMD_INFO_STRING.
The pci_id_ixgbe_map table has only PCI_ANY_ID for .subvend and .subdev in all
entries.
Using of IXGBE_SUBDEV_ID_82599_SFP for 'dev' is not correct.
It generates the wrong PMD_INFO_STRING. The output of the program
"dpdk-pmdinfo.py" is confusing.
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 194058fb8..9473a0fee 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -442,13 +442,8 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KX4_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KR) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_COMBO_BACKPLANE) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_CX4) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_RNDC) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_560FLR) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_ECNA_DP)
},
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_BACKPLANE_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_EM) },
--
2.13.0
Re: [dpdk-dev] [PATCH v4 00/12] Infrastructure to detect iova mapping on the bus
Hi Santosh, On 07/18/2017 07:59 AM, Santosh Shukla wrote: v4: Introducing RTE_PCI_DRV_IOVA_AS_VA flag for autodetection of iova va mapping. If a PCI driver demand for IOVA as VA scheme then the driver can add it in the PCI driver registration function. Algorithm to select IOVA as VA for PCI bus case: 0. If no device bound then return with RTE_IOVA_DC mapping mode, else goto 1). 1. Look for device attached to vfio kdrv and has .drv_flag set to RTE_PCI_DRV_IOVA_AS_VA. 2. Look for any device attached to UIO class of driver. 3. Check for vfio-noiommu mode enabled. If 2) & 3) is false and 1) is true then select mapping scheme as RTE_IOVA_VA. Otherwise use default mapping scheme (RTE_IOVA_PA). That way, Bus can truly autodetect the iova mapping mode for a device Or a set of the device. Patch series rebased on 'a599eb31f2e477674fc6176cdf989ee17432b552'. * Re-introduced RTE_IOVA_DC (Don't care mode) for no-device found case. (Identified by Hemant [5]). * Renamed flag from RTE_PCI_DRV_NEED_IOVA_VA to RTE_PCI_DRV_IOVA_AS_VA (Suggested by Maxime[6]). * Based on the discussion on the thread [3], [6] and [5]. v3 --> v4: - Re-introduced RTE_IOVA_DEC mode (Suggested by Hemant [5]). - Renamed flag to RTE_PCI_DRV_IOVA_AS_VA (Suggested by Maxime). - Reworded WARNING message(suggested by Maxime[7]). - Created a separate patch for rte_pci_get_iommu_class (suggested by Maxime[]). - Added VFIO_PRESENT ifdef build fix. v2 --> v3: - Removed rte_mempool_virt2phy (suggested by Olivier [4]) v1 --> v2: - Removed override eal option i.e. (--iova-mode=<>) Because we have means to truly autodetect the iova mode. - Introduced RTE_PCI_DRV_NEED_IOVA_VA drv_flag (Suggested by Maxime [3]). - Using NEED_IOVA_VA drv_flag in autodetection logic. - Removed Linux version check macro in vfio code, As per Maxime feedback. - Moved rte_pci_match API from local to global. Patch Summary: 0) 1st: Introducing a new flag in rte_pci_drv 1) 2nd: declare rte_pci_match api in pci header. Required for autodetection in follow up patches. 2) 3rd: declare rte_pci_get_iommu_class. 3) 4nd - 5th: autodetection mapping infrastructure for Linux/bsdapp. 4) 6th: Introduces global bus API named rte_bus_get_iommu_class. 5) 7th: iova mode helper API. 6) 8th - 9th: Calls rte_bus_get_iommu_class API for Linux/bsdapp and returns their iova mode. 7) 10th: Check iova mode and accordingly map vfio.dma_map to _pa or _va. 8) 11th - 12th: Check for IOVA_VA mode in below APIs - rte_mem_virt2phy - rte_malloc_virt2phy Test History: - Tested for x86/XL710 40G NIC card for both modes (iova_va/pa). - Tested for arm64/thunderx vNIC Integrated NIC for both modes - Tested for arm64/Octeontx integrated NICs for only Iova_va mode(It supports only one mode.) - Ran standalone tests like mempool_autotest, mbuf_autotest. - Verified for Doxygen. Work History: For v1, Refer [1]. For v2, Refer [2]. For v3, Refer [9]. Checkpatch result: * Debug message - WARNING: line over 80 characters Thanks., [1] https://www.mail-archive.com/dev@dpdk.org/msg67438.html [2] https://www.mail-archive.com/dev@dpdk.org/msg70674.html [3] https://www.mail-archive.com/dev@dpdk.org/msg70279.html [4] https://www.mail-archive.com/dev@dpdk.org/msg70692.html [5] http://dpdk.org/ml/archives/dev/2017-July/071282.html [6] http://dpdk.org/ml/archives/dev/2017-July/070951.html [7] http://dpdk.org/ml/archives/dev/2017-July/070941.html [8] http://dpdk.org/ml/archives/dev/2017-July/070952.html [9] http://dpdk.org/ml/archives/dev/2017-July/070918.html Santosh Shukla (12): eal/pci: introduce PCI driver iova as va flag eal/pci: export match function eal/pci: get iommu class bsdapp/eal_pci: get iommu class linuxapp/eal_pci: get iommu class bus: get iommu class eal: introduce iova mode helper api linuxapp/eal: auto detect iova mode bsdapp/eal: auto detect iova mapping mode linuxapp/eal_vfio: honor iova mode before mapping linuxapp/eal_memory: honor iova mode in virt2phy eal/rte_malloc: honor iova mode in virt2phy lib/librte_eal/bsdapp/eal/eal.c | 21 -- lib/librte_eal/bsdapp/eal/eal_pci.c | 10 +++ lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 ++ lib/librte_eal/common/eal_common_bus.c | 23 ++ lib/librte_eal/common/eal_common_pci.c | 11 +-- lib/librte_eal/common/include/rte_bus.h | 32 + lib/librte_eal/common/include/rte_eal.h | 12 lib/librte_eal/common/include/rte_pci.h | 28 lib/librte_eal/common/rte_malloc.c | 9 ++- lib/librte_eal/linuxapp/eal/eal.c | 21 -- lib/librte_eal/linuxapp/eal/eal_memory.c| 3 + lib/librte_eal/linuxapp/eal/eal_pci.c | 95 + lib/librte_eal/linuxapp/eal/eal_vfio.c | 29 +++- lib/librte_eal/linuxapp/eal/eal_vfio.h | 4 ++ lib/librte_eal/linuxapp/eal/rte_eal_
[dpdk-dev] [PATCH] net/ixgbe: Wrong PCI ids for PMD_INFO_STRING.
The pci_id_ixgbe_map table has only PCI_ANY_ID for
.subvend and .subdev in all entries. Using of IXGBE_SUBDEV_ID_82599_SFP
for 'dev' is not correct. It generates the wrong PMD_INFO_STRING.
The output of the program "dpdk-pmdinfo.py" is confusing.
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 194058fb8..9473a0fee 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -442,13 +442,8 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KX4_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KR) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_COMBO_BACKPLANE) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_CX4) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_RNDC) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_560FLR) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_ECNA_DP)
},
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_BACKPLANE_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_EM) },
--
2.13.0
[dpdk-dev] [PATCH] net/ixgbe: Wrong PCI ids for PMD_INFO_STRING.
The pci_id_ixgbe_map table has only PCI_ANY_ID for
.subvend and .subdev in all entries. Using of IXGBE_SUBDEV_ID_82599_SFP
for 'dev' is not correct. It generates the wrong PMD_INFO_STRING.
The output of the program "dpdk-pmdinfo.py" is confusing.
Signed-off-by: Leonid Myravjev
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 194058fb8..9473a0fee 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -442,13 +442,8 @@ static const struct rte_pci_id pci_id_ixgbe_map[] = {
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KX4_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_KR) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_COMBO_BACKPLANE) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_CX4) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_SFP) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_RNDC) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_560FLR) },
- { RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_SUBDEV_ID_82599_ECNA_DP)
},
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID,
IXGBE_DEV_ID_82599_BACKPLANE_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_FCOE) },
{ RTE_PCI_DEVICE(IXGBE_INTEL_VENDOR_ID, IXGBE_DEV_ID_82599_SFP_EM) },
--
2.13.0
Re: [dpdk-dev] [dpdk-stable] [PATCH v2] net/i40e: fix link down and negotiation issue
On 7/21/2017 4:07 AM, Jeff Guo wrote:
> Enable the functions set link down and set link up in i40e by check
> phy_type, and fix the issue of auto negotiation failed in XXV710 when
> bind kernel driver after unbind from dpdk driver by modify the speed
> setting distinguish from set link up and down. With this fix, if unbind
> dpdk to bind kernel driver, no need to set auto negotiation and ifconfi
> up anymore, remove the part from doc.
>
> Fixes: ca7e599d4506 ("net/i40e: fix link management")
> Fixes: 2f1e22817420 ("i40e: skip link control as firmware workaround")
> Fixes: 6e145fcc754b ("i40e: support autoneg or force link speed")
Cc: sta...@dpdk.org
> Signed-off-by: Jeff Guo
Applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH] pci: limit default numa node to used devices
Commit 8a04cb612589 ("pci: set default numa node for broken systems")
added logic to default to NUMA node 0 when sysfs numa_node information
was wrong or not available.
Unfortunately there are many devices with wrong NUMA node information
that DPDK does not care about but still show warnings for them.
Instead, only check for invalid NUMA node information for devices
managed by the DPDK.
Signed-off-by: Sergio Gonzalez Monroy
---
lib/librte_eal/common/eal_common_pci.c | 5 +
lib/librte_eal/linuxapp/eal/eal_pci.c | 11 +++
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index eaa041e..52fd38c 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -226,6 +226,11 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
return 1;
}
+ if (dev->device.numa_node < 0) {
+ RTE_LOG(WARNING, EAL, " Invalid NUMA socket, default to 0\n");
+ dev->device.numa_node = 0;
+ }
+
RTE_LOG(INFO, EAL, " probe driver: %x:%x %s\n", dev->id.vendor_id,
dev->id.device_id, dr->driver.name);
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 556ae2c..2041d5f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -314,15 +314,10 @@ pci_scan_one(const char *dirname, const struct
rte_pci_addr *addr)
snprintf(filename, sizeof(filename), "%s/numa_node",
dirname);
- if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
- tmp < RTE_MAX_NUMA_NODES)
+ if (eal_parse_sysfs_value(filename, &tmp) == 0)
dev->device.numa_node = tmp;
- else {
- RTE_LOG(WARNING, EAL,
- "numa_node is invalid or not present. "
- "Set it 0 as default\n");
- dev->device.numa_node = 0;
- }
+ else
+ dev->device.numa_node = -1;
pci_name_set(dev);
--
2.9.4
Re: [dpdk-dev] [PATCH v2 0/8] bnxt patchset
On 7/21/2017 4:22 AM, Ajit Khaparde wrote: > This patch set fixes some of the issues found during testing. > Please apply. > > v1->v2: incorporate review feedback > > net/bnxt: fix log levels for non error conditions. > net/bnxt: fix to avoid a segfault > net/bnxt: fix vnic cleanup > net/bnxt: fix set link config > net/bnxt: reset VF stats during initialization > net/bnxt: fix VLAN antispoof configuration code > net/bnxt: check invalid l2_filter_id > net/bnxt: fix to free a filter before reusing it Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/ixgbe: fix mirror rule index overflow
On 7/21/2017 9:56 AM, Qi Zhang wrote:
> Mirror rule id should not exceed the boundary defined by
> IXGBE_MAX_MIRROR_RULES.
>
> Fixes: fe3a45fd4104 ("ixgbe: add VMDq support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/ixgbe: fix mirror rule index overflow
On 7/21/2017 9:56 AM, Qi Zhang wrote:
> Mirror rule id should not exceed the boundary defined by
> IXGBE_MAX_MIRROR_RULES.
>
> Fixes: fe3a45fd4104 ("ixgbe: add VMDq support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/ixgbe: add support for ipv4-other type filter
On 7/20/2017 8:25 AM, Wei Zhao wrote: > add support for ipv4-other type in ntuple filter. > > Signed-off-by: Wei Zhao Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/ixgbe: Wrong PCI ids for PMD_INFO_STRING.
On 7/21/2017 12:25 PM, Leonid Myravjev wrote: > The pci_id_ixgbe_map table has only PCI_ANY_ID for > .subvend and .subdev in all entries. Using of IXGBE_SUBDEV_ID_82599_SFP > for 'dev' is not correct. It generates the wrong PMD_INFO_STRING. > The output of the program "dpdk-pmdinfo.py" is confusing. > > Signed-off-by: Leonid Myravjev Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] Rx Can't receive anymore packet after received 1.5 billion packet.
- Original Message - From: "cristian dumitrescu" To: vuon...@viettel.com.vn Cc: us...@dpdk.org, dev@dpdk.org Sent: Thursday, July 20, 2017 1:43:37 AM Subject: RE: [dpdk-dev] Rx Can't receive anymore packet after received 1.5 billion packet. > -Original Message- > From: vuon...@viettel.com.vn [mailto:vuon...@viettel.com.vn] > Sent: Tuesday, July 18, 2017 2:37 AM > To: Dumitrescu, Cristian > Cc: us...@dpdk.org; dev@dpdk.org > Subject: Re: [dpdk-dev] Rx Can't receive anymore packet after received 1.5 > billion packet. > > > > On 07/17/2017 05:31 PM, cristian.dumitre...@intel.com wrote: > > > >> -Original Message- > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of > >> vuon...@viettel.com.vn > >> Sent: Monday, July 17, 2017 3:04 AM > >> Cc: us...@dpdk.org; dev@dpdk.org > >> Subject: [dpdk-dev] Rx Can't receive anymore packet after received 1.5 > >> billion packet. > >> > >> Hi DPDK team, > >> Sorry when I send this email to both of group users and dev. But I have > >> big problem: Rx core on my application can not receive anymore packet > >> after I did the stress test to it (~1 day Rx core received ~ 1.5 billion > >> packet). Rx core still alive but didn't receive any packet and didn't > >> generate any log. Below is my system configuration: > >> - OS: CentOS 7 > >> - Kernel: 3.10.0-514.16.1.el7.x86_64 > >> - Huge page: 32G: 16384 page 2M > >> - NIC card: Intel 85299 > >> - DPDK version: 16.11 > >> - Architecture: Rx (lcore 1) received packet then queue to the ring > >> - Worker (lcore 2) dequeue packet in the ring and free it (use > >> rte_pktmbuf_free() function). > >> - Mempool create: rte_pktmbuf_pool_create ( > >>"rx_pool", /* > >> name */ > >>8192, /* > >> number of elemements in the mbuf pool */ > >> 256,/* Size of per-core > >> object cache */ > >> 0, /* Size of > >> application private are between rte_mbuf struct and data buffer */ > >>RTE_MBUF_DEFAULT_BUF_SIZE, /* > >> Size of data buffer in each mbuf (2048 + 128)*/ > >> 0 /* socket id */ > >> ); > >> If I change "number of elemements in the mbuf pool" from 8192 to 512, > Rx > >> have same problem after shorter time (~ 30s). > >> > >> Please tell me if you need more information. I am looking forward to > >> hearing from you. > >> > >> > >> Many thanks, > >> Vuong Le > > Hi Vuong, > > > > This is likely to be a buffer leakage problem. You might have a path in your > code where you are not freeing a buffer and therefore this buffer gets > "lost", as the application is not able to use this buffer any more since it > is not > returned back to the pool, so the pool of free buffers shrinks over time up to > the moment when it eventually becomes empty, so no more packets can be > received. > > > > You might want to periodically monitor the numbers of free buffers in your > pool; if this is the root cause, then you should be able to see this number > constantly decreasing until it becomes flat zero, otherwise you should be > able to the number of free buffers oscillating around an equilibrium point. > > > > Since it takes a relatively big number of packets to get to this issue, it > > is > likely that the code path that has this problem is not executed very > frequently: it might be a control plane packet that is not freed up, or an ARP > request/reply pkt, etc. > > > > Regards, > > Cristian > Hi Cristian, > Thanks for your response, I am doing your ideal. But let me show you > another case i have tested before. I changed architecture of my > application as below: > - Architecture: Rx (lcore 1) received packet then queue to the ring > - after that: Rx (lcore 1) dequeue packet in the ring and free it > immediately. > (old architecture as above) > With new architecture Rx still receive packet after 2 day and everything > look good. Unfortunately, My application must run in old architecture. > > Any ideal for me? > > > Many thanks, > Vuong Le I am not sure I understand the old architecture and the new architecture you are referring to, can you please clarify them. Regards, Cristian Hi Cristain, I have found my problem, It caused by I created mempool in socket 1 while I created ring in socket 0 (I have not set huge page for socket 0). This is my stupid mistake. But I don't understand why rings still created by system in socket 0 where I didn't set huge page before. Thanks for your support. Many thanks, Vuong Le
Re: [dpdk-dev] [PATCH] net/ixgbe: Wrong PCI ids for PMD_INFO_STRING.
On 7/21/2017 11:29 AM, Ferruh Yigit wrote: > On 7/21/2017 12:25 PM, Leonid Myravjev wrote: >> The pci_id_ixgbe_map table has only PCI_ANY_ID for >> .subvend and .subdev in all entries. Using of IXGBE_SUBDEV_ID_82599_SFP >> for 'dev' is not correct. It generates the wrong PMD_INFO_STRING. >> The output of the program "dpdk-pmdinfo.py" is confusing. >> >> Signed-off-by: Leonid Myravjev > > Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] eal: disable NUMA related warnings on non-NUMA systems
On 7/21/2017 11:31 AM, Thomas Monjalon wrote: 13/07/2017 13:28, Hemant Agrawal: Disabling NUMA warnings on non-NUMA systems. "EAL: eal_parse_sysfs_value(): cannot open sysfs value /sys/bus/pci/devices/:00:00.0/numa_node EAL: numa_node is invalid or not present. Set it 0 as default EAL: cannot open /proc/self/numa_maps, consider that all memory is in socket_id 0" Signed-off-by: Hemant Agrawal If I understand well, you are disabling every warnings when DPDK is compiled without libnuma. I think we should keep one warning in case libnuma is not available but it is running on a NUMA system. What about adding this kind of sysfs check? #ifndef RTE_EAL_NUMA_AWARE_HUGEPAGES if (sysfs/numa_node is present) RTE_LOG(WARN, "Only the first NUMA node will be used\n"); #endif Good suggestion. I will rework the patch.
[dpdk-dev] query: NIC firmware upgrade
Hi I am having 2 VMs on my host. VM1 is running my application with dpdk2.2.0 without any issues and i am using VM2 for dpdk17.05 for the same application. But newer version of dpdk (dpdk 17.05 ) needs NIC's firmware upgrade for SR-IOV Nics. If i upgrade firmware, will it create any trouble for VM1(which is running without any issues) or firmware upgrade will have the backward compatibility? NIC: Physical nic Intel X710/XL710 10GbE SFP+ current version:1.3.45 latest version:1.4.28 Host:VMware 5.5.0 and Please let me know what all the things i have to consider before going for NIC firmware upgrade. -- Thanks Sakthivel S OM
Re: [dpdk-dev] [PATCH v2] examples/load_balancer: enable the build for lesser lcores
19/07/2017 11:19, Hemant Agrawal: > load_balancer app can also work for lower number of cores. > Limit the cores Worker and IO cores to 16 as defined in original > App. Otherwise use the actual number of lcores as MAX. > > Signed-off-by: Hemant Agrawal > --- > v2: Revert back the condition check Applied, thanks
Re: [dpdk-dev] [PATCH v3] examples/qos_sched: fix core limit for lower num of lcore
19/07/2017 11:13, Hemant Agrawal:
> APP_MAX_LCORES is hardcoded as 64.
> This will cause build err when RTE_MAX_LCORE is less then 64.
>
> "args.c:127:22: error: iteration 8 invokes undefined behavior
> [-Werror=aggressive-loop-optimizations]
>if (cfg->lcore_role[i] == ROLE_RTE)
>~~~^~~
> args.c:126:2: note: within this loop
> for (i = 0; i < APP_MAX_LCORE; i++) {"
>
> Fixes: d52b5e735aa3 ("examples/qos_sched: fix lcore limit")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Hemant Agrawal
> ---
> v3: fix as per review comment of Thomas
Applied, thanks
[dpdk-dev] [PATCH v1] net/i40e: fix sync phy type by adding retry
Some phy's take longer than others to come up. Add a retry to give
more phy's a chance to come up before returning an error.
Signed-off-by: David Hunt
---
drivers/net/i40e/i40e_ethdev.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 97a73e1..8c39eb7 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -9248,16 +9248,22 @@ i40e_dev_sync_phy_type(struct i40e_hw *hw)
enum i40e_status_code status;
struct i40e_aq_get_phy_abilities_resp phy_ab;
int ret = -ENOTSUP;
+ int retries = 0;
status = i40e_aq_get_phy_capabilities(hw, false, true, &phy_ab,
NULL);
- if (status) {
+ while (status) {
PMD_INIT_LOG(WARNING, "Failed to sync phy type: status=%d",
status);
- return ret;
+ retries++;
+ rte_delay_us(10);
+ if (retries < 5)
+ status = i40e_aq_get_phy_capabilities(hw, false,
+ true, &phy_ab, NULL);
+ else
+ return ret;
}
-
return 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
The title and the text below should explain that you move
the warning log from scan to probe, thanks to a temporary
negative value.
21/07/2017 12:11, Sergio Gonzalez Monroy:
> Commit 8a04cb612589 ("pci: set default numa node for broken systems")
> added logic to default to NUMA node 0 when sysfs numa_node information
> was wrong or not available.
>
> Unfortunately there are many devices with wrong NUMA node information
> that DPDK does not care about but still show warnings for them.
>
> Instead, only check for invalid NUMA node information for devices
> managed by the DPDK.
>
> Signed-off-by: Sergio Gonzalez Monroy
[...]
> - if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
> - tmp < RTE_MAX_NUMA_NODES)
> + if (eal_parse_sysfs_value(filename, &tmp) == 0)
> dev->device.numa_node = tmp;
Why are you removing the check of the value?
Are you going to accept invalid high values?
This check was introduced on purpose by this commit:
http://dpdk.org/commit/8a04cb6125
Re: [dpdk-dev] [PATCH v2 6/8] mbuf: use 2 bytes for port andnbsegments
On Wed, Jul 12, 2017 at 06:23:38PM +0200, Thomas Monjalon wrote: > 12/07/2017 17:57, Morten Brørup: > > From: Stephen Hemminger > > > Morten Brørup wrote: > > > > From: Yang, Zhiyong [mailto:zhiyong.y...@intel.com] > > > > > From: Morten Brørup > > > > > > From: Wiles, Keith > > > > > > > > On Jul 11, 2017, at 10:23 AM, Morten Brørup wrote: > > > > > > > > From: Thomas Monjalon > > > > > > > >> 11/07/2017 15:30, Morten Brørup: > > > > > > > >>> Morten Brørup wrote: > > > > > > > Olivier Matz wrote: > > > > > > > > As I said in a previous message, I think a good first > > > > > > > > step would be to introduce a typedef for the port > > > > > > > > number: rte_eth_port_num_t. > > > > > > > > It can still be uint8_t for now, and can be switched > > > > > > > > to 16 bits in one step when everyone uses this new type. > > > > > > > > > > > > > > I think that DPDK follows the Linux tradition of exposing > > > > > > > the variable types, as opposed to hiding them behind > > > > > > > typedefs. This has the unfortunate consequence that > > > > > > > when a variable type changes, it has to be changed > > > > > > > everywhere. > > > > > > > > > > > > > > Introducing a rte_eth_port_num_t will require changing the > > > > > > > same files at the same locations everywhere, so not even as a > > > > > > > temporary solution will it be beneficial. > > > > > > > >> [...] > > > > > > > >>> What I was trying to communicate with my long argument > > > > > > > >>> about type definitions was: > > > > > > > >>> When the type changed from 8 bit to 16 bit, the type > > > > > > > >>> needs to change from uint8_t to uint16_t everywhere too, > > > > > > > >>> including in the ethdev APIs. > > > > > > > >>> > > > > > > > >>> Don't start breaking coding conventions here by hiding the > > > > > > > >>> type of this variable. > > > > > > > >> > > > > > > > >> So, Morten, you are against the typedef, right? > > > > > > > >> Because we need to change it everywhere anyway, right? > > > > > > > >> > > > > > > > >> Note: I have no strong opinion. > > > > > > > > > > > > > > > > I'm against the typedef because it would break convention, > > > > > > > > and I'm a strong proponent of conventions. > > > > > > > > In other projects, I'm all for typedefs, virtual classes, > > > > > > > > inheritance etc., but DPDK follows the Linux convention > > > > > > > > of not hiding simple types. > > > > > > > > > > > > > > > > We need to change it from uint8_t everywhere, regardless what > > > > > > > > we change it to. (But if we need to change it again sometime > > > > > > > > in the future, then a typedef will save us next time.) > > > > > > > > > > > > > > If the number of ports go beyond 64K then I will be the first > > > > > > > one (if still alive) to eat this email. :-) The only reason to > > > > > > > have more then 2 bytes would be to encode something into the > > > > > > > port id value, which I could see, but a very slim chance IMHO. > > > > > > > > > > > > > > > My preference: Follow convention and change it to uint16_t > > > > > > > > everywhere. > > > > > > > > > > > > > > As we must change the uint8_t to uint16_t, then I would like it > > > > > > > to be more descriptive via a typedef. I really do not see us > > > > > > > needing to change it again in the near future. > > > > > > > The only reason to make it a typedef is to be able to identify > > > > > > > from just the prototype of the function that it takes a port > > > > > > > ID value, which I am in favor of doing here for that reason. > > > > > > > > > > > > That is not a very good reason: When used as a function > > > > > > parameter, the type is only shown in the function declaration, > > > > > > whereas the variable name is shown every time it is used inside > > > > > > the function. > > > > > > So remember to always use meaningful variable names, such as > > > > > > "port" (like in the mbuf structure) or "port_id" (used in other > > > > > > places). > > > > > > > > > > > > I still don't support typedefs for scalar types. I consider it > > > > > > against the coding style, although after reviewing the official > > > > > > DPDK Coding Style documentation > > > > > > (http://dpdk.org/doc/guides/contributing/coding_style.html), > > > > > > I can see that it is not explicitly stated. Please also note > > > > > > that section 1.5.7 of the DPDK Coding Style documentation says > > > > > > that the _t postfix should be avoided. Anyway, if we end up > > > > > > with a typedef, please don't use something resembling pid_t > > > > > > known from POSIX > > > > > > (https://www.gnu.org/software/libc/manual/html_node/Process- > > > > > > Identification.html). > > > > > > > > > > How about rte_dev_id_t? > > > > > > > > If the DPDK Coding Style is based on Linux Coding Style, we should > > > > avoid typedefs in general, not just for structures. Please read Linus > > > > Torvalds' opinions about it: > > > > http://yarchive.n
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
On 21/07/2017 15:53, Thomas Monjalon wrote:
The title and the text below should explain that you move
the warning log from scan to probe, thanks to a temporary
negative value.
I thought that saying that I only check for devices managed by dpdk
explains the purpose,
and the patch itself shows the change from one file to another.
21/07/2017 12:11, Sergio Gonzalez Monroy:
Commit 8a04cb612589 ("pci: set default numa node for broken systems")
added logic to default to NUMA node 0 when sysfs numa_node information
was wrong or not available.
Unfortunately there are many devices with wrong NUMA node information
that DPDK does not care about but still show warnings for them.
Instead, only check for invalid NUMA node information for devices
managed by the DPDK.
Signed-off-by: Sergio Gonzalez Monroy
[...]
- if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
- tmp < RTE_MAX_NUMA_NODES)
+ if (eal_parse_sysfs_value(filename, &tmp) == 0)
dev->device.numa_node = tmp;
Why are you removing the check of the value?
Are you going to accept invalid high values?
This check was introduced on purpose by this commit:
http://dpdk.org/commit/8a04cb6125
tmp is unsigned long type, so -1 is going to be a large number.
My understanding was that it was basically checking for -1 as numa_node.
If we have valid numa_node greater than RTE_MAX_NUMA_NODES, defaulting
to 0 is not a good idea, is it?
What I try to achieve with the patch is:
- if no numa_node avilable then parse is going to fail and we set -1.
- if numa_node is present but wrong, my understanding was that it would
be -1.
Thanks,
Sergio
Re: [dpdk-dev] [PATCH] lib/gro: fix doxygen comment issue
11/07/2017 09:18, Jiayu Hu: > This patch updates GRO API comments to generate correct > API documentation by doxygen. > > Signed-off-by: Jiayu Hu Applied with the small fix below, thanks For rte_gro_timeout_flush: - * @param nb_out + * @param max_nb_out
Re: [dpdk-dev] [PATCH] doc: update programmer's guide for the GRO library
11/07/2017 06:27, Jiayu Hu: > Add description to programmer's guide to explain the > design of the GRO library. > > Signed-off-by: Jiayu Hu > --- > MAINTAINERS| 1 + > .../prog_guide/generic_receive_offload_lib.rst | 163 > + > doc/guides/prog_guide/index.rst| 1 + > doc/guides/prog_guide/source_org.rst | 1 + > 4 files changed, 166 insertions(+) > create mode 100644 doc/guides/prog_guide/generic_receive_offload_lib.rst Looking for a reviewer of this new doc. Any volunteer? > --- a/doc/guides/prog_guide/source_org.rst > +++ b/doc/guides/prog_guide/source_org.rst > @@ -68,6 +68,7 @@ The lib directory contains:: > +-- librte_distributor # Packet distributor > +-- librte_eal # Environment abstraction layer > +-- librte_ether# Generic interface to poll mode driver > ++-- librte_gro # Generic receive offload library > +-- librte_hash # Hash library > +-- librte_ip_frag # IP fragmentation library > +-- librte_kni # Kernel NIC interface I really want we remove this file. It is useless and not well maintained.
Re: [dpdk-dev] [PATCH] net/mlx5: poll completion queue once per a call
On Thu, Jul 20, 2017 at 07:34:04PM +0300, Sagi Grimberg wrote: > > > mlx5_tx_complete() polls completion queue multiple times until it > > encounters an invalid entry. As Tx completions are suppressed by > > MLX5_TX_COMP_THRESH, it is waste of cycles to expect multiple completions > > in a poll. And freeing too many buffers in a call can cause high jitter. > > This patch improves throughput a little. > > What if the device generates burst of completions? mlx5 PMD suppresses completions anyway. It requests a completion per every MLX5_TX_COMP_THRESH Tx mbufs, not every single mbuf. So, the size of completion queue is even much small. > Holding these completions un-reaped can theoretically cause resource stress on > the corresponding mempool(s). Can you make your point clearer? Do you think the "stress" can impact performance? I think stress doesn't matter unless it is depleted. And app is responsible for supplying enough mbufs considering the depth of all queues (max # of outstanding mbufs). > I totally get the need for a stopping condition, but is "loop once" > the best stop condition? Best for what? > Perhaps an adaptive budget (based on online stats) perform better? Please bring up any suggestion or submit a patch if any. Does "budget" mean the threshold? If so, calculation of stats for adaptive threshold can impact single core performance. With multiple cores, adjusting threshold doesn't affect much. Thanks, Yongseok
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
21/07/2017 18:03, Sergio Gonzalez Monroy:
> On 21/07/2017 15:53, Thomas Monjalon wrote:
> > The title and the text below should explain that you move
> > the warning log from scan to probe, thanks to a temporary
> > negative value.
>
> I thought that saying that I only check for devices managed by dpdk
> explains the purpose,
> and the patch itself shows the change from one file to another.
It is obvious when you look carefully at the code, yes.
I was just giving my help to better explain :)
>
> > 21/07/2017 12:11, Sergio Gonzalez Monroy:
> >> Commit 8a04cb612589 ("pci: set default numa node for broken systems")
> >> added logic to default to NUMA node 0 when sysfs numa_node information
> >> was wrong or not available.
> >>
> >> Unfortunately there are many devices with wrong NUMA node information
> >> that DPDK does not care about but still show warnings for them.
> >>
> >> Instead, only check for invalid NUMA node information for devices
> >> managed by the DPDK.
> >>
> >> Signed-off-by: Sergio Gonzalez Monroy
> > [...]
> >> - if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
> >> - tmp < RTE_MAX_NUMA_NODES)
> >> + if (eal_parse_sysfs_value(filename, &tmp) == 0)
> >>dev->device.numa_node = tmp;
> >
> > Why are you removing the check of the value?
> > Are you going to accept invalid high values?
> > This check was introduced on purpose by this commit:
> > http://dpdk.org/commit/8a04cb6125
>
> tmp is unsigned long type, so -1 is going to be a large number.
Oh yes, I missed it was unsigned!
> My understanding was that it was basically checking for -1 as numa_node.
>
> If we have valid numa_node greater than RTE_MAX_NUMA_NODES, defaulting
> to 0 is not a good idea, is it?
>
> What I try to achieve with the patch is:
> - if no numa_node avilable then parse is going to fail and we set -1.
> - if numa_node is present but wrong, my understanding was that it would
> be -1.
All your explanations make sense when you realize that it is unsigned.
I have one more question,
Does it work to check for a negative value like this?
if (dev->device.numa_node < 0)
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
On 21/07/2017 16:37, Thomas Monjalon wrote:
21/07/2017 18:03, Sergio Gonzalez Monroy:
On 21/07/2017 15:53, Thomas Monjalon wrote:
The title and the text below should explain that you move
the warning log from scan to probe, thanks to a temporary
negative value.
I thought that saying that I only check for devices managed by dpdk
explains the purpose,
and the patch itself shows the change from one file to another.
It is obvious when you look carefully at the code, yes.
I was just giving my help to better explain :)
Just giving my view of the commit message
If you think it can be improve,by all meansfeel free to change it :)
21/07/2017 12:11, Sergio Gonzalez Monroy:
Commit 8a04cb612589 ("pci: set default numa node for broken systems")
added logic to default to NUMA node 0 when sysfs numa_node information
was wrong or not available.
Unfortunately there are many devices with wrong NUMA node information
that DPDK does not care about but still show warnings for them.
Instead, only check for invalid NUMA node information for devices
managed by the DPDK.
Signed-off-by: Sergio Gonzalez Monroy
[...]
- if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
- tmp < RTE_MAX_NUMA_NODES)
+ if (eal_parse_sysfs_value(filename, &tmp) == 0)
dev->device.numa_node = tmp;
Why are you removing the check of the value?
Are you going to accept invalid high values?
This check was introduced on purpose by this commit:
http://dpdk.org/commit/8a04cb6125
tmp is unsigned long type, so -1 is going to be a large number.
Oh yes, I missed it was unsigned!
My understanding was that it was basically checking for -1 as numa_node.
If we have valid numa_node greater than RTE_MAX_NUMA_NODES, defaulting
to 0 is not a good idea, is it?
What I try to achieve with the patch is:
- if no numa_node avilable then parse is going to fail and we set -1.
- if numa_node is present but wrong, my understanding was that it would
be -1.
All your explanations make sense when you realize that it is unsigned.
I have one more question,
Does it work to check for a negative value like this?
if (dev->device.numa_node < 0)
numa_node is signed int type in struct rte_device, so it should work.
Regards,
Sergio
Re: [dpdk-dev] [PATCH 00/18] Increase minimum requirements for x86 platforms
On Tue, Jul 04, 2017 at 02:42:24PM +0200, Thomas Monjalon wrote: > > > Bruce Richardson (18): > > > mk: require SSE4.2 support on all x86 platforms > > > acl: remove checks for SSE4 > > > distributor: remove checks for SSE4 > > > eal: remove unneeded conditionals for SSE headers > > > hash: remove checks for SSE4 > > > ip_frag: check for x86 rather than SSE4 > > > net: remove check for SSE4 > > > sched: remove check for SSE4 > > > crypto/aesni_mb: remove check for SSE4 > > > crypto/kasumi: remove check for SSE4 > > > crypto/snow3g: remove check for SSE4 > > > crypto/zuc: remove check for SSE4 > > > net/enic: replace check for SSE4 with check for x86 > > > net/i40e: remove checks for SSE4 > > > net/ixgbe: remove fallback code for non-SSE4 systems > > > examples/ip_pipeline: remove macro check for SSE4 > > > examples/l3fwd: remove checks for SSE4 > > > examples/performance-thread: remove non-SSE4 fallbacks > > > > Acked-by: Konstantin Ananyev > > Applied and rebased with additions (in this thread), thanks. Thanks for fixing the couple of things I missed!
Re: [dpdk-dev] [PATCH] doc: notify callback process API change
12/07/2017 12:25, Bernard Iremonger: > The _rte_eth_dev_callback_process function has been modified. > The return value has been changed form void to int and an > extra parameter "void *ret_param" has been added. > > Signed-off-by: Bernard Iremonger Applied, thanks
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
21/07/2017 18:47, Sergio Gonzalez Monroy:
> On 21/07/2017 16:37, Thomas Monjalon wrote:
> > 21/07/2017 18:03, Sergio Gonzalez Monroy:
> >> On 21/07/2017 15:53, Thomas Monjalon wrote:
> >>> The title and the text below should explain that you move
> >>> the warning log from scan to probe, thanks to a temporary
> >>> negative value.
> >> I thought that saying that I only check for devices managed by dpdk
> >> explains the purpose,
> >> and the patch itself shows the change from one file to another.
> > It is obvious when you look carefully at the code, yes.
> > I was just giving my help to better explain :)
>
> Just giving my view of the commit message
> If you think it can be improve,by all meansfeel free to change it :)
>
> >>> 21/07/2017 12:11, Sergio Gonzalez Monroy:
> Commit 8a04cb612589 ("pci: set default numa node for broken systems")
> added logic to default to NUMA node 0 when sysfs numa_node information
> was wrong or not available.
>
> Unfortunately there are many devices with wrong NUMA node information
> that DPDK does not care about but still show warnings for them.
>
> Instead, only check for invalid NUMA node information for devices
> managed by the DPDK.
>
> Signed-off-by: Sergio Gonzalez Monroy
> >>> [...]
> -if (eal_parse_sysfs_value(filename, &tmp) == 0 &&
> -tmp < RTE_MAX_NUMA_NODES)
> +if (eal_parse_sysfs_value(filename, &tmp) == 0)
> dev->device.numa_node = tmp;
> >>> Why are you removing the check of the value?
> >>> Are you going to accept invalid high values?
> >>> This check was introduced on purpose by this commit:
> >>> http://dpdk.org/commit/8a04cb6125
> >> tmp is unsigned long type, so -1 is going to be a large number.
> > Oh yes, I missed it was unsigned!
> >
> >> My understanding was that it was basically checking for -1 as numa_node.
> >>
> >> If we have valid numa_node greater than RTE_MAX_NUMA_NODES, defaulting
> >> to 0 is not a good idea, is it?
> >>
> >> What I try to achieve with the patch is:
> >> - if no numa_node avilable then parse is going to fail and we set -1.
> >> - if numa_node is present but wrong, my understanding was that it would
> >> be -1.
> > All your explanations make sense when you realize that it is unsigned.
> >
> > I have one more question,
> > Does it work to check for a negative value like this?
> > if (dev->device.numa_node < 0)
>
> numa_node is signed int type in struct rte_device, so it should work.
OK, sorry I overlooked :)
Re: [dpdk-dev] [PATCH] pci: limit default numa node to used devices
21/07/2017 12:11, Sergio Gonzalez Monroy:
> Commit 8a04cb612589 ("pci: set default numa node for broken systems")
> added logic to default to NUMA node 0 when sysfs numa_node information
> was wrong or not available.
>
> Unfortunately there are many devices with wrong NUMA node information
> that DPDK does not care about but still show warnings for them.
>
> Instead, only check for invalid NUMA node information for devices
> managed by the DPDK.
>
> Signed-off-by: Sergio Gonzalez Monroy
Applied with title below, thanks
pci: move NUMA node check from scan to probe
Re: [dpdk-dev] [PATCH] doc: remove driver interface header from API index
14/07/2017 17:45, Thomas Monjalon: > The file rte_flow_driver.h is a driver interface, > thus it should not be listed in the API index. > > Signed-off-by: Thomas Monjalon Applied
Re: [dpdk-dev] [PATCH v2 2/8] net/bnxt: fix to avoid a segfault
So the only change was replacing a nesting level with a continue? Yeah,
looks good.
On Thu, Jul 20, 2017 at 8:22 PM, Ajit Khaparde
wrote:
> Fix use of local variable to avoid segfault.
> cnt was incorrectly tested and decremented in the loop that removes
> a VLAN from the table.
>
> Fixes: 36735a932ca7 ("support set VF QOS and MAC anti spoof")
>
> Signed-off-by: Stephen Hurd
> Signed-off-by: Ajit Khaparde
>
> --
> v1->v2: incorporate review feedback.
> ---
> drivers/net/bnxt/rte_pmd_bnxt.c | 101 +++---
> --
> 1 file changed, 49 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/bnxt/rte_pmd_bnxt.c b/drivers/net/bnxt/rte_pmd_
> bnxt.c
> index 0a8fb1e..ec5855d 100644
> --- a/drivers/net/bnxt/rte_pmd_bnxt.c
> +++ b/drivers/net/bnxt/rte_pmd_bnxt.c
> @@ -473,62 +473,59 @@ int rte_pmd_bnxt_set_vf_vlan_filter(uint8_t port,
> uint16_t vlan,
>
> for (i = 0; vf_mask; i++, vf_mask >>= 1) {
> cnt = bp->pf.vf_info[i].vlan_count;
> - if (vf_mask & 1) {
> - if (bp->pf.vf_info[i].vlan_table == NULL) {
> - rc = -1;
> - continue;
> + if ((vf_mask & 1) == 0)
> + continue;
> +
> + if (bp->pf.vf_info[i].vlan_table == NULL) {
> + rc = -1;
> + continue;
> + }
> + if (vlan_on) {
> + /* First, search for a duplicate... */
> + for (j = 0; j < cnt; j++) {
> + if (rte_be_to_cpu_16(
> + bp->pf.vf_info[i].vlan_table[j].vid)
> == vlan)
> + break;
> }
> - if (vlan_on) {
> - /* First, search for a duplicate... */
> - for (j = 0; j < cnt; j++) {
> - if (rte_be_to_cpu_16(
> -bp->pf.vf_info[i].vlan_table[j].vid)
> ==
> - vlan)
> - break;
> - }
> - if (j == cnt) {
> - /* Now check that there's space */
> - if (cnt == getpagesize() /
> -sizeof(struct
> bnxt_vlan_table_entry)) {
> - RTE_LOG(ERR, PMD,
> - "VF %d VLAN table is
> full\n",
> - i);
> - RTE_LOG(ERR, PMD,
> - "cannot add VLAN
> %u\n",
> - vlan);
> - rc = -1;
> - continue;
> - }
> -
> - cnt =
> bp->pf.vf_info[i].vlan_count++;
> - /*
> -* And finally, add to the
> -* end of the table
> -*/
> - ve = &bp->pf.vf_info[i].vlan_table[
> cnt];
> - /* TODO: Hardcoded TPID */
> - ve->tpid =
> rte_cpu_to_be_16(0x8100);
> - ve->vid = rte_cpu_to_be_16(vlan);
> - }
> - } else {
> - for (j = 0; cnt; j++) {
> - if (rte_be_to_cpu_16(
> - bp->pf.vf_info[i].vlan_table[j].vid)
> !=
> - vlan)
> - continue;
> - memmove(
> -&bp->pf.vf_info[i].vlan_table[j],
> -&bp->pf.vf_info[i].vlan_table[j
> + 1],
> -getpagesize() -
> -((j + 1) *
> -sizeof(struct
> bnxt_vlan_table_entry)));
> - j--;
> - cnt =
> bp->pf.vf_info[i].vlan_count--;
> + if (j == cnt) {
> + /* Now check that there's space */
> + if (cnt == getpagesize() /
> +sizeof(struct bnxt_vlan_table_entry)) {
> + RTE_LOG(ERR, PMD,
> +
[dpdk-dev] [dpdk-announce] release candidate 17.08-rc2
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v17.08-rc2 What's new in RC2? - service cores API - traffic management API (QoS) - lock-free Tx queue capability API - failsafe driver The release notes have been updated: http://dpdk.org/doc/guides/rel_notes/release_17_08.html It was a bit long too long to make this second release candidate. Hopefully it is in a good shape and there won't be too many issues for the third one. We should make RC3 in less than a week. The next release candidate is expected to include only some bug fixes, tooling, packaging or documentation updates. The patchwork backlog has been cleaned a lot by moving some features as deferred until the beginning of the 17.11 release cycle. Please check what is remaining. Thank you everyone
