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

From: Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org>
To: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Cc: "dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org"
	<dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>,
	netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH net-next] openvswitch: report features supported by the kernel datapath
Date: Fri, 9 Oct 2015 11:24:53 +0200	[thread overview]
Message-ID: <20151009092453.GB18316@pox.localdomain> (raw)
In-Reply-To: <CAEP_g=-pgG6yhGsbvbdrJdAK3VXX1a+8c-wRkHuRte0=2Byg2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 10/08/15 at 03:40pm, Jesse Gross wrote:
> On Thu, Oct 8, 2015 at 6:53 AM, Jiri Benc <jbenc@redhat.com> wrote:
> > Allow the user space to query what features are supported by the openvswitch
> > module. This will be used to allow or disallow certain configurations and/or
> > switch between newer and older APIs depending on what the kernel supports.
> >
> > Two features are reported as supported by this patch: lwtunnel and IPv6
> > tunneling support. Theoretically, we could merge these two, as any of them
> > implies the other with this patch applied, but it's better to keep them
> > separate: kernel 4.3 supports lwtunnels but not IPv6 for ovs, and the
> > separation of the two flags allows us to backport a version of this patch
> > to 4.3 should the need arise.
> >
> > Signed-off-by: Jiri Benc <jbenc@redhat.com>
> 
> 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.

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.

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