[ovs-discuss] Some questions about OVS porting

Mehdi Rashidi fanttazio at gmail.com
Thu May 2 22:09:31 UTC 2013


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 <blp at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130502/2fa1b905/attachment.html>


More information about the discuss mailing list