LAN Testing Prerequisites
The content in this section describes the LAN (Ethernet) testing prerequisites that you should complete before testing your network adapter using the Windows Hardware Lab Kit (Windows HLK).
Note
This content applies to both stand-alone network adapters and integrated network devices.
Document Terms
| Device Role | Interface Alias |
|---|---|
Test machine, test target (DUT) |
No name necessary, HLK jobs will automatically choose it |
Test machine, message device |
MessageDevice |
Support machine, support device |
SupportDevice0 |
Support machine, message device |
MessageDevice |
LWF driver |
NDIS Light Weight Filter driver |
Machine topology
The following diagram shows the recommended machine topology. Topologies that differ from this are highly discouraged as they may require extra effort in order to get the tests running correctly.
This is the topology that applies to all LAN devices (including devices which support QoS and Chimney).
Machine topology for Network Adapter tests
Recently developed HLK tests prefixed with "[Network Adapter]" or "[name of the test]" in the title are single machine tests and require 3 network adapters on that machine. The interface alias names are as follows:
- TestDevice: This is the network device under test.
- SupportDevice0: Additional support network card needed, connected back-to-back with TestDevice
- MessageDevice: Used to communicate with the HLK controller.
The following diagram shows the recommended topology:
Test connections
The back-to-back connection is preferred in general as it takes away the possibility of the switch from interfering with the test (VLAN misconfigurations, flow control packets, and so on)
A back-to-back connection is required for tests which a network switch may interfere with the result. Such tests include:
QoS (aka. DCB) (priority flow control, LLDP/DCBX interop, ETS (as some switches may strip 802.1p tags)
Tx Flow Control
Tests which send 802.1q-tagged (VlanSendRecv, VMQ, 1c_priority, maybe others)
Backchannel/corporate network
It is recommended that the backchannel switch be the same network which the test machines will use to communicate with the HLK controller. It is recommended that this network be DHCP enabled.
Machine requirements
The machine requirements are often dictated by the features which the test target supports. Certification on client SKUs will require 2 processing cores while certification on server SKUs will require 4 processing cores.
Note
The term cores refers to physical processing cores (not virtual or hyper-threaded cores). If your device supports advanced features such as the ones below, then the minimum system requirements may be increased.
Wake-on-LAN: system must support power management (S3)
RSS: maximum of either 4 physical cores or the default number of RSS queues supported by the device
Example: if a 1G NIC supports 2 queues, the number of required cores would be 4
Example: if a 10G NIC supports 8 queues, the number of required cores would be 8
Server/QoS: Systems must be capable of saturating 90% of max link rate
QoS: storage target writes at 20% of max link rate
Note
If send/receive packet loss problems happen frequently and throughout the test, it's not likely a selective suspend problem.
Note
To certify your product for use on servers, the test computer must support four processors and a minimum of 1 GB of RAM. These system capabilities are required to test the Rebalance, D3 State, and Multiple Processor Group functionality of the device and driver. You do not need a computer that actually has more than 64 processors to test your device. Additionally, the server system(s) being used for device or driver testing must have Server Core installed prior to testing. For more information see Windows Server Installation Options.
If you use a pool of test computers to test devices, at least one computer in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that computer must contain the device and the driver that you want to test. If the driver is the same on all the computers in the pool, the system creates a schedule to run against all test computers.
For tests that do not include a driver to test, such as hard disk drive tests, the Windows HLK scheduler constrains the tests that validate the device's and driver's rebalance, D3 state, and multiple processor groups functionality to run on the default test computer. You must manually configure this computer to have multiple processor groups. The default computer is the first test computer in the list. Test personnel must make sure that the first test computer in the list meets the minimum hardware requirements.
Note
Except for para-virtualization drivers (as defined by the WHCP Policies and Processes document), you may not use any form of virtualization when you test physical devices and their associated drivers for server certification or signature. All virtualization products do not support the underlying functionality that is required to pass the tests that relate to multiple processor groups, device power management, device PCI functionality, and other tests.
Note
Multiple Processor Groups Setting You must set the value for the processor group size for Hardware Lab Kit testing of Windows Server 2008 R2 and later device drivers for certification. This is done by running bcdedit in an elevated command prompt window, using the /set option.
The commands for adding the group settings and restarting are as follows:
bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f
The commands for removing the group settings and rebooting are as follows:
bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f
Note
Code Integrity Setting
The Virtualization Based Security feature (VBS) of Windows Server 2016 must be enabled using Server Manager first.
Once that has occurred, the following Registry key must be created and set:
HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)
Machine configuration
Some tests require unique configuration that is not or cannot be automatically taken care of by test jobs. The below list outlines which tests require unique configurations.
QosStorageInterop
The test target on the DUT machine must have connectivity to network-based storage using either iSCSI or SMB. The test machine topology is such that the test network is back-to-back which means the support machine must also serve as a storage target. This means a software iSCSI target must be configured on the SUT or an SMB share must be shared out. The DUT machine must map the storage target to a drive letter and the user must ensure that this connection flows over the test network and not the backchannel network. Once configured, you must input two additional parameters to this job at schedule time:
Drive letter
Storage mode (iSCSI or ND (Network Direct))
Selective suspend
The NDIS Selective Suspend feature may have a negative impact on test results. Many of the network certification tests assume a device is in a powered-on and ready-to-use state. Thus, many of the tests may quickly send or receive traffic and expect all packets to be sent or received appropriately. If a device is in low power (Selective Suspend), it may take a short while for the device to resume which may result in packet loss during the resume period.
Microsoft recommends configuring *SelectiveSuspend to disabled (for NDIS drivers) or the *IdleRestriction to enabled (for NetAdapterCx 2.2+ drivers) if the following are true (note: do not change the default value, just the operational value while running the certification tests):
A customer has a selective suspend capable device
Send/receive tests are experiencing packet loss problems
Send/receive test packet loss problems are only in the FIRST variation of a given test
Alternatively, the “Allow the computer to turn off this device to save power” can be unchecked in the miniport’s Device Manager properties Power Management tab.
HW QOS tests
The "HW QoS*" tests require SR-IOV being active, with available VF vPorts. On some hardware, Hyper-V needs to be installed for the network adapter to enable SR-IOV and advertise VF vPort availability. It is therefore recommended that Hyper-V is installed before running the "HW QoS" tests.
Overview of changes in network device selection
For LAN device testing, message and support adapters are no longer selected using a UI--they are automatically detected based on the network topology. If the automatic detection fails because the network topology is different than recommended topology, the devices need to be renamed on the test and support machines before running tests. Renaming refers to the device's "ifAlias" which is visible from the Network Connections window among other places.
If renaming is required, the support device on the support machine needs to be renamed to "SupportDevice0". The message devices on both the test and support machines need to be renamed to "MessageDevice".
Automatic device selection criteria
The test and support machines must be set up in the same configuration as Figure 4 and all other Ethernet devices/ports not involved in testing need to be disconnected or disabled. The test jobs use the following criteria to find the message device: Ethernet device, link connected, enabled, TCP bound, IP address assigned using DHCP. Detection will include adapters with static IP addresses if no adapters are with DHCP assigned addresses are found. The message adapter is typically connected to the HLK controller and normal corporate network. Once the message device is found the job searches the remaining adapters for a support device that is an Ethernet device, link connected, and enabled.
Running the LAN tests in the HLK
Please refer the HLK help for information on setting up the controller and the client machines.This document only deals with the execution of LAN content in the HLK.
Once the Controller and Client machines are setup, follow these steps for running the LAN tests:
Create a project in HLK studio.
Create a new machine pool, and add the client machines that were setup to the newly created pool, and mark the machine status as ready.
Make sure the test machine and support machine are connected as described in the Device Selection Criteria section above.
Select only the device/driver to be tested (such as device manager or software device), in the Selection tab of HLK studio.
Select the jobs that appear in the list on the Tests tab of the HLK studio.
Click Run Selected, and choose the Support machine for the test run, and click OK.
Running filter logo tests
Use the following steps to run lightweight filter (LWF) logo tests:
Setup/Configure the DTM Server and the DTM Client machines. Filter Logo tests need just the one client machine.
Install the LWF driver on the client machine.
Restart the client machine.
From DTM server, add the client on which the LWF is installed to a new machine pool, and change the machine status to 'Ready'.
From HLK studio, create a new project under the 'Project' tab in HLK Studio.
In the 'Selection' tab of the HLK studio, Select the machine pool that was created in the previous steps from the dropdown.
Click software device, and select the installed LWF driver you want to test.
Run the all tests (the 'NDISTest 6.5 - LWF Logo Test' checks for all the LWF requirements) listed in the Tests tab against the LWF driver.
NDISTest 6.5 - LWF logo test
This test targets LWF by ensuring that the filter is able to process packets that are larger than miniport's MTU size.
This also runs a filter stress test to stress the datapath and PNP paths of NDIS filter drivers. The test will limit the test virtual miniports receive descriptors such that a significant number of receive indications will happen with the receive resources flag. The test will then conduct the following actions in a multi-threaded manner:
Stress traffic from the support miniport directed to the test miniport.
Stress traffic from the test miniport directed to the support miniport
Stop/start the test miniport (which will trigger a pause and subsequent restart operations).
Test adapter indicating media disconnected/connected.
Test adapter resetting.
Finally, basic send and receive connectivity will be tested between the test/support adapters.
NdkPerfLogoTests
This test ensures that RDMA traffic can be sent and received betweeen the DUT and the the support machine. This test requires that the network interface on both DUT and support be enabled for RDMA traffic.
The test executes NdkPerfCmd.exe on both the DUT and support machine. This will load the driver ndkperf.sys which will invoke the NDK APIs to send RDMA traffic from the DUT to the support machine.
Parameters:
| Parameter | Description |
|---|---|
ClientIf |
The Interface ID of the RDMA enabled NIC on the DUT. Use Get-NetAdapter to get the ID |
ClientAddr |
The IP Address of the RDMA enabled NIC on the DUT. Use ipconfig or Get-NetIpAddress to get the IP address |
SupportIf |
The Interface ID of the RDMA enabled NIC on the Support machine. Use Get-NetAdapter to get the ID |
SupportAddr |
The IP Address of the RDMA enabled NIC on the Support machine. Use ipconfig or Get-NetIpAddress to get the IP address |
Tips for investaging failures:
Ensure both nics are RDMA enabled (Get-NetAdapterRdma)
Ensure the RDMA Activity perfmon counters increment when sending RDMA traffic
Try running NdkPerfCmd.exe manually on the DUT/support machine. If it fails then likely there is a problem with either the parameters or the Network Driver's implemantion of the NDK APIs.