[ovs-dev] [PATCH v2 0/3] Support for OVS datapath on Windows platform.

[Alessandro Pilotti]

Hi Saurabh,

On 26 Jul 2014, at 03:32, Saurabh Shah <ssaurabh at vmware.com> wrote:

> Hi Alessandro,
> 
>> Hi Saurabh,
>> 
>> I¹d suggest that before doing a full review of the kernel driver we need
>> to have:
>> 
>> * Userspace Netlink interface support (which means that patches 1 and 2
>> in this
>> set can be skipped)
> 
> There is some dependence between patches 2 & 3. In my V3 change I will
> drop out the entire userspace change & just post the kernel.
> 
>> 
>> * Kernel Netlink interface support (not provided by patch 3)
>> 
>> * Support for multiple datapaths and vswitches
> 
> I would like to understand the use case a little better. Can you let me
> know?

To begin with, one of the goals we had in mind is to make sure that this port
integrates seamlessly with the Hyper-V networking. Not supporting multiple
switches, a very common scenario, is definitely not a step in this direction.

This is just a starting point of course, we can have an initial discussion on
the scenarios during the IRC meeting. 

> 
>> 
>> * Split the kernel driver code in smaller patches to allow a proper
>> review (I
>> made a simple suggestion in a previous email, but any other solution is
>> good)
> 
> Splitting the change into multiple smaller changes will likely be very
> difficult and time consuming. Once the initial kernel support has been
> checked in, lets do incremental changes/reviews from then on.
> 

I suggest to discuss about this and other topics during the IRC meeting on Tue
as well. 

IMO the code must at least work (and I’m not discussing about a bug or two,
I’m talking about basic functionality) and be able to interface properly with
the userspace using the Netlink interface we agreed upon, so surely those
patchsets need anyway to be reworked.

We did some very basic tests and we are getting blue screens (aka kernel
panics) by just doing very basic operations, w/o even being able to get a basic
VXLAN tunnel in place.

This code can surely be used as a base to build the driver, but it’s nowhere
close to a mergeable state IMO.

There are also design decision to be agreed upon, for example the implicit
naming in the vswitch / ovs port mapping is a total no go for what I’m
concerned (again, just my 2c, but I'd like to see some proper discussion on this).

Let’s not even start talking about test coverage, but that can be
reserved to a different conversation.

I don’t want to sound negative, on the contrary I’m looking forward to see this
work merged ASAP, but not before the bare minimum design, feature and stability
level is reached, otherwise we’ll just complicate a lot the subsequent work for
the near future.



Thanks,

Alessandro


> Thanks!
> Saurabh
>