netdev - question: tg3 driver/nics and inconsistent RX ring count

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2016 21:52:50 +0200
From:	Michal Soltys <soltys@....info>
To:	Linux Netdev List <netdev@...r.kernel.org>
Subject: question: tg3 driver/nics and inconsistent RX ring count

Hi,

I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
servers - and all of them have certain peculiarity: they claim to have
up to 4 TX and RX rings (and this can be set/verified just fine through
ethtool -l/-L, with driver defaulting to 4 rings), indirection table
(ethtool -x) looks fine as well:

RX flow hash indirection table for eth1b with 3 RX ring(s):
    0:      0     1     2     3     0     1     2     3
    8:      0     1     2     3     0     1     2     3
......

But this "3 RX ring(s)" is actually a real limit if I try to adjust
anything, for example all those commands would fail:

ethtool -X eth1b equal 4
ethtool -X eth1b weight 1 1 1 1

But would work fine for 3 and less rings. This was quickly tested with
different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
exact results. Nothing fancier (-N/-U) is supported either.

Any hints/comments about the cause of this and/or possible workarounds ?