[ovs-discuss] Open vSwitch 1.1.1 Available

[Peter Phaal]

On Jun 13, 2011, at 11:51 PM, Justin Pettit wrote:

> 
>> I guess I am not clear where in the ofproto -> ofproto-dpif -> dpif -> dpif provider -> datapath stack the decision to use exact_match or keep wildcards is made. It seems like it would be a good idea to try and push that decision down the stack since it is closely tied to the hardware capabilities and would allow greater code re-use.
> 
> The dpif implementation itself makes the exact-match flows.  I would expect a hardware vendor with a switching ASIC to write their own ofproto plugin, which deals with wildcarded flows.  Just like there is an "ofproto-dpif.c" file, I'd expect there to be an "ofproto-acme.c" file if the ACME corporation wrote a plugin for their ASIC's API.
> 
> Most of this should be documented in the PORTING guide, but clearly its falling short in some of its explanations. If you have any suggestions on how to improve it, please let us know!  I already have some thoughts on a couple of areas. 
> 
> (By the way, one thing that may have added to the confusion is that the "ofproto-sflow.[ch]" files should really be named "dpif-sflow.[ch]".  This is a vestige of the reorganizing that happened in the process of getting this hardware abstraction layer added.  I spoke with Ben, and he agreed that we should change it.)

The porting guide shows an "ofproto provider" block in the first diagram, which I take to be the ofproto plugin? This block is dropped in the second diagram. 

Perhaps the second diagram should should be modified to include ofproto provider, making the path: 
ofproto->ofproto provider->dpif->dpif provider->datapath

This would make it clearer that the ofproto provider module is part of the driver stack for any given piece of hardware.

> 
>> I am also curious as to how you see the functional split with SR-IOV network adapters and Open vSwitch on hypervisors.
> 
> The current SR-IOV adaptors that I've seen have extremely coarse-grained rules to determine which traffic should bypass the hypervisor, basically a VLAN and DMAC.  As such, we cannot apply the fine-grained policies that users would typically expect from OVS.  We've been having conversations with NIC vendors about improving this situation.
> 

The vSwitch case is likely to see the most hardware diversity since different vendor's network adapters might be installed in the same server. Some adapters may have suitable hardware support for OpenFlow and others won't. Making it clear what the driver boundary is for the adapter makes it easier to see how they would all plug into OVS as a common control plane. It looks like the ofproto provider API abstracts the hardware differences in the forwarding capabilities. Is this correct?