Re: [PATCH net-next] openvswitch: report features supported by the kernel datapath

[Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev