[Section:begin]  Do not move or remove this line.  Edit with WORDPAD.exe

    COPYRIGHT: 

    This program is an unpublished work fully protected by the United
    States copyright laws and is considered a trade secret belonging to
    Emulex.  To the extent that this work may be considered "published," 
    the following notice applies "© 2010, Emulex"  Any unauthorized use, 
    reproduction, distribution, display, modification, or disclosure of this 
    program is strictly prohibited.

[Section:NetworkAddress]
This overrides the permanent MAC address for the interface. The MAC address should follow this format XX:XX:XX:XX:XX:XX, where X is a hex digit (0-9 or A-F).

•	The address cannot be a multicast address, which has the lowest bit in the first byte set.
•	The address cannot be all zeros.

For example, 01:00:00:00:00:00 is not valid, while 02:00:00:00:00:00 is valid.

[Section:*JumboPacket]
This parameter determines the maximum packet size transmitted and received on the interface. A 1514 byte frame size is standard, while larger packets are called jumbo frames.

Using a higher frame size is generally more efficient, but it uses more system memory. A larger frame size also requires support on the network switch.

[Section:InterruptModerationLevel]
The network device uses interrupt moderation algorithms to reduce the total amount of CPU cycles spent processing interrupts which increases efficiency for the system. However, interrupt moderation increases the latency of each send and receive. It should only be disabled when short latencies are more important than efficient CPU utilization.

The "No Moderation" setting disables all delays to minimize latency. 

The "Static Moderation" uses a constant interrupt delay to avoid any spikes in interrupt rate. 

The dynamic settings cause the driver to dynamically maintain a target interrupt rate. If CPU usage is too high, choose a higher adaptive value to increase the interrupt delays (and reduce the rate of interrupts).

[Section:*LsoV1IPv4]
Large Send Offload allows the NIC hardware to segment large TCP packets (up to 64kB) into smaller packets (<= "Packet Size") that may be transmitted. This segmentation will increase transmit efficiency for TCP applications that send large buffers. During segmentation, the hardware computes the IPv4 and TCP checksums for each individual packet.

The Windows Version 1 LSO supports only IPv4.

[Section:*LsoV2IPv4]
Large Send Offload allows the NIC hardware to segment large TCP packets (up to 64kB) into smaller packets (<= "Packet Size") that may be transmitted. This segmentation will increase transmit efficiency for TCP applications that send large buffers. During segmentation, the hardware computes the IPv4 and TCP checksums for each individual packet.

Windows Large Send Offload Version 2 supports IPv4.

[Section:*LsoV2IPv6]
Large Send Offload allows the NIC hardware to segment large TCP packets (up to 64kB) into smaller packets (less than the MTU) that may be transmitted. This segmentation will increase transmit efficiency for TCP applications that send large buffers. During segmentation, the hardware computes the TCP checksums for each individual packet.

IPv6 support requires LSO Version 2, included in Windows 2008 and later.

[Section:*RSCIPv4]
Receive Segment Coalescing merges multiple TCP segments and indicates them as a single coalesced unit to the operating system's TCP/IP stack. This reduces the per-packet receive processing overhead and CPU usage, when standard 1514 byte sized frames are in use.

[Section:*RSCIPv6]
Receive Segment Coalescing merges multiple TCP segments and indicates them as a single coalesced unit to the operating system's TCP/IP stack. This reduces the per-packet receive processing overhead and CPU usage, when standard 1514 byte sized frames are in use.

[Section:TxCpuPolicy]
Transmit packet completion processing will be done on this CPU.  By default, the driver will intelligently choose a CPU in the system, so this parameter should only be set for advanced performance tuning.

The valid values are 0 to (Num CPUs on the System - 1).  

[Section:RxCpuPolicy]
The non-RSS receive packets are processed on this logical CPU. By default, the driver will intelligently choose a CPU in the system, so this parameter should only be set for advanced performance tuning. RSS packets will be processed by the set of RSS CPUs provided by Windows operating system.

The valid values are 0 to (Num CPUs on the System - 1).  

[Section:ToeOptLevel]
This parameter only applies to TCP connection offload, that must be enabled in the "Protocol Offloads" section.

Most applications will perform better with TCP Offload Optimization set to "Optimize Throughput" which handles large data transfers with minimal CPU impact. 

Setting this parameter to "Optimize Latency" will cause receive data to be delivered to the application without waiting for a TCP PSH. This causes additional receive indications that will typically decrease total throughput.

[Section:*TransmitBuffers]
This sets the number of Ethernet transmits that may be posted to the hardware at any given time. 

The default value is sufficient to achieve maximum performance.  Reducing this value will conserve system memory.

[Section:*ReceiveBuffers]
This determines the number of Ethernet receive buffers allocated per receive queue. If RSS is enabled, 4 or more receive queues are used.  Otherwise, a single queue is enabled.

Decreasing this value will reduce the required system memory, but performance may decrease. Each buffer is the size of the "Packet Size" parameter.

[Section:VlanId]
Set one or more VLAN tags on the adapter. If a single VLAN tag is set, the adapter will automatically add that VLAN tag on all transmitted packets. Multiple VLAN tags should be used either with Emulex Teaming solution or in Hyper-V environment which will decide VLAN tag for each transmitted packet.

Setting Vlan tag 0 enables reception of untagged packets.

Multiple VLAN tags must be separated by space ( ). Group of contiguous VLAN tags can be specified as a range. A range is two numbers separated with a dash (-). The valid VLAN id range is 0 to 4094.

Example:2 5 7-10 15

[Section:*RSS]
Receive Side Scaling (RSS) scales receive processing over multiple CPUs in parallel. This scaling typically improves application performance; however, it tends to increase CPU usage on low end machines.

RSS is only supported on two primary adapters per device. It will appear disabled for additional PCI functions in blade server configurations.

RSS requires Windows 2003 SP2 and later.

[Section:*NumRssQueues]
When RSS is enabled, this parameter controls the number of receive queues.  

Typically, this will be left at the maximum value.  Windows will reduce the number of queues as necessary based on the number of installed CPU cores.

This value may be reduced during performance tuning for a particular application.  It is possible that system performance may improve by limiting the number of RSS queues.

[Section:*RssBaseProcNumber]
Windows will automatically spread the RSS queues for all network cards over the available CPU cores in the computer.  This parameter may be set to explicitly define the CPU affinity for the RSS queues of this device.  It is the CPU number of the lowest RSS queue for this device.

Hyperthreaded systems will only use the lower thread of each core for RSS.  A hyperthreaded system with 16 logical processors will only use 8 RSS threads.

[Section:*RssBaseProcGroup]
On systems with greater than 64 CPUs, Windows will divide the CPUs into groups.  This parameter controls the base processor group for the RSS CPUs.

[Section:*FlowControl]
The IEEE 802.3x Ethernet specification defines a control frame between peers that can request a pause in packet transmissions. This allows one system to request a temporary halt of all incoming traffic when receive buffer space is exhausted.

The network device may be configured to respond to pause frames (Rx Enable) and/or to send pause frames (Tx Enable). Flow control is almost always advantageous to avoid packet drops on the network. The switch or network peer must also have flow control enabled.

[Section:WakeOnLan]
Enabling this parameter allows the network device to wake up the computer when a magic packet is received during standby. 

In blade server configurations, Wake On Lan is only supported on two primary adapters per device. Additional PCI functions will appear disabled.

[Section:*TCPConnectionOffloadIPv4]
If TCP offload is enabled, the device offloads the entire TCP protocol, including ACK processing, retransmits, and timers. Applications that prepost receive buffers (before the data arrives) may avoid data copies in the receive path, which will substantially increase the system efficiency and data rates.

Windows will not offload TCP connections if any of the following are enabled: 
•	Windows Firewall Service (Server 2003)
•	Network Load Balancing
•	IPSEC
•	Network Address Translation
•	NDIS 5.1 Intermediate Drivers

TCP offload must be enabled in the Windows operating system with the shell commands:
Windows 2003: netsh int ip set chimney enabled
Windows 2008: netsh int tcp set global chimney=enabled

This parameter will appear disabled if the firmware installed on your device does not support TCP connection offload.  Upgrading the firmware may resolve this issue.

TCP offload requires Windows 2003 SP2.  View the "Statistics" property page to ensure that TCP connection offload is working.

[Section:*TCPChecksumOffloadIPv4]
This offloads the transmit and/or receive IPv4 TCP checksum computation.

Offloading checksums will increase system efficiency.

[Section:*TCPChecksumOffloadIPv6]
This offloads the transmit and/or receive IPv6 TCP checksum computation.

Offloading checksums will increase system efficiency.

[Section:*UDPChecksumOffloadIPv4]
This offloads the transmit and/or receive IPv4 UDP checksum computation.

Offloading checksums will increase system efficiency.

[Section:*UDPChecksumOffloadIPv6]
This offloads the transmit and/or receive IPv6 UDP checksum computation.

Offloading checksums will increase system efficiency.

[Section:*IPChecksumOffloadIPv4]
This offloads the transmit and/or receive IPv4 checksum computation.

Offloading checksums will increase system efficiency.

[Section:*NumaNodeId]
Most modern multi-socket servers have separate memory controllers for each CPU socket.  These systems have non-uniform memory access latencies for a given CPU core to access the local versus remote memory node.

By setting this property, the driver will attempt to use both memory and CPU cores from the given NUMA node.

For best performance, the network applications should try to use memory and CPU affinity from the same NUMA node. This level of tuning is primarily noticeable when multiple adapters are running.

[Section:ClassOfServiceMode]
The following modes are supported for selecting 802.1p priority tags:
•	Automatic Priority - The DCBX standard allows the network adapter to negotiate priority class usage with DCBX aware endpoints such as switches or network cards.  If the peer indicates that priority pause is supported for a non-zero priority, the NIC will automatically insert the default priority in all transmitted packets. This is the default mode, allowing priority pause to operate for both storage and network traffic.  If the peer indicates a zero default priority (such as when the peer does not support priority pause), the device uses the "Non-Storage Priority" mode discussed below.
•	Filtered Priority - This mode coerces the user priorities in each packet to avoid sending packets on the network function that may disrupt the converged adapter's storage traffic.  The network device uses the next lower priority if a conflict exists.  This mode is useful if multiple network priorities are necessary.  Only a limited number of classes are supported for priority pause, so typically it will not function optimally in this mode.
•	User Priority - This mode allows any user specified priority value.  This mode should be limited to cases where storage functions are not used.
•	Disable Priority - The adapter always transmits either untagged packets, or VLAN ID (802.1q) tagged packets with a priority value (802.1p) of zero.

[Section:*VMQ]
Virtual Machine Queues are dedicated hardware receive queues for virtual machines that filter receive packets based on the destination MAC address and/or VLAN. Receive buffers can be allocated for each queue from VM memory. 

This improves network throughput by distributing processing of network traffic for multiple VMs among multiple processors. It reduces CPU utilization by offloading receive packet filtering to NIC hardware. VMQs prove beneficial when 4 or more VMs are in use.

VMQs require Windows Server 2008 R2 or later with Hyper-V.

[Section:*VMQLookaheadSplit]
If lookahead split is enabled with VMQs, the NIC can directly DMA received packets to the virtual machine memory, eliminating a packet copy from the host to VM.

Lookahead split requires Advanced Mode Support to be enabled in the BIOS controller configuration. Lookahead split is not supported for jumbo frames.

[Section:VMQTransmit]
If this option is enabled with VMQs, separate transmit queues are created for each VM network interface. Send and receive interrupts for a VM network interface are processed on the same CPU(s).

[Section:*SpeedDuplex]
Used for selecting link speed, mainly for 10G BaseT Adapters. default it auto negotiates 100Mbps/1Gbps/10Gbps with switch/peer.  

Link speed can be forced to set to 1Gbps, if option 1.0Gbps Full Duplex  is selected.

Link speed can be forced to set to 10Gbps, if option 10Gbps Full Duplex is selected. 10Gbps is the  maximum suported link speed.

[Section:*Sriov]
<warning>Please see an Emulex Advisory below when enabling SR-IOV.

</warning>Single Root IO Virtualization (SR-IOV) enables the adapter to allocate virtual PCI functions for each virtual machine in Hyper-V. Note that the virtual switch and virtual network adapter must have SR-IOV enabled in the Hyper-V Manager.

When using SR-IOV the Emulex NIC driver must be installed on each virtual function within the virtual machine. SR-IOV provides a direct hardware interface from the virtual machine to the networking adapter, which reduces latency and improves performance.

The Windows Server 2012 SR-IOV architecture establishes each Emulex virtual NIC with a corresponding emulated NIC. This allows the virtual machine to seamlessly failover to the emulated NIC if SR-IOV is disabled. It also allows Live Migration to another system, regardless of the installed NIC hardware.<warning>

Advisory: This adapter may have a problem recovering from corrupted use of SR-IOV. Assigning an SR-IOV device to a Virtual Machine could leave the system vulnerable, and lead to instability. It is strongly recommended that you assign SR-IOV devices only to Virtual Machines that run trusted workloads, or consider disabling the use of SR-IOV.

This Advisory is highlighting a use case where a “rogue” [non-Emulex] digitally signed driver is installed by the system administrator in a Virtual Machine. It is then possible for that rogue driver to crash a BladeEngine 3 series networking adapter. While there are many benefits to using SR-IOV with virtualized workloads, these benefits should be weighed against the potential risks in doing so. As an example, see the Microsoft TechNet Blog cited in the link below where the benefits and usage of the WS2012 Hyper-V switch vs. NIC SR-IOV are noted. http://www.emulex.com/downloads/sr-iov.html</warning>

[Section:*QOS]
If QOS is enabled, it enables ETS (Enhanced Transmission selection), PFC (Priority-based Flow Control) and DCBX (Data Center Bridging Exchange) protocol. 

With ETS, each traffic class is allocated with a percentage of the link bandwidth available between directly connected peers. If a traffic class doesn't use its allocated bandwidth, ETS allows other traffic classes to use the available bandwidth that the traffic class is not using.

PFC specifies a link-layer flow control for directly connected peers. This allows a receiver to pause a transmitter on any 802.1p priority level.

DCBX allows DCB configuration parameters to be exchanged between two directly connected peers.

[Section:ETS]
If ETS is enabled, the driver will filter transmit packets based on the 802.1p priority tag into multiple separate transmit rings.  The network switch should be configured for ETS to group priorities into a priority group (or traffic class).  Each priority group may be assigned a QoS bandwidth limit.  One network priority may support priority flow control to achieve loss-less network traffic.  Using separate hardware interfaces in the driver allows each priority to progress at a different rate, or pause temporarily,  without affecting the other priorities.

When ETS is enabled, all configuration regarding bandwidth and priority flow control should be done on the network switch.  The adapter will learn the configuration using the DCBx protocol.

ETS is not supported in conjunction with VMQ technology.

[Section:Tree Categories]

[Section:Configuration]
Configuration parameters must be set correctly for the device to operate on the network.  These parameters typically require corresponding changes to the network switch or network peer device.

[Section:Performance]
This section includes parameters that help tune the performance of the device.  These parameters may need to be configured based on the system capabilities or application requirements.

[Section:PerformanceCpu]
For performance tuning, these advanced parameters allow isolating CPU usage to a particular NUMA node or CPU core.

[Section:PerformanceVmq]
These advanced parameters enable VM performance tuning.

[Section:ProtocolOffload]
Protocol offloads help reduce CPU usage on the system.  They include stateless offload for checksum computations and segmentation offload for TCP, or full TCP protocol offload. 

[Section:ProtocolOffload4]
This section details IPv4 protocol offloads.

[Section:Checksum4]
This section includes the various checksum offloads for IPv4 packets.

[Section:ProtocolOffload6]
This section details IPv6 protocol offloads.

[Section:Checksum6]
This section includes the various checksum offloads for IPv6 packets.

[Section:ERROR MESSAGES.]

[Section:DuplicateVlanId]
Invalid VLAN ID. The specified value is already is use. Modify the VLAN ID or select a dedicated ring interface.

[Section:InvalidVlanRing]
Invalid parameters. The interface must be VLAN tagged, a dedicated hardware ring, or both.

[Section:InvalidVlanId]
Invalid VLAN ID. The valid range is <min> to <max>.

[Section:InvalidPacketSize]
Invalid Packet Size. The valid range is <min> to <max>."

[Section:InvalidRxBuffers]
Invalid Receive Buffers. The valid range is <min> to <max>.

[Section:InvalidDataRate]
Invalid Max Transmit Data Rate. The valid range is <min> to <max> Mbits/sec.

[Section:InvalidPacketRate]
Invalid Max Transmit Packet Rate. The valid range is <min> to <max> packets/sec.

[Section:NetCfgLocked]
Some of the controls on this property sheet are disabled because another Network or Device Property sheet is open. Close all property sheets, and reopen this one.

[Section:Range]
The value is out of range. The valid range is from <min> to <max>.

[Section:InvalidEnum]
Invalid value. The legal values are:

[Section:Caption]
Error

[Section:InvalidMacAddress]
The Network Address is invalid.

The MAC address should follow this format XX:XX:XX:XX:XX:XX, where X is a hex digit (0-9 or A-F).

•	The address cannot be a multicast address, which has the lowest bit in the first byte set.
•	The address cannot be all zeros.

For example, 01:00:00:00:00:00 is not valid, while 02:00:00:00:00:00 is valid.

[Section:end] Do not move or remove