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: <20160225215046.GG33942@gospo.home.greyhouse.net>
Date:	Thu, 25 Feb 2016 16:50:48 -0500
From:	Andy Gospodarek <gospo@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>
Cc:	jiri@...nulli.us, netdev@...r.kernel.org, idosch@...lanox.com,
	eladr@...lanox.com, yotamg@...lanox.com, ogerlitz@...lanox.com,
	yishaih@...lanox.com, dledford@...hat.com, sean.hefty@...el.com,
	hal.rosenstock@...il.com, eugenia@...lanox.com,
	roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
	hadarh@...lanox.com, jhs@...atatu.com, john.fastabend@...il.com,
	jeffrey.t.kirsher@...el.com, brouer@...hat.com, ivecera@...hat.com,
	rami.rosen@...el.com, hannes@...essinduktion.org
Subject: Re: [patch net-next v2 0/9] Introduce devlink interface and first
 drivers to use it

On Thu, Feb 25, 2016 at 03:12:47PM -0500, David Miller wrote:
> From: Jiri Pirko <jiri@...nulli.us>
> Date: Tue, 23 Feb 2016 16:51:25 +0100
> 
> > There a is need for some userspace API that would allow to expose things
> > that are not directly related to any device class like net_device of
> > ib_device, but rather chip-wide/switch-ASIC-wide stuff.
> > 
> > Use cases:
> > 1) get/set of port type (Ethernet/InfiniBand)
> > 2) setting up port splitters - split port into multiple ones and squash again,
> >    enables usage of splitter cable
> > 3) setting up shared buffers - shared among multiple ports within
> >    one chip (work in progress)
> > 4) configuration of switch wide properties - resources division etc - This will
> >    allow to pass configuration that is unacceptable to be passed as
> >    a module option.
> > 
> > First patch of this set introduces a new generic Netlink based interface,
> > called "devlink". It is similar to nl80211 model and it is heavily
> > influenced by it, including the API definition. The devlink introduction patch
> > implements use cases 1) and 2). Other 2 are in development atm and will
> > be addressed by follow-ups.
> > 
> > It is very convenient for drivers to use devlink, as you can see in other
> > patches in this set.
> > 
> > Counterpart for devlink is userspace tool for now called "dl". Command line
> > interface and outputs are derived from "ip" tool so it should be easy
> > for users to get used to it.
> 
> I am very close to applying this series as-is.
> 
> The clincher for me is that there is precendence in the nl80211 stuff,
> so obviously whatever userland infrastructure sits on top of that has
> found a way to deal whatever perceived shortcomings devlink has.
> 
> If all that people can come up with is "device names! omg UDEV!" and
> "multiple tools are hard to use!"  That's awesome, because it means
> nobody has any real substantial objection to this facility. :-)

Generally speaking I had no issue with the patch after being *ahem*
corrected to realize that the set operations only applied to the devlink
devices not specifically to netdevs.

I find this interface useful for some other items we have discussed in
the past (resource limits for routes, etc), so I'm happy to see some
interface for general chip maintenance included.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ