From: Alessandro Pilotti <apilo...@cloudbasesolutions.com> Date: Friday, July 25, 2014 at 6:13 PM To: Saurabh Shah <ssaur...@vmware.com> Cc: "dev@openvswitch.org" <dev@openvswitch.org>, Ankur Sharma <ankursha...@vmware.com>, Rajiv Krishnamurthy <krishnamurt...@vmware.com>, Guolin Yang <gy...@vmware.com> Subject: Re: [ovs-dev] [PATCH v2 0/3] Support for OVS datapath on Windows platform.
>Hi Saurabh, > >On 26 Jul 2014, at 03:32, Saurabh Shah <ssaur...@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. Sure, lets discuss this in the IRC meeting. Also, is this something that you code currently supports or is it that you want to go in this direction? > > >> >>> >>> * 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. The code definitely works for us. I am trying to figure out with Alin & see why it doesn’t work on his setup. I will be available over the weekend as well, so feel free to send me an email and I will take a look. > >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. We don’t see any BSOD’s right now in our setup. Are these new BSODs that you seeing on the patch V2? If so, can you send us the crash reports please. Out the 2 BSOD’s that you reported last time, we’ve already fixed one of them and the other one is an unsupported configuration. I had mentioned this in my reply earlier to your review comments and I re-mentioned it in the cover-letter of my V2 patch. > >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). We had a different approach to begin with, but having a persistent user friendly name for vports does sound like a good idea. This isn’t a major design issue though IMO, it can easily be added as a feature. Saurabh _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
