ehttool combined X does not work if count of cores is not equal to X 3.x linux, latest driver, i40e

[TWitt4]

I would appreciate it, if you could take this serious.The topic is related to RSS. If you do not know what's it, please consult next level, please.

what the manual says.....

==================

The x710 supports multiple queues to spread the incoming traffic accross the cpus, per magic flowdirector.

It should be set up under linux running the command ethtool like

f.i.

ethtool -L eth0 combined 7

should use 7 rx/rx combined queues and distribute the traffic up to 7 irqs.

if 7 irqs are smp_affinitiy'iated to 7 cores, we can say, each queue will be handled by one core.

That was a short summary of intels manual, intel's saying how the adapter should work.

again, what's happen in reality...

========================

in our real scenario we have 1 cpu with 8 cores.

if we run "ethtool -i ethX combined 8" each queue will end up to one core.

if we run "ethtool -i ethX combined 7" there will be 8 queues, balanced to one irq/core.

Same happend if we run this with 2 or 3 or 4 ...

We can conclude:

If the count of queues is not equal to the count of cores, it shows the same misbehavior.

It just create one queue.

Finally... .?

=========

So this is not normal. this is not whats written in the manual.

Please tell me what's wrong. The manual or the driver or the card?

Adapters Data

===========

nvmeupdate:

02) Intel(R) Ethernet Controller X710  6.01(6.01) 1572 00:004 Update not  available 

  for 10GbE SFP+                        

lspci:

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)

04:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)

04:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)

04:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)

lshw:

 *-network:1

        description: Ethernet interface

        product: Intel Corporation

        vendor: Intel Corporation

        physical id: 0.1

        bus info: pci@0000:04:00.1

        logical name: ethX

        version: 02

        serial: ac:1f:6b:8d:xx:yy

        size: 10Gbit/s

        width: 64 bits

        clock: 33MHz

        capabilities: pm msi msix pciexpress vpd bus_master cap_list rom ethernet physical fibre

        configuration: autonegotiation=off broadcast=yes driver=i40e driverversion=2.7.26 duplex=full firmware=6.01 0x800036e4 1.1861.0 ip=a.b.c.d latency=0 link=yes multicast=yes speed=10Gbit/s

        resources: irq:16 memory:91000000-917fffff memory:92c08000-92c0ffff memory:fb200000-fb27ffff memory:90600000-907fffff memory:92ca0000-92d1ffff

ip, serial and logical name were modified.

ethtool -i:

driver: i40e

version: 2.7.26

firmware-version: 6.01 0x800036e4 1.1861.0

bus-info: 0000:04:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

[Mike_Intel]

Hello TWitt4, Thank you for posting in Intel Ethernet Communities. We need to further check this one. Please wait for our update. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[Mike_Intel]

Hello TWitt4, Thank you for waiting. For us to further check, can you provide Your Linux distribution used and also the ethtool -k output. And also, base on the serial number of your X710 (ac:1f:6b, it belongs to SuperMicro. You may also try to contact the, for further checking since they may have altered the specification of the card. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[TWitt4]

... but look. i can not see that the effect was system or kernel dependend. the chip/card is capable of balancing to the number for cores of the cpu.

ethtool just tells the driver the amount of queues. it looks like a bug in the latest driver.

concerning supermicro:

we use quad port sfp+ card AOC-STG-I4S

we have asked them before.

they recommended broadcome series instead. AOC-STG-b4S

[~]# more /etc/redhat-release 

CentOS release 6.5 (Final)

[~]# uname -a

Linux dummy 3.13.2-4.el6.x86_64 #1 SMP Wed Feb 26 13:31:21 CET 2014 x86_64 x86_64 x86_64 GNU/Linux

[~]# ethtool -k eth0

Features for eth0:

rx-checksumming: on

tx-checksumming: on

tx-checksum-ipv4: on

tx-checksum-ip-generic: off [fixed]

tx-checksum-ipv6: on

tx-checksum-fcoe-crc: off [fixed]

tx-checksum-sctp: on

scatter-gather: off

tx-scatter-gather: off

tx-scatter-gather-fraglist: off [fixed]

tcp-segmentation-offload: off

tx-tcp-segmentation: off

tx-tcp-ecn-segmentation: off

tx-tcp6-segmentation: off

udp-fragmentation-offload: off [fixed]

generic-segmentation-offload: off

generic-receive-offload: off

large-receive-offload: off [fixed]

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: on

receive-hashing: off

highdma: on

rx-vlan-filter: on [fixed]

vlan-challenged: off [fixed]

tx-lockless: off [fixed]

netns-local: off [fixed]

tx-gso-robust: off [fixed]

tx-fcoe-segmentation: off [fixed]

tx-gre-segmentation: on

tx-ipip-segmentation: on

tx-sit-segmentation: on

tx-udp_tnl-segmentation: on

tx-mpls-segmentation: off [fixed]

fcoe-mtu: off [fixed]

tx-nocache-copy: on

loopback: off [fixed]

rx-fcs: off [fixed]

rx-all: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

l2-fwd-offload: off [fixed]

[Mike_Intel]

Hello TWitt4, We will try to further check this. While doing that, let me also check if you tried Contacting SuperMicro for this particular issue? Just like what I have said before, since the serial number belongs to them, there is a big chance that they have altered this NIC. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[TWitt4]

what X710 product was safe in your perspective?

[Mike_Intel]

Hello TWitt4, I am sorry, what do you mean by safe? Are you referring to your X710 because it belongs to SuperMicro? We just asked you to contact SuperMicro because they may have altered this NIC. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[TWitt4]

Hi Mike, I'm considering what could be the fastest solution for this problem. So if you see any chance that supermicro could have made such modifications, it wont lead us to a final solution  short-term. Rather I see a chance in swapping supermicro's card against a card you can guarantee it will work. In order to prevent any shopping failure, I'd asked for advise. If same problem occurs, its even easier for you. Thomas Am 23. Apr. 2019, 07:22, um 07:22, Intel Forums <supportreplies@intel.com> schrieb:

[Mike_Intel]

Hello TWitt4, Okay, let me answer your last post by following the standards in building a server system. In building a server system, to avoid or lessen the issues that you may encounter, it is best to contact the board manufacturer for the list of validated components. The board always dictates the validated OS and other components. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[Mike_Intel]

Hello TWitt4, Just want to check if you tried contacting Supermicro regarding this issue. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[Mike_Intel]

Hello TWitt4, I am just checking if you were able to contact Supermicro? If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation

[Mike_Intel]

Hello TWitt4, We hope that you already tried contacting Supermicro regarding this issue. If you have questions, please let us know. Best regards, Michael L. Intel Customer Support Under Contract to Intel Corporation