[ovs-discuss] Some questions about OVS porting

Mehdi Rashidi fanttazio at gmail.com
Fri May 3 00:31:30 UTC 2013


On Thu, May 2, 2013 at 11:09 PM, Mehdi Rashidi <fanttazio at 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 <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/20130503/4d471a4c/attachment.html>


More information about the discuss mailing list