[ovs-dev] [PATCH] ovs-dpctl: allow ovs-dpctl to fallback from ovs_datapath to odp_datapath Netlink Family

Ansis Atteka aatteka at nicira.com
Fri Dec 2 18:55:28 UTC 2011


On Fri, Dec 2, 2011 at 9:55 AM, Ben Pfaff <blp at nicira.com> wrote:

> On Thu, Dec 01, 2011 at 07:55:21PM -0800, Ansis Atteka wrote:
> > Some while ago Netlink Family names were changed from ODP_*
> > to OVS_*. This leaded to upgrade related issues when the new ovs-dpctl
> > wanted to remove existing datapaths from the old kernel module
> > by using 'ovs_datapath' instead of 'odp_datapath' name.
> >
> > Issue #8548
>
> I believe that adding some compatibility is the right approach, but I
> think that this is not the right way to do it.
>
> We can't modify include/linux/openvswitch.h for this because that file
> is supposed to go upstream.
>
> I don't think that we should make dpif-linux.c treat the older
> "odp_datapath" identically to the newer "ovs_datapath", because there
> are undoubtedly important changes that will cause many (most?)
> operations to fail in the older protocol.
>
I mostly agree with this.

I haven't looked into GIT history how much our Netlink protocol has changed
between odp_datapath and ovs_datapath, so I do not have strong opinion
about this. But the thing is that operations can also fail between two
different ovs_datapath versions that go under the same name as well.

In the past ovs-dpctl has always tried to treat two different versions of
ovs_datapath the same way. And the commit that changed odp_* to ovs_* was
pure refactoring. That was the reason why I thought that using them as
fall-back alias would not be more risky than what we have been doing all
the time.


> I would:
>
>        * Put the definitions we need in a separate header file.
>
Ok.

>
>        * Log a warning when the fallback datapath is opened.
>
 Ok.

>
>        * Support only the most basic operations, e.g. dump, open,
>          close, destroy, and fail the rest with an error.

Agree. Initially I wanted to go the same approach by limiting fall-back
only to ovs-dpctl commands that are needed to unload the kernel module. But
If I understand it correctly then this would require in dpif_linux_init()
knowledge whether it is being called from ovs-dpctl and what operations
user wants to execute. Will look into this.

>

I think it might be reasonable, in fact, to define this as a
> completely separate dpif named, e.g., "linux-old" in a file like
> lib/dpif-linux-old.c.  That would make it very easy to remove later.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20111202/a0151a75/attachment-0003.html>


More information about the dev mailing list