On Fri, 9 Oct 2015 11:24:53 +0200, Thomas Graf wrote: > On 10/08/15 at 03:40pm, Jesse Gross wrote: > > I have similar concerns as were expressed in the other thread. The > > features listed here aren't OVS components and I don't think that it > > makes sense for OVS to try to cover everything that is related - the > > goal that we've been working towards is to have OVS be less monolithic > > and more integrated. So to the extent that it is necessary to have > > capabilities be exposed (and I would like to avoid this where > > possible), it should be in the individual component, not in OVS.
Fair enough. Note that the IPv6 flag really belongs to ovs, though - it's about the existence of OVS_TUNNEL_KEY_ATTR_IPV6_SRC and OVS_TUNNEL_KEY_ATTR_IPV6_DST netlink attributes. For the lwtunnel flag (which is just another way to tell whether vxlan/geneve/etc. has COLLECT_METADATA support) I can agree that it does not belong to ovs. > I'm fine with that as well. However, I do dislike the idea of creating > net_devices with a set of parameters just to figure if the parameters > are supported or not. This works OK for the first step of evolution > where we have support or not but it gets absolutely messy when we > have: no support, multiple levels of partial support and finally full > support. 100% agreed. > We have been thinking about a more generic capabilities Netlink > interface for a while and this looks like a good justification for > finally doing that work. I've been looking into this since morning and everything I've been able to come up with seems to be quite intrusive. Before investing time to create a long patchset that might be potentially rejected, I'd like to get some opinions. My thoughts are introducing either RTM_VALIDATELINK or RTM_NEWLINK_STRICT. In the first case, it would just check whether the passed attributes are okay for "strict" creation of the link; in the second case, it would either reject the request, or create the link (similarly to what RTM_NEWLINK does but with "strict" attributes checking). The "strict" checking would mean: - Rejecting attributes with type <= 0 and > maxtype (i.e. changing nla_parse, nlmsg_parse, etc. to do optional strict checking based on a passed bool parameter). - Adding the bool parameter for strict checking to rtnl_link_ops validate and slave_validate callbacks. It would mean refactoring of rtnl_newlink. Or do you have something more generic in mind? Like adding a new NLM_F_REQUEST_STRICT flag to nlmsghdr to be used instead of NLM_F_REQUEST? Thanks, Jiri -- Jiri Benc -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
