In our previous 3 blogs in this series we discussed what makes customers happy. We know that they want to get their Email fast, download their files, search the web and just do everything fast. We also know that to keep our customers happy and make a profit we have to be smart about network hardware usage. We cannot buy a new server and a new network connection for every customer. QLogic helps IT administrators get the most performance and attain the best value from their networking hardware by giving them maximum control over the flow of data from their servers.
From a high level we described the basics of QLogic NPAR, created an example customer application environment and described how Service Level Agreements can be enforced via dynamic parameters provided with QLogic NPAR. In our next blog we compared QLogic NPAR to a Linux Operating System dependent method of using SR-IOV rate limiting to control Virtual Function (VF) bandwidth. In this final blog in the series we will discuss utilizing a non-QLogic adapter's hardware to balance the IO workload using a simple Round-Robin approach and point out some of the limitations of this method of providing Ethernet Quality of Service.
Round-Robin and SR-IOV Bandwidth Scheduling Quality of Service
A competing approach to QLogic Switch NPAR that is offered by some Ethernet adapter manufacturers is based on a Round-Robin bandwidth scheduler in the adapter. This method essentially ensures that everybody gets an equal share of the pipe. The network traffic is balanced across all VFs – created in the OS using SR-IOV. No limit is set for any VF, and no guarantee can be set for the amount of bandwidth any one VF will have access to. If there are 4 VFs, then each VF gets 1/4th of the bandwidth. In contrast, QLogic NPAR is applied to Physical Functions (PF) created on the adapter without the need for SR-IOV, which is then Operating System agnostic and Switch Independent. For each PF created using QLogic NPAR there are two settings available: Maximum Bandwidth (the maximum amount of bandwidth a PF can ever consume) and a Relative Bandwidth Weight (minimum amount of bandwidth a PF can get when there is bandwidth contention with other PFs).
An Ethernet adapter that offers a "round robin" based bandwidth scheduler requires that the user first create virtual functions using the operating system tools that are available for an SR-IOV configuration. To ensure all VFs can access an "equal share" the user in this case will not set VF rate limits in the OS. In this example the user just creates the SR-IOV VF in the operating system and configures the Ethernet adapter to utilize SR-IOV.
When I/O is being transmitted by the adapter, the adapter employs a 1/n algorithm, where "n" is the number of VFs fighting for bandwidth. In our example with four VFs, all four VFs would each get 1/4th of the available bandwidth. With 10Gbps of total possible bandwidth, Application 1 could at most access 2.5 Gbps, Application 2 also would at most be able to access 2.5Gbps, etc. Also in this configuration if there is no fight for bandwidth then any VF would have access to all of the available bandwidth.
This Round-Robin scheme allows a busy VF to take available bandwidth if other VFs are idle and during a bandwidth fight, all VFs get an equal share of bandwidth. This solution solves the problem that is created by a static VF rate limit. However, this also means that when there is network congestion it is possible the SLA will be violated. There is no way to guarantee that a particular, mission critical application gets a defined higher amount of bandwidth out of the adapter.
A network administrator simply cannot depend on the adapter’s Round-Robin algorithm when an SLA is in place for a critical business application. What if having exactly the same amount of bandwidth as all other applications simply isn’t enough? To achieve this dynamically, the best option is the QLogic NPAR solution. The reason for this is due to the two parameters QLogic provides the network administrator for each PF: Maximum Bandwidth and a Relative Bandwidth Weight.
Throughout this blog series we have explored many customer application and total cost of ownership benefits that the QLogic NPAR solution offers. We have pointed out several limitations to a QoS solution based solely on SR-IOV rate limiting and a round-robin bandwidth scheduler in an adapter:
- QLogic NPAR can be deployed into the broadest possible network topology. It is Operating System and Switch Independent. QLogic NPAR creates Physical Functions that behave just like actual physical adapter ports and do not require SR-IOV or any operating system intervention
- QLogic NPAR frees up system administrators' time – they don't need to adjust the adapter to match the network workload. This feature enforces an SLA during heavy networking periods but still allows other applications to use more bandwidth when it is available and the network is idle.
- System Administrators have to babysit an SR-IOV Rate Limiting based solution. Since SR-IOV Rate Limiting requires static parameter setting in the OS there is a need for manual user intervention to set maximum bandwidth rates on a per VF basis and may lead to VFs being starved of bandwidth when the other applications are idle, wasting precious and available network resources.
- SLA enforcement is difficult to impossible without QLogic NPAR. A Round-Robin scheduler in the adapter can at best offer equal bandwidth to all VFs when there is a bandwidth fight and is dependent on SR-IOV and cannot offer a hard bandwidth guarantee, thus potentially violating SLAs.
We hope this blog series helped to explain this powerful technology and will help you create more powerful, dynamic and guaranteed fast network infrastructures.
For More Information
Please see these links for more information on these innovative 10GbE Intelligent Ethernet and Converged Network adapters. An excellent use case discussion for VMware and QLogic NPAR can be found in our Solution Sheet: Switch Independent NIC Partitioning and VMware Virtual Environments. A handy list of Frequently Asked Questions is detailed in our Switch Independent NIC Partitioning document.
Blog Series Links