Date: Tue, 17 Jul 2018 08:34:43 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 203856] [igb] PPPoE RX traffic is limitied to one queue Message-ID: <bug-203856-7501-BtzFTzGFmm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-203856-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-203856-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203856 --- Comment #21 from ricsip <ricsip@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 w= ill be set as =3D"PPPoE" and not as "pure-IP". Indeed, somebody with the necess= ary network background could easily decrypt the true meaning of the various tab= les (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 =E2=80=94 Receive Side Scaling distributes packet processing between se= veral 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 functio= n is defined with several variations for the following cases: =E2=80=A2 TcpIPv4 =E2=80=94 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. =E2=80=A2 IPv4 =E2=80=94 The I210 parses the packet to identify an IPv4 pac= ket. If the packet is not an IPv4 packet, RSS is not done for the packet. =E2=80=A2 TcpIPv6 =E2=80=94 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. =E2=80=A2 TcpIPv6Ex =E2=80=94 The I210 parses the packet to identify an IPv= 6 packet containing a TCP segment with extensions per the criteria described later in this sect= ion. If the packet is not an IPv6 packet containing a TCP segment, RSS is not do= ne 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 destinat= ion address). =E2=80=A2 IPv6Ex =E2=80=94 The I210 parses the packet to identify an IPv6 p= acket. Extension headers should be parsed for a Home-Address-Option field (for source addres= s) 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 hash= ed 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. =E2=80=A2 IPv6 =E2=80=94 The I210 parses the packet to identify an IPv6 pac= ket. 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: =E2=80=A2 UdpIPV4 =E2=80=94 The I210 parses the packet to identify a packet= with UDP over IPv4. =E2=80=A2 UdpIPV6 =E2=80=94 The I210 parses the packet to identify a packet= with UDP over IPv6. =E2=80=A2 UdpIPV6Ex =E2=80=94 The I210 parses the packet to identify a pack= et with UDP over IPv6 with extensions. A packet is identified as containing a TCP segment if all of the following conditions are met: =E2=80=A2 The transport layer protocol is TCP (not UDP, ICMP, IGMP, etc.). =E2=80=A2 The TCP segment can be parsed (such as IP options can be parsed, = packet not encrypted). =E2=80=A2 The packet is not fragmented (even if the fragment contains a com= plete 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 impleme= nted 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-203856-7501-BtzFTzGFmm>