netdev - Re: ixgbe RSS not working as expected with 8021q and bridging

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, 15 Dec 2009 20:33:53 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Eldon Koyle <esk-netdev@....cs.usu.edu>
CC:	netdev@...r.kernel.org
Subject: Re: ixgbe RSS not working as expected with 8021q and bridging

Le 15/12/2009 18:21, Eldon Koyle a écrit :
> On  Dec 11  1:11+0100, Eric Dumazet wrote:
>> Le 11/12/2009 00:11, Eldon Koyle a écrit :
>>> We have built a firewall with two 10 Gbit interfaces (intel 82598EB) and
>>> are doing some testing.  A simple bridge between the two interfaces acts
>>> as expected with packets being distributed fairly evenly across all of
>>> the rx/tx queues.
>>>
>>> We then switched to tagged vlans on both interfaces (10 vlans each, 8
>>> source and 8 dest addresses per vlan) and bridged eth0.N to eth1.N, and
>>> many of our queues (and CPUs) remained idle, and all of our VLAN traffic
>>> went out on the same tx queue.  Are multiple transmit queues supported
>>> with 802.1q?  How do we figure out what is causing some of our receive
>>> queues to be unused?
>>>
>>> We are using 2.6.31 (from Debian) and ixgbe-2.0.44.14 .
>>>
>>
>> You need more recent kernel (2.6.32) to get multi queue support on vlans, sorry.
> 
> Excellent.  2.6.32 solved half of the problem.  Now, we are using the
> same number of rx and tx queues.  We are still seeing no packets on 3 of
> our 8 rx queues on each interface, though (no packets on 2, 4 or 6).
> Does the card assign queues in hardware, or is that handled by the
> kernel?
> 

When a packet is received (ethernet -> Card), the hardware chooses a RX queue using
hash function.

Then, in your forwarding setup, we (the kernel) automaticaly use same queue to transmit packet.

So if only 5 queues out of 8 receive trafic, it might be because of the flows all map to only 5 queues,
but you should ask Intel people for details :)

(They usualy read netdev)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html