






So with that …

Why soft switching is awesome:





First, what are the latency costs of soft switching?




What about throughput?




Soft Packet Classification:

















10 Comments on “The Rise of Soft Switching Part II: Soft Switching is Awesome ™”

  1. Hi Martin, let me reply here with the same arguments I used commenting your post at Ivan’s site.



    This said, I like how you clarify some “myths” on software-based switching for virtualized environments. I am missing a bit on the real world challenges of configuring this kind of scenario for a quick and manageable deployment. I believe the beauty of passthrough solutions is in its simplicity and direct ways. I happen to just have finished the design and deployment of a pretty dense virtual network (more than 2000 virtual desktops and around the same figure for virtual servers), and there really is a design complexity toll you pay when introducing this layer. True, its benefits greatly overshadow this extra complexity, but every step we take towards simplification is very welcome, especially for large Enterprise customers.

    Congrats on the post though, referenced it at my blog as usual: great clarity and succinctness.


    (DISCLAIMER: I am a Cisco Systems Engineer).

  2. D.S. says:

    What about the overhead of TCP offload , IP checksums etc, that cannot be delegated to the NIC any more?

    • [note: the original reply was a little misleading and has been edited to clarify things a bit.

      It’s important to remember that end-host protocol offload does not conflict with the softwitching. The vSwitch can (and does) carry the context for various stateless offloads from the vNIC through to the pNIC and in the vNICvNIC case can either avoid doing them (ie VLAN tagging/stripping, or can do them in software optionally [checksum offload is one that can be dropped technically, but makes tcpdump output look scary so is usually done in software [for “free” inline with the copy that happens anyway]])

      However, there is definitely room for simple offload of other functions within the NIC (without full abdication of control). And that is the subject of our final post which should be up in the next day or so.

  3. Alex Bachmutsky says:

    I would say that you’ve made a lot of assumptions and oversimplified the generic problem. You are right that for some applications a softswitch could be a viable solution. However, there are a number of arguments against it:
    1. When you need IPsec/MACsec/TCP/UDP offload, you still need an intelligent NIC. In many cases you need to load balance between multiple switching instances, so with the intelligent NIC it makes sense to place that function there, because it is coming “for free”. The same is true also for a basic switching.
    2. Switches today are not that dumb, they can handle very large tables, they can process L2-L4 headers and beyond (usually first 128B-256B of the packet are being parsed), some of them are even programmable to be able to add new protocols.
    3. You can use NPUs for switching, which can provide the required flexibility, performance and scalability.
    4. Even if softswitch can achieve the same performance level, you pay much heavier price from the power consumption point of view. And we all know well how important is the power today.
    5. You’ve assumed in your calculations a large packet size, which is not always the case. Instead of providing the bit rate as a performance characteristic, much better metric is the packet rate. For instance, the 10Gbps capable switch can usually handle 15Mpps. I do not think you can claim the same for softswitch.
    6. If your application requires also traffic management capabilities, the softswitch overhead goes up very quickly with a number of queues, because dual token or leaky bucket implementation is expensive in means of CPU cycles. Of course, you can say that TM can be also offloaded to the NIC, but TM requires some level of flow classification, and with flow classification already performed in the NIC it makes sense to do the switching in the NIC as per the 1st argument.

    Just to clarify my comment: I am not saying that softswitch is not a good solution, I am saying that you should check a particular application and its further evolving requirements before deciding on the softswitch-based implementation.

    And a final comment here is about the definition of a softswitch. Remember that above-mentioned intelligent NIC could be based on the latest generation of multi-core processors (Cavium, NetLogic, Tilera, etc.) with hybrid NPU-CPU capabilities and a lot of offload, but the switching itself is still performed by software either in Linux or bare metal environment. So from the system point of view the switching is performed by the NIC, but it is still a softswitch…

  4. […] the second article the Network Heresy folks attempts to defend software switching and excoriate SR-IOV in […]

  5. EtherealMind says:

    I have two, at least, issues that remains unaddressed:

    1) is that the additional complexity of a software layer is a operational failure – network software has a poor reliability record and no reason to believe that soft switching in the hypervisor will be any more or less successful.

    2) that security is not possible when soft switching for a standard multi-tenant and multipurpose designs. Security baselines require more than promises of “no bugs” or “no access we promise”. Sinvce VMware has started to inject device drivers into GuestOS’s there is no security barrier between the hypervisor and Guest.

    For these fundamental reasons, I find it highly unlikely that Soft Switching will cross the adoption gap.

    • Hey, thanks for the comment.

      However, I (this is Martin) think we might be talking about two different things. By soft switching, we’re simply referring to the first hop decision being done in software rather than shunted directly to hardware via hairpinning or passthrough. This is how 99.9% of all virtualized workloads have worked over the last decade (whether using VMWare’s vswitch, the linux bridge, or Open vSwitch). All of the large multi-tenant virtualized clouds that we know of use soft switching. So (a) it seems the complexity is manageable (b) it seems to have already crossed the adoption gap. Perhaps you’re referring to something different than we are?

      To your second point, security. Soft switching maintains the same security model as compute virtualization, which is trust consolidation in the hypervisor. Today, all virtualized deployments which support co-resident VMs entrust the hypervisor to enforce address space isolation by managing the physical page table. If this is compromised, all isolation is compromised.

      So, if you don’t trust the hypervisor (for whatever reason), you don’t trust virtualization (and you shouldn’t be running it). However, if you do trust virtualization, then soft switching doesn’t change the basic security assumptions. Which again, is why soft switching has faired well over the last decade in security sensitive environments such as the federal space, and large multi-tenant datacenters.

  6. […] is our third (and final) post on soft switching. The previous two posts described various hardware edge switching technologies (tagging + hairpinning, offloading to the […]

  7. I would argue that softswitching “has faired well over the last decade” and “all of the large multi-tenant virtualized clouds that we know of use soft switching” because there really hasn’t been a real-world alternative solution until relatively recently.

Leave a Reply


You are commenting using your account. Log Out /  Change )

Google photo


Twitter picture


Facebook photo


Connecting to %s