https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #22 from ricsip <ric...@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 (quote from 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 not that easy to covert into real world meaning of "how will my i210-based firewall perform at 1Gbit speed using PPPoE connection". 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. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
