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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151009092453.GB18316@pox.localdomain>
Date:	Fri, 9 Oct 2015 11:24:53 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Jesse Gross <jesse@...ira.com>
Cc:	Jiri Benc <jbenc@...hat.com>, netdev <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Pravin Shelar <pshelar@...ira.com>
Subject: Re: [PATCH net-next] openvswitch: report features supported by the
 kernel datapath

On 10/08/15 at 03:40pm, Jesse Gross wrote:
> On Thu, Oct 8, 2015 at 6:53 AM, Jiri Benc <jbenc@...hat.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@...hat.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html