From owner-freebsd-net@freebsd.org Tue Jul 17 08:34:47 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421DA103071A for ; Tue, 17 Jul 2018 08:34:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CBA1D7AAE0 for ; Tue, 17 Jul 2018 08:34:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 828931030719; Tue, 17 Jul 2018 08:34:46 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E3451030718 for ; Tue, 17 Jul 2018 08:34:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ECD867AADF for ; Tue, 17 Jul 2018 08:34:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 388CD1C72C for ; Tue, 17 Jul 2018 08:34:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6H8YjVC058812 for ; Tue, 17 Jul 2018 08:34:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6H8Yj6P058811 for net@FreeBSD.org; Tue, 17 Jul 2018 08:34:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 203856] [igb] PPPoE RX traffic is limitied to one queue Date: Tue, 17 Jul 2018 08:34:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ricsip@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 08:34:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203856 --- Comment #21 from ricsip --- (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.=