[dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link

2017-01-10 Thread Christos Ricudis 
Hello, 

Using a X710 based 4-port 4x10Gbit NIC, I have came across the following issue 
on the i40e PMD: 

When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active link 
partner on the other end of the link (or fiber completely disconnected from the 
SFP+), i40e_aq_get_phy_capabilities() (called by i40e_dev_sync_phy_type() on 
port initialization), fails with a 0x05 return value (EIO) on the AQ response 
structure. The struct i40e_aq_get_phy_abilities_resp buffer passed to the Get 
Phy Abilities command is unmodified upon return. 

This prevents DPDK 16.11 from initializing the port, and ultimately fails with 
the following error: 

PMD: eth_i40e_dev_init(): Failed to sync phy type: -95

The change introducing this issue was 
http://dpdk.org/ml/archives/dev/2016-September/047663.html

Reading the X710 datasheet, I notice that no specific mention is given on the 
meaning of EIO as a response to Get PHY Abilities command (opcode 0x0600), 
whereas in most other commands, an explicit mention of the meaning of the 
possible error status responses is given. 

This behaviour is the same across the following NVM releases: 

FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6
FW 4.40 API 1.4 NVM 04.05.03 eetrack 80001cd8
FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da

I will try to get around the issue by falling back to PHY capabilities 
detection using the device ID in the case i40e_aq_get_phy_capabilities() fails, 
but conceptually the capabilities of the PHY should not be dependent on whether 
PHY detects an active link or not. 

I’d be happy to do more testing on this issue per your recommendations. 

Moreover, while trying to debug this issue, I managed to get both 3 NIC 
adapters on my test system on a state where the PHY has apparently died - no 
link indication at all on any ports. A reboot solved this, and I am now trying 
to replicate this behaviour under more controlled conditions. 

Best regards, 
Christos Ricudis.

Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link

2017-01-10 Thread Christos Ricudis 
Hi Helin, 

> On 11 Jan 2017, at 09:08, Zhang, Helin  wrote:
> 
> Hi Aaron
> 
> Is the SFP+ (Finisar FTLX8571D3BCL) supported and validated by Intel?
> It seems there is some PHY issue in this case.

As the original reporter of this issue, I will test with validated SFP+s and 
will report on my testing. 

Shouldn’t unsupported SFP+s be blacklisted in the I40E driver? 

Best regards, 
Christos Ricudis

> 
> Regards,
> Helin
> 
> -Original Message-
> From: Olivier MATZ [mailto:olivier.m...@6wind.com] 
> Sent: Tuesday, January 10, 2017 11:29 PM
> To: Christos Ricudis 
> Cc: dev@dpdk.org; Zhang, Helin ; Wu, Jingjing 
> 
> Subject: Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ 
> with no link
> 
> Hi Christos,
> 
> +CC i40e maintainers
> 
> On Tue, 10 Jan 2017 20:32:26 +0800, Christos Ricudis 
>  wrote:
>> Hello,
>> 
>> Using a X710 based 4-port 4x10Gbit NIC, I have came across the 
>> following issue on the i40e PMD:
>> 
>> When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active 
>> link partner on the other end of the link (or fiber completely 
>> disconnected from the SFP+), i40e_aq_get_phy_capabilities() (called by 
>> i40e_dev_sync_phy_type() on port initialization), fails with a
>> 0x05 return value (EIO) on the AQ response structure. The struct 
>> i40e_aq_get_phy_abilities_resp buffer passed to the Get Phy Abilities 
>> command is unmodified upon return.
>> 
>> This prevents DPDK 16.11 from initializing the port, and ultimately 
>> fails with the following error:
>> 
>> PMD: eth_i40e_dev_init(): Failed to sync phy type: -95
>> 
>> The change introducing this issue was
>> http://dpdk.org/ml/archives/dev/2016-September/047663.html
>> 
>> Reading the X710 datasheet, I notice that no specific mention is given 
>> on the meaning of EIO as a response to Get PHY Abilities command 
>> (opcode 0x0600), whereas in most other commands, an explicit mention 
>> of the meaning of the possible error status responses is given.
>> 
>> This behaviour is the same across the following NVM releases: 
>> 
>> FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6 FW 4.40 API 1.4 NVM 
>> 04.05.03 eetrack 80001cd8 FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da
>> 
>> I will try to get around the issue by falling back to PHY capabilities 
>> detection using the device ID in the case
>> i40e_aq_get_phy_capabilities() fails, but conceptually the 
>> capabilities of the PHY should not be dependent on whether PHY detects 
>> an active link or not.
>> 
>> I’d be happy to do more testing on this issue per your 
>> recommendations.
>> 
>> Moreover, while trying to debug this issue, I managed to get both 3 
>> NIC adapters on my test system on a state where the PHY has apparently 
>> died - no link indication at all on any ports. A reboot solved this, 
>> and I am now trying to replicate this behaviour under more controlled 
>> conditions.
>> 
> 
> I'm currently running into a similar issue (I think). I can reproduce it with 
> testpmd with the following case:
> 
>  set link_check off
>  port stop 0
>  # don't wait between these 2 commands
>  port start 0
> 
> I added some logs that are displayed after the port start:
> 
>  PMD: i40e_set_tx_function(): Vector tx finally be used.
>  PMD: i40e_set_rx_function(): Vector rx enabled, please make sure RX
>burst size no less than 4 (port=0).
>  PMD: i40e_dev_rx_queue_start():  >>
>  PMD: i40e_dev_tx_queue_start():  >>
>  PMD: i40e_dev_start(): applying link settings...
>  PMD: i40e_apply_link_speed(): abilities = 38, speed = 0
>  PMD: i40e_phy_conf_link(): i40e_aq_get_phy_capabilities failed -7
>  PMD: i40e_dev_start(): Fail to apply link setting
>  PMD: i40e_dev_clear_queues():  >>
> 
> The -7 corresponds to I40E_ERR_UNKNOWN_PHY. This happens in
> i40e_aq_get_phy_capabilities() in the following code, which makes me think 
> it's the same problem than yours:
> 
>   if (hw->aq.asq_last_status == I40E_AQ_RC_EIO)
>   status = I40E_ERR_UNKNOWN_PHY;
> 
> A workaround in my usecase is to wait a bit between the stop and the start.
> 
> Any help is welcome.
> 
> Regards,
> Olivier
> 
>

Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link

2017-01-18 Thread Christos Ricudis 
Hi, 

> On 12 Jan 2017, at 21:55, Olivier MATZ  wrote:
> 
> Hi,
> 
> On Wed, 11 Jan 2017 20:51:58 +, "Rowden, Aaron F"
>  wrote:
>> Hi Helin,
>> 
>> I'm checking on this to see why it could be failing but I don’t think
>> this is one part of formal validation. Intel modules are always what
>> is recommended.
>> 
>> Aaron
>> 
>>> Hi Helin, 
>>> 
>>>> On 11 Jan 2017, at 09:08, Zhang, Helin 
>>>> wrote:
>>>> 
>>>> Hi Aaron
>>>> 
>>>> Is the SFP+ (Finisar FTLX8571D3BCL) supported and validated by
>>>> Intel? It seems there is some PHY issue in this case.  
>>> 
>>> As the original reporter of this issue, I will test with validated
>>> SFP+s and will report on my testing. 
>>> 
>>> Shouldn’t unsupported SFP+s be blacklisted in the I40E driver? 
>>> 
> 
> Just to let you know that in my case the SFP are Intel ones.
> Maybe it's a different issue.
> 
> I see there are some i40e fixes in the net-next repo, I'll give a try
> with this version.
> 
> Regards,
> Olivier

After further testing, I can confirm that this issue persists with supported 
Intel SFPs (Intel FTLX8571D3BCV-IT). 

As for the changeset introducing this issue - we had failure reports with 
previous DPDK versions, probably related to LSE handling, but these weren’t 
properly investigated. The change in 16.11 which calls get_phy_capability too 
early in initialization stage might have alleviated the issue making it easier 
for us to detect and confirm. 

Best regards, 
Christos Ricudis.

[dpdk-dev] [PATCH] net/bnxt: add missing counters to xstats

2020-04-13 Thread Christos Ricudis 
Signed-off-by: Christos Ricudis 
---
 drivers/net/bnxt/bnxt_stats.c | 127 ++
 1 file changed, 127 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_stats.c b/drivers/net/bnxt/bnxt_stats.c
index 4668629..e8971ab 100644
--- a/drivers/net/bnxt/bnxt_stats.c
+++ b/drivers/net/bnxt/bnxt_stats.c
@@ -55,32 +55,80 @@
rx_pause_frames)},
{"rx_pfc_frames", offsetof(struct rx_port_stats,
rx_pfc_frames)},
+   {"rx_unsupported_opcode_frames", offsetof(struct rx_port_stats,
+   rx_unsupported_opcode_frames)},
+   {"rx_unsupported_da_pausepfc_frames", offsetof(struct rx_port_stats,
+   rx_unsupported_da_pausepfc_frames)},
+   {"rx_wrong_sa_frames", offsetof(struct rx_port_stats,
+   rx_wrong_sa_frames)},
{"rx_align_err_frames", offsetof(struct rx_port_stats,
rx_align_err_frames)},
+   {"rx_oor_len_frames", offsetof(struct rx_port_stats,
+   rx_oor_len_frames)},
+   {"rx_code_err_frames", offsetof(struct rx_port_stats,
+   rx_code_err_frames)},
+   {"rx_false_carrier_frames", offsetof(struct rx_port_stats,
+   rx_false_carrier_frames)},
{"rx_ovrsz_frames", offsetof(struct rx_port_stats,
rx_ovrsz_frames)},
{"rx_jbr_frames", offsetof(struct rx_port_stats,
rx_jbr_frames)},
{"rx_mtu_err_frames", offsetof(struct rx_port_stats,
rx_mtu_err_frames)},
+   {"rx_match_crc_frames", offsetof(struct rx_port_stats,
+   rx_match_crc_frames)},
+   {"rx_promiscuous_frames", offsetof(struct rx_port_stats,
+   rx_promiscuous_frames)},
{"rx_tagged_frames", offsetof(struct rx_port_stats,
rx_tagged_frames)},
{"rx_double_tagged_frames", offsetof(struct rx_port_stats,
rx_double_tagged_frames)},
+   {"rx_trunc_frames", offsetof(struct rx_port_stats,
+   rx_trunc_frames)},
{"rx_good_frames", offsetof(struct rx_port_stats,
rx_good_frames)},
+   {"rx_sch_crc_err_frames", offsetof(struct rx_port_stats,
+   rx_sch_crc_err_frames)},
{"rx_undrsz_frames", offsetof(struct rx_port_stats,
rx_undrsz_frames)},
+   {"rx_frag_frames", offsetof(struct rx_port_stats,
+   rx_frag_frames)},
{"rx_eee_lpi_events", offsetof(struct rx_port_stats,
rx_eee_lpi_events)},
{"rx_eee_lpi_duration", offsetof(struct rx_port_stats,
rx_eee_lpi_duration)},
+   {"rx_llfc_physical_msgs", offsetof(struct rx_port_stats,
+   rx_llfc_physical_msgs)},
+   {"rx_llfc_logical_msgs", offsetof(struct rx_port_stats,
+   rx_llfc_logical_msgs)},
+   {"rx_llfc_msgs_with_crc_err", offsetof(struct rx_port_stats,
+   rx_llfc_msgs_with_crc_err)},
+   {"rx_hcfc_msgs", offsetof(struct rx_port_stats,
+   rx_hcfc_msgs)},
+   {"rx_hcfc_msgs_with_crc_err", offsetof(struct rx_port_stats,
+   rx_hcfc_msgs_with_crc_err)},
{"rx_bytes", offsetof(struct rx_port_stats,
rx_bytes)},
{"rx_runt_bytes", offsetof(struct rx_port_stats,
rx_runt_bytes)},
{"rx_runt_frames", offsetof(struct rx_port_stats,
rx_runt_frames)},
+   {"rx_pfc_xon2xoff_frames_pri0", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri0)},
+   {"rx_pfc_xon2xoff_frames_pri1", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri1)},
+   {"rx_pfc_xon2xoff_frames_pri2", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri2)},
+   {"rx_pfc_xon2xoff_frames_pri3", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri3)},
+   {"rx_pfc_xon2xoff_frames_pri4", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri4)},
+   {"rx_pfc_xon2xoff_frames_pri5"

[dpdk-dev] [PATCH] eal: Place EAL thread stack in a reserved per-lcore memzone

2020-04-13 Thread Christos Ricudis 
Reserve a per-lcore 4MB memzone and allocate thread stack of EAL threads there 
for better NUMA locality of stack-allocated variables

Signed-off-by: Christos Ricudis 
---
 lib/librte_eal/linux/eal.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index 9530ee5..e047107 100644
--- a/lib/librte_eal/linux/eal.c
+++ b/lib/librte_eal/linux/eal.c
@@ -68,6 +68,8 @@
 
 #define KERNEL_IOMMU_GROUPS_PATH "/sys/kernel/iommu_groups"
 
+#define THREAD_STACK_SIZE_DEFAULT (4ULL * 1024ULL * 1024ULL)
+#include 
 /* Allow the application to print its usage message too if set */
 static rte_usage_hook_trte_application_usage_hook = NULL;
 
@@ -1224,6 +1226,24 @@ static void rte_eal_init_alert(const char *msg)
 
lcore_config[i].state = WAIT;
 
+   pthread_attr_t attr;
+   pthread_attr_init(&attr);
+   size_t thread_stack_size = THREAD_STACK_SIZE_DEFAULT;
+   char thread_stack_name[64];
+   snprintf(thread_stack_name, sizeof thread_stack_name, 
"rte:lcore:%s:%d:threadstack", rte_eal_process_type() == RTE_PROC_PRIMARY ? "p" 
: "s", i);
+   const struct rte_memzone *mz = 
rte_memzone_lookup(thread_stack_name);
+   if (mz == NULL) {
+   if ((mz = rte_memzone_reserve(thread_stack_name, 
thread_stack_size, lcore_config[i].socket_id, 0)) == NULL) {
+   rte_panic("Cannot allocate memzone for thread 
stack");
+   }
+   }
+   void *thread_stack = mz->addr;
+
+   if (pthread_attr_setstack(&attr, thread_stack, 
thread_stack_size) < 0) {
+   rte_panic("Cannot set thread stack\n");
+   }
+   RTE_LOG(DEBUG, EAL, "Thread stack for lcore %d on socket %d set 
to %p\n", i, lcore_config[i].socket_id, thread_stack);
+
/* create a thread for each lcore */
ret = pthread_create(&lcore_config[i].thread_id, NULL,
 eal_thread_loop, NULL);
-- 
1.8.3.1

[dpdk-dev] [PATCH] usertools: decode PCI device name as UTF-8

2020-04-13 Thread Christos Ricudis 
Fixes the case where a PCI device string identifier contains non-ASCII UTF-8.

A particular example is Mellanox Connext-X 5 EN MT27800:

28:00.0 Ethernet controller: Mellanox Technologies MT27800 Family [ConnectX-5]
Subsystem: Mellanox Technologies ConnectX®-5 EN network interface card, 
100GbE single-port QSFP28, PCIe3.0 x16, tall bracket; MCX515A-CCAT

Signed-off-by: Christos Ricudis 
---
 usertools/dpdk-devbind.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index b1d1498..8ec1703 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -257,7 +257,7 @@ def get_device_details(devices_type):
 # Clear previous device's data
 dev = {}
 else:
-name, value = dev_line.decode().split("\t", 1)
+name, value = dev_line.decode("utf8").split("\t", 1)
 value_list = value.rsplit(' ', 1)
 if len(value_list) > 1:
 # String stored in _str
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] usertools: decode PCI device name as UTF-8

2020-04-13 Thread Christos Ricudis 
Fixes the case where a PCI device string identifier
contains non-ASCII UTF-8

A particular example is Mellanox Connext-X 5 EN MT27800:

28:00.0 Ethernet controller: Mellanox Technologies
MT27800 Family [ConnectX-5]

Subsystem: Mellanox Technologies ConnectX®-5 EN network
interface card, 100GbE single-port QSFP28, PCIe3.0 x16,
tall bracket; MCX515A-CCAT

Signed-off-by: Christos Ricudis 
---
 usertools/dpdk-devbind.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index b1d1498..fad0eaa 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -211,7 +211,7 @@ def get_pci_device_details(dev_id, probe_lspci):
 for line in extra_info:
 if len(line) == 0:
 continue
-name, value = line.decode().split("\t", 1)
+name, value = line.decode("utf8").split("\t", 1)
 name = name.strip(":") + "_str"
 device[name] = value
 # check for a unix interface name
@@ -257,7 +257,7 @@ def get_device_details(devices_type):
 # Clear previous device's data
 dev = {}
 else:
-name, value = dev_line.decode().split("\t", 1)
+name, value = dev_line.decode("utf8").split("\t", 1)
 value_list = value.rsplit(' ', 1)
 if len(value_list) > 1:
 # String stored in _str
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] net/bnxt: add missing counters to xstats

2020-04-13 Thread Christos Ricudis 
---
v2:
* Fix checkpatch issues

Christos Ricudis (1):
  net/bnxt: add missing counters to xstats

 drivers/net/bnxt/bnxt_stats.c | 127 ++
 1 file changed, 127 insertions(+)

-- 
1.8.3.1

[dpdk-dev] [PATCH v2] net/bnxt: add missing counters to xstats

2020-04-13 Thread Christos Ricudis 
Add several missing hardware counters to xstats

Signed-off-by: Christos Ricudis 
---
 drivers/net/bnxt/bnxt_stats.c | 127 ++
 1 file changed, 127 insertions(+)

diff --git a/drivers/net/bnxt/bnxt_stats.c b/drivers/net/bnxt/bnxt_stats.c
index 4668629..29628bd 100644
--- a/drivers/net/bnxt/bnxt_stats.c
+++ b/drivers/net/bnxt/bnxt_stats.c
@@ -55,32 +55,80 @@
rx_pause_frames)},
{"rx_pfc_frames", offsetof(struct rx_port_stats,
rx_pfc_frames)},
+   {"rx_unsupported_opcode_frames", offsetof(struct rx_port_stats,
+   rx_unsupported_opcode_frames)},
+   {"rx_unsupported_da_pausepfc_frames", offsetof(struct rx_port_stats,
+   rx_unsupported_da_pausepfc_frames)},
+   {"rx_wrong_sa_frames", offsetof(struct rx_port_stats,
+   rx_wrong_sa_frames)},
{"rx_align_err_frames", offsetof(struct rx_port_stats,
rx_align_err_frames)},
+   {"rx_oor_len_frames", offsetof(struct rx_port_stats,
+   rx_oor_len_frames)},
+   {"rx_code_err_frames", offsetof(struct rx_port_stats,
+   rx_code_err_frames)},
+   {"rx_false_carrier_frames", offsetof(struct rx_port_stats,
+   rx_false_carrier_frames)},
{"rx_ovrsz_frames", offsetof(struct rx_port_stats,
rx_ovrsz_frames)},
{"rx_jbr_frames", offsetof(struct rx_port_stats,
rx_jbr_frames)},
{"rx_mtu_err_frames", offsetof(struct rx_port_stats,
rx_mtu_err_frames)},
+   {"rx_match_crc_frames", offsetof(struct rx_port_stats,
+   rx_match_crc_frames)},
+   {"rx_promiscuous_frames", offsetof(struct rx_port_stats,
+   rx_promiscuous_frames)},
{"rx_tagged_frames", offsetof(struct rx_port_stats,
rx_tagged_frames)},
{"rx_double_tagged_frames", offsetof(struct rx_port_stats,
rx_double_tagged_frames)},
+   {"rx_trunc_frames", offsetof(struct rx_port_stats,
+   rx_trunc_frames)},
{"rx_good_frames", offsetof(struct rx_port_stats,
rx_good_frames)},
+   {"rx_sch_crc_err_frames", offsetof(struct rx_port_stats,
+   rx_sch_crc_err_frames)},
{"rx_undrsz_frames", offsetof(struct rx_port_stats,
rx_undrsz_frames)},
+   {"rx_frag_frames", offsetof(struct rx_port_stats,
+   rx_frag_frames)},
{"rx_eee_lpi_events", offsetof(struct rx_port_stats,
rx_eee_lpi_events)},
{"rx_eee_lpi_duration", offsetof(struct rx_port_stats,
rx_eee_lpi_duration)},
+   {"rx_llfc_physical_msgs", offsetof(struct rx_port_stats,
+   rx_llfc_physical_msgs)},
+   {"rx_llfc_logical_msgs", offsetof(struct rx_port_stats,
+   rx_llfc_logical_msgs)},
+   {"rx_llfc_msgs_with_crc_err", offsetof(struct rx_port_stats,
+   rx_llfc_msgs_with_crc_err)},
+   {"rx_hcfc_msgs", offsetof(struct rx_port_stats,
+   rx_hcfc_msgs)},
+   {"rx_hcfc_msgs_with_crc_err", offsetof(struct rx_port_stats,
+   rx_hcfc_msgs_with_crc_err)},
{"rx_bytes", offsetof(struct rx_port_stats,
rx_bytes)},
{"rx_runt_bytes", offsetof(struct rx_port_stats,
rx_runt_bytes)},
{"rx_runt_frames", offsetof(struct rx_port_stats,
rx_runt_frames)},
+   {"rx_pfc_xon2xoff_frames_pri0", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri0)},
+   {"rx_pfc_xon2xoff_frames_pri1", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri1)},
+   {"rx_pfc_xon2xoff_frames_pri2", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri2)},
+   {"rx_pfc_xon2xoff_frames_pri3", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_frames_pri3)},
+   {"rx_pfc_xon2xoff_frames_pri4", offsetof(struct rx_port_stats,
+   rx_pfc_xon2xoff_fr