hi Ben, This is very reasonable. This will enable meaningful collaboration without duplicating effort. There are some indications of design choices that have seem different between the two implementations. Discussing about those things would be useful for the product.
For Eg:. > * Cloudbase has the ability to set AllowManagementIP to false. (I > don't understand what this means.) > I hope that initial patches will focus on adding Netlink support to the > kernel module, based on the userspace Netlink code or the Cloudbase kernel > implementation or some combination. Here is a list of other features that > I'd like to see added, based on the list of differences above. To the > extent that it makes sense, I hope that this could reuse code from the > Cloudbase implementation rather than duplicating work further: > > * The Windows support daemon required for full integration. > > * Megaflow classifier. > > * GRE support. > > * Installer. > > * Support for configurable VXLAN UDP port (I think the Linux > kernel module can support VXLAN on multiple UDP ports; that's > nice to have but less important than a configurable port > number). > > * Support for checksum offloading and any other offloads that make > sense. > > * Persistent port naming. The "Windows support daemon" and the "Persistent port naming" have some overlapping functionality. We can discuss and figure out what is the best approach. > I think that when we're done, we'll end up with a flexible and well- > integrated HyperV port. Absolutely. thanks! -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
