netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jul 2016 22:32:41 +0200
From:	Michal Soltys <soltys@....info>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>, mcarlson@...adcom.com
Subject: Re: question: tg3 driver/nics and inconsistent RX ring count

On 2016-07-26 22:06, Alexander Duyck wrote:
> On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys <soltys@....info> wrote:
>> 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 ?
> 
> Well a quick look at the driver code makes it seem the problem lies in
> tg3_get_rxnfc.  I suspect the bug is related to the following lines:
> 
>                 /* The first interrupt vector only
>                  * handles link interrupts.
>                  */
>                 info->data -= 1;
> 
> I'm not sure what the number of interrupt vectors has to do with the
> number of rings.  Perhaps someone more familiar with the driver can
> point out why you would subtract 1 from tp->rxq_cnt to get the number
> of queues when it seems like it should be tp->rxq_cnt.
> 
> Hope that helps.
> 
> - Alex
> 

Ah thanks, seems to be the case then. Quick git blame shows it's been
since the very introduction of RSS indirection configurability (ca.
2011) in this driver, 90415477bf1356f72acc34063ff52441fc10a754.

I've CCed the author, maybe he will be able to shed some light.