[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856

--- Comment #21 from ricsip <ricsip at gmail.com> ---
(In reply to Eugene Grosbein from comment #20)

Eugene: thanks for the clarification. Forgive my ignorance, that I was not
aware that the feature "multiple TX/RX queue with RSS support" for any NIC on
the market is a pure marketing gimmick, if the connection type on the NIC will
be set as ="PPPoE" and not as "pure-IP". Indeed, somebody with the necessary
network background could easily decrypt the true meaning of the various tables
(Intel i210 datasheet):

RSS and MSI-X to lower CPU utilization in multi-core systems
Receive Side Scaling (RSS) number of queues per port: Up to 4
Total number of Rx queues per port: 4
Total number of TX queues per port: 4
RSS — Receive Side Scaling distributes packet processing between several
processor cores by assigning packets into different descriptor queues. RSS
assigns to each received packet an RSS index. Packets are routed to a queue out
of a set of Rx queues based on their RSS index and other considerations.

7.1.2.10.1 RSS Hash Function
Section 7.1.2.10.1 provides a verification suite used to validate that the hash
function is computed according to Microsoft* nomenclature.
The I210 hash function follows Microsoft* definition. A single hash function is
defined with several variations for the following cases:
• TcpIPv4 — The I210 parses the packet to identify an IPv4 packet containing a
TCP segment per the criteria described later in this section. If the packet is
not an IPv4 packet containing a TCP segment, RSS is not done for the packet.
• IPv4 — The I210 parses the packet to identify an IPv4 packet. If the packet
is not an IPv4 packet, RSS is not done for the packet.
• TcpIPv6 — The I210 parses the packet to identify an IPv6 packet containing a
TCP segment per the criteria described later in this section. If the packet is
not an IPv6 packet containing a TCP segment,RSS is not done for the packet.
• TcpIPv6Ex — The I210 parses the packet to identify an IPv6 packet containing
a TCP segment with extensions per the criteria described later in this section.
If the packet is not an IPv6 packet containing a TCP segment, RSS is not done
for the packet. Extension headers should be parsed for a Home-Address-Option
field (for source address) or the Routing-Header-Type-2 field (for destination
address).
• IPv6Ex — The I210 parses the packet to identify an IPv6 packet. Extension
headers should be parsed for a Home-Address-Option field (for source address)
or the Routing-Header-Type-2 field (for destination address). Note that the
packet is not required to contain any of these extension headers to be hashed
by this function. In this case, the IPv6 hash is used. If the packet is not an
IPv6 packet, RSS is not done for the packet.
• IPv6 — The I210 parses the packet to identify an IPv6 packet. If the packet
is not an IPv6 packet, receive-side-scaling is not done for the packet.

The following additional cases are NOT part of the Microsoft* RSS
specification:
• UdpIPV4 — The I210 parses the packet to identify a packet with UDP over IPv4.
• UdpIPV6 — The I210 parses the packet to identify a packet with UDP over IPv6.
• UdpIPV6Ex — The I210 parses the packet to identify a packet with UDP over
IPv6 with extensions.
A packet is identified as containing a TCP segment if all of the following
conditions are met:
• The transport layer protocol is TCP (not UDP, ICMP, IGMP, etc.).
• The TCP segment can be parsed (such as IP options can be parsed, packet not
encrypted).
• The packet is not fragmented (even if the fragment contains a complete TCP
header)

For the majority, these deep technical statements / values are totally not easy
to covert into real world meaning of how will my i210-based firewall will
perform at 1Gbit wire-speed.

Intel could have said in their datasheets, that "this NIC is not recommended
for PPPoE-type of service". Or should Microsoft be blamed (as Intel implemented
the MSFT Receive Side Scaling algorithm, and its MSFT who doesnt support
anything apart from TCP/IP)? You see, even MSFT entered this arena now :(

Just for my curiosity (its offtopic discussion from now on, again forgive me
about that): what other possible network types will lose the multi-queue TX/RX
capability, if those types are not strictly considered as "pure-IP"?

Thanks again, situation disappointing.

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