On Thu, May 2, 2013 at 11:09 PM, Mehdi Rashidi <fantta...@gmail.com> wrote:
> 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. > OK. I made a mistake here. By ofproto-dpif I meant "ofproto provider". My questions may look daft but that would be a great help for me to get answer. So far I've learnt so much. Thank you > 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
