Paul Durrant wrote: > On 28/09/2007, Yunsong (Roamer) Lu <roamer at sun.com> wrote: >> We've posted a new design document, Crossbow Hardware Resources >> Management and Virtualization, here: >> http://dlc.sun.com/osol/netvirt/downloads/docs/virtual_resources.pdf >> you're welcome to review and comment. >> > > WRT to load balancing/traffic steering: Microsoft have very specific > requirements for supporting load balancing NICs under Windows (using > Toeplitz hash and a re-programmable table) and you can bet that most > NICs will be supported under Windows! Hence, perhaps you should look > at the way Windows handles load balancing when deciding how you may > want to do it for GLDv3. Thank you very much for the suggestion!
We investigated some hardwares and found that the current receive load balance implementations, also known as traffic steering or receive side scaling, are very different. Not only different hash algorithms have been adopted by IHVs, but also various hardware classification scenarios are implemented. Even though Microsoft suggested Toeplitz hash based RSS. Alternatively, we prefer to leave the flexibility to hardware/drivers by defining a high level load balance interface, even the driver may decide not to expose the interface changing load balance policy. Ideally, the driver and hardware may implement these classification features: * Initially, when a group of rx rings are enabled, a default load balance policy(we prefer 5-tuple) should be enabled. It doesn't matter which type of hash is used and whether the load is evenly balanced. The framework also doesn't care the hash output. As soon as the traffics are steered to multiple channels, we assume the performance is acceptable. Then * If capable, the framework may decide to change the load balance policy, like from socket-pair based classification to IP protocol based classification, according to the traffic type. This is an optional nice-to-have interface. Then * A specific classification rule can be added with higher priority, so that a dedicated hardware channel can be used exclusively for this type of flow. For example, you want to steer all UDP/IPv4 packets to a ring for some reason. The load balance should still happen among all rest rings. Any comments? Thanks, Roamer -- # telnet (650)-786-6759 (x86759) Connected to Solaris.Sun.COM. login: Lu, Yunsong Last login: January 2, 2007 from beyond.sfbay Yunsong.Lu at Sun.COM v1.03 Since Mon Dec. 22, 2003 [Roamer at Solaris Networking]# cd ..
