Justin, thanks for the comments. On Jun 10, 2011, at 10:14 AM, Justin Pettit 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. > 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. > 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? 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. I am also curious as to how you see the functional split with SR-IOV network adapters and Open vSwitch on hypervisors. Peter > > --Justin > > > On Jun 10, 2011, at 9:47 AM, Peter Phaal wrote: > >> On Sun, May 29, 2011 at 11:35 PM, Justin Pettit <jpet...@nicira.com> wrote: >>> >>> We have seen an interest from vendors in bringing Open vSwitch's features >>> to hardware switches. To that end, our current "master" branch will be the >>> basis of a 1.2.x series of releases. The focus of which is a new datapath >>> abstraction layer that simplifies porting Open vSwitch to switching ASICs. >>> For those of you interested in understanding how this works, please look at >>> the PORTING document: >>> >>> http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob;f=PORTING >>> >>> Thanks and enjoy! >>> >>> --The Open vSwitch Team >>> >> >> For anyone porting Open vSwitch to hardware platforms, most switch >> hardware includes support for sFlow traffic monitoring so integrating >> this functionality with Open vSwitch is relatively straightforward. >> >> The following document identifies the Open vSwitch API's involved in >> integrating sFlow support: >> >> http://blog.sflow.com/2011/06/hardware-support-for-open-vswitch.html >> >> If you are porting Open vSwitch to a wireless platform, you might also >> want to look at implementing the sFlow wireless extensions: >> >> http://blog.sflow.com/2010/08/wireless.html >> >> Looking at the big picture. Combining the scalable traffic monitoring >> of sFlow with the fine grain traffic controls of OpenFlow creates >> interesting opportunities for adaptive load balancing and traffic >> shaping within the software defined network: >> >> http://blog.sflow.com/2011/05/openflow-and-sflow.html >> >> Cheers, >> Peter > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
