Users Guide
Table Of Contents
- Table of Contents
- 1 Regulatory and Safety Approvals
- 2 Functional Description
- 3 Network Link and Activity Indication
- 4 Features
- 4.1 Software and Hardware Features
- 4.2 Virtualization Features
- 4.3 VXLAN
- 4.4 NVGRE/GRE/IP-in-IP/Geneve
- 4.5 Stateless Offloads
- 4.6 Priority Flow Control
- 4.7 Virtualization Offload
- 4.8 SR-IOV
- 4.9 Network Partitioning (NPAR)
- 4.10 Security
- 4.11 RDMA over Converged Ethernet – RoCE
- 4.12 VMWare Enhanced Networking Stack (ENS)
- 4.13 Supported Combinations
- 4.14 Unsupported Combinations
- 5 Installing the Hardware
- 6 Software Packages and Installation
- 7 Updating the Firmware
- 8 Link Aggregation
- 9 System-Level Configuration
- 10 PXE Boot
- 11 SR-IOV – Configuration and Use Case Examples
- 12 NPAR – Configuration and Use Case Example
- 13 Tunneling Configuration Examples
- 14 RoCE – Configuration and Use Case Examples
- 15 DCBX – Data Center Bridging
- 16 DPDK – Configuration and Use Case Examples
- Revision History
Broadcom NetXtreme-E-UG304-2CS
35
NetXtreme-E User Guide User Guide for Dell Platforms
The device supports NetQueue selection based on any combination of the fields above.
NOTE: For GRE/IP-in-IP frames, the VMQ selection is performed using the Ethernet header of the encapsulated packet
(inner packet) that includes inner destination MAC address and inner 802.1Q Tag (optional).
4.7.4.8 RSS
For VXLAN frames, there are two options for RSS queue selection:
RSS hash computation based on outer UDP/IP headers: The VXLAN IETF draft recommends that the source port is set
based on the hash of inner headers. This allows the RSS hash computation based on outer UDP/IP headers a viable
option.
RSS hash computation based on inner UDP/IP or TCP/IP headers: This option requires 2-tuple or 4-tuple hash
computation based on inner headers. The inner header is parsed for RSS hash computation. The RSS hash
computation is performed in parallel with other checksum computations. In some exceptional cases, this may lead to
inaccurate hash computations where one or more checksum validation fails.
For GRE/IP-in-IP frames, the RSS queue selection is performed using inner headers. The following are possible
combinations:
GRE/IP-in-IP frame with inner TCP/IP or UDP/IP headers: The RSS is performed using four-tuple (src IP, dst IP, src
port, dst port) hash on the inner IP header and TCP or UDP header.
GRE/IP-in-IP frame without inner TCP or UDP header: The RSS is performed using 2-tuple (src IP, dst IP) hash on the
inner IP header.
Other encapsulated frames (for example, GRE/IP-in-IP frames that cannot be parsed): The RSS is performed using 2-
tuple (src IP, dst IP) hash on the outer IP header.
4.7.4.9 TCP Segmentation Offload
For VXLAN, the TCP Segmentation Offload (TSO) algorithm is performed on the inner TCP segment. The hypervisor
provides template TCP/IP headers for the inner TCP segment as well as template VXLAN/UDP/IP headers for the outer UDP
datagram. For every inner TCP segment generated by the VXLAN-aware TSO, the outer VXLAN, UDP, IP, and MAC headers
are inserted and outer IPv4 checksum, outer UDP checksum (not for GRE frames), inner IP checksum (for inner IPv4
datagram only), and inner TCP checksum is computed and inserted. The device updates the IP ID field for every inner TCP
segment.
For GRE/IP-in-IP, the LSO (Large Send offload) algorithm is performed on the inner TCP segment. The hypervisor provides
template TCP/IP headers for the inner TCP segment as well as template GRE/IP/Ethernet headers for the outer IP
datagram. For every inner TCP segment generated by the GRE/IP-in-IP-aware LSO, the outer GRE (not applicable for IP-
in-IP frames), IP, and MAC headers is inserted and outer IPv4 checksum (for outer IPv4 datagrams only), inner IP checksum
(for inner IPv4 datagram only), and inner TCP checksum is computed and inserted. The device updates the IP ID field for
every inner TCP segment.
4.7.4.10 Large Receive Offload
Tunneling Offload support for LRO and RSC support is TBD.
4.8 SR-IOV
The PCI-SIG defines optional support for Single-Root IO Virtualization (SR-IOV). SR-IOV is designed to allow access of the
VM directly to the device using Virtual Functions (VFs). The NIC Physical Function (PF) is divided into multiple virtual
functions and each VF is presented as a PF to VMs.