I read the document couple of times but I found it quit vague maybe because of lack of knowledge. My confusion is that whether all those components (ofproto-dpif, dpif, dpif provider) are needed all together if I want to port OVS to a new hardware or not. That is because when I looked at the blockdiagram "ofproto-dpif", "dpif", "dpif provider" are all marked as "implementation of ofproto provider", therefor my understanding was, if I need to implement "ofproto provider" I have to implement all of these components but later on I read that "ofproto-dpif" is actually a built-in "ofproto provider" itself. But it sits on top of "dpif" and "dpif provider" in the blockdiagram so it looks like it is uses "dpif" and "dpif provider" (but I am wrong apparently)
Based on what's inside the document and you emphasized in your answer if I don't want to use userspace switch I have two choices: write "ofproto provider" or "dpif provider" so does it mean that "ofproto" either uses "ofproto provider" or "dpif provider"? Thanks Mehdi On Thu, May 2, 2013 at 4:58 PM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, May 02, 2013 at 12:59:30PM +0100, Mehdi Rashidi wrote: > > I am trying to analyze the OVS as an option for porting it to our > devices. > > Reading the porting document has risen some question for me. > > Q: Say I want to port OVS to a new hardware like EZchip NP-3 platform. > > According to the document if I want to take full advantage of hardware I > > need to write my own "ofproto-provider". > > "ofproto-provider" uses "dpif" library. > > Only if you write your ofproto-provider so that it uses "dpif". (But in > that case why don't you just use ofproto-dpif?) > > > Now do I need to write a new library for my "ofproto-provider" or I > > can just use the one that is already in the package? > > Your ofproto-provider can use any code already included that you find to > be useful. > > > Also do I need to write "dpif-provider" too to feed the > > "ofproto-provider"? > > Only if you write your ofproto-provider so that it uses "dpif". (But in > that case why don't you just use ofproto-dpif?) > > > What about the "datapath" in the kernel space? Is it needed to be written > > for every porting? > > Only if you write your ofproto-provider so that it uses the kernel > datapath. > > > From the architectural block diagram I get that I need to write > > "ofproto-provider", "dpif", "dpif-provider" and "datapath" if I want to > > port OVS to a new hardware > > Most of the trouble that people have with the porting document is that > they do not actually read it. Is the following paragraph unclear? > > If the userspace switch is not the right choice for your port, then > you will have to write more code. You may implement either an > "ofproto provider" or a "dpif provider". Which you should choose > depends on a few different factors: > > > but if I want to port it to a software (say make a VM that acts as > > OpenFlow proxy that sits between egress/ingress) I need to write > > "dpif-provider" and "datapath". > > That would be the case if your VM runs an operating system that Open > vSwitch does not yet support. You could avoid writing any code if you > used Linux or FreeBSD in the VM. >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
