All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [dpdk-dev] [Bug 263] ixgbe does not support 10GBASE-T copper SFP+
Date: Wed, 01 May 2019 06:54:06 +0000	[thread overview]
Message-ID: <bug-263-3@http.bugs.dpdk.org/> (raw)

https://bugs.dpdk.org/show_bug.cgi?id=263

            Bug ID: 263
           Summary: ixgbe does not support 10GBASE-T copper SFP+
           Product: DPDK
           Version: 17.11
          Hardware: x86
                OS: Linux
            Status: CONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: ido@cgstowernetworks.com
  Target Milestone: ---

Tried couple of vendor's 10GBASE-T copper SFPs and they fail at init
Transceiver example http://www.eoptolink.com/products/copper-10g-sfp

        root@AFS:/home/cgs# ./testpmd -c7 -n3 -w 0000:0a:00.0 -- -i
        EAL: Detected 28 lcore(s)
        EAL: Detected 2 NUMA nodes
        EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
        EAL: No available hugepages reported in hugepages-1048576kB
        EAL: Probing VFIO support...
        EAL: PCI device 0000:0a:00.0 on NUMA socket 0
        EAL:   probe driver: 8086:10fb net_ixgbe
        eth_ixgbe_dev_init(): Unsupported SFP+ Module
        eth_ixgbe_dev_init(): Hardware Initialization Failure: -19
        EAL: ethdev initialisation failedEAL: Requested device 0000:0a:00.0
cannot be used
        testpmd: No probed ethernet devices

Tested in 2 different Intel controllers 82599ES and X552 
        cgs@AFS:~# lspci -s  0a:00.0
        0a:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection (rev 01)
        cgs@AFS:~$ lspci -s 04:00.0
        04:00.0 Ethernet controller: Intel Corporation Ethernet Connection X552
10 GbE SFP+


If the SFPs is inserted only *after* the dpdk app starts (after rte_eal_init
and pci devices are probed) it will work! 
as it is only identified and blocked as not supported in
ixgbe_identify_sfp_module_generic
Though the ixgbe_identify_sfp_module_generic function tries to be premissive in
case the allow_unsupported_sfp is set
        if (hw->allow_unsupported_sfp == true) {
                                EWARN(hw,
                                        "WARNING: Intel (R) Network Connections
are quality tested using Intel (R) Ethernet Optics. "
                                        "Using untested modules is not
supported and may cause unstable operation or damage to the module or the
adapter. "
                                        "Intel Corporation is not responsible
for any harm caused by using untested modules.\n");
                                status = IXGBE_SUCCESS;
                        }
but this is too late as this SFP falls into earlier case in the function
        /* Verify supported 1G SFP modules */
        if (comp_codes_10g == 0 &&
                    !(hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1 ||
                      hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0 ||
                      hw->phy.sfp_type == ixgbe_sfp_type_1g_lx_core0 ||
                      hw->phy.sfp_type == ixgbe_sfp_type_1g_lx_core1 ||
                      hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core0 ||
                      hw->phy.sfp_type == ixgbe_sfp_type_1g_sx_core1)) {
                        hw->phy.type = ixgbe_phy_sfp_unsupported;
                        status = IXGBE_ERR_SFP_NOT_SUPPORTED;
                        goto out;
                }

The driver reads 0 from eeprom IXGBE_SFF_10GBE_COMP_CODES offset and
comp_codes_10g=0 
I guess because there's no 10GBASE-T code defined in SFF-8472 TABLE 5-3
TRANSCEIVER COMPLIANCE CODES [https://members.snia.org/document/dl/25916] 

This same 10GBASE-T SFP does work in i40e controllers

see more info and suggested patch in
http://mails.dpdk.org/archives/dev/2019-April/131091.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

                 reply	other threads:[~2019-05-01  6:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-263-3@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.