On Jun 10, 2011, at 10:54 AM, Peter Phaal wrote: >> Hi, Peter. Thanks for writing this up. To integrate with hardware, >> implementors are better off looking at the set_netflow() function in >> "ofproto/private.h". > > I think you meant to look at the set_sflow() function in ofproto/private.h.
Yes, sorry about that. >> The dpif interface is generally for software implementations that are able >> to do faster lookups based on exact-match entries; it is an instance of an >> ofproto that creates exact-match flows. > > Isn't the dpif interface also used to pass TCAM misses up to user space where > ofproto sits? The reference to dp_upcall was trying to show that the sampled > packet (along with the sample_pool) are sent up to user space using the same > channel. Yes, this is true. However, the "TCAM miss" is that an exact match entry wasn't found. >> Generally, hardware vendors are going to be creating their own ofproto >> instances that make use of wildcarded flows that make better use of TCAMs. > > That doesn't seem consistent with the functional diagram. Doesn't the > datapath component represent the TCAM implementation with the dpif interface > providing the driver for the hardware? You can certainly think about it that way, however, the dpif interface only pushes exact match entries. We provide two instances of dpif: dpif-linux (the kernel module) and dpif-netdev (userspace switching). I would imagine any additional dpif implementation would also be for a software switch (e.g., a kernel module for a new OS). > 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.) > 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. --Justin _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
