netdev - Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

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: <56CC5E65.40809@stressinduktion.org>
Date:	Tue, 23 Feb 2016 14:28:05 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, 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
Subject: Re: [patch net-next 3/9] mlx4: Implement port type setting via
 devlink interface

On 23.02.2016 13:21, Jiri Pirko wrote:
> Tue, Feb 23, 2016 at 12:26:00PM CET, hannes@...essinduktion.org wrote:
>> Hi Jiri,
>>
>> On 22.02.2016 19:31, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@...lanox.com>
>>>
>>> So far, there has been an mlx4-specific sysfs file allowing user to
>>> change port type to either Ethernet of InfiniBand. This is very
>>> inconvenient.
>>
>> Again, I want to express my concerns regarding all of this until this will be
>> integrated into udev/systemd for stable device names. While one can build
>> wrapper code around devlink to have stable devlink ports, I don't see a
>> reason to include kernel code which actually has more problems than the sysfs
>> approach. This harms admins to use those devices and will additionally
>> require user space to write boiler plate code.
>
> Sysfs is not the place to do this things. It was already discussed here
> multiple times. There was and attempt to use configfs, which was also
> refused. Netlink is the only place to go. For multiple reasons,
> including well defined api and behaviour, notifications, etc.

I am not against netlink at all. My fear with this interface is simply:

1) we introduce another ifindex/name like identifiers. It took a long 
time until this stuff finally worked fine with linux. It needs 
persistent storage in userspace being applied at boot time. Why this 
complications for this probably lesser often used interface?

2) The actual devlink attributes get managed from inside devlink and not 
the driver. So driver need to modify devlink.c/devlink.h in core to add 
new attributes.

1) is easily solvable, just drop the ifindex style attributes and always 
force the user to enter the bus and bus-topology id.

For 2) I don't really know what drivers want, not sure if it is easier 
to add some small helper functions to add sysfs attributes to kobjects 
without necessarily holding a net_device. Thus mellanox drivers can use 
it and I am not sure how many other networking cards allow switching 
ports between ib and eth type. Port splitting only happens for 
interfaces which already have a net_device, no?

> I think it is quite trivial to teach udev to name devlinkX devices
> according to pci address (or any other address). That's all what is
> needed here. I don't understand your concerns.

I don't think that this interface needs the same complexity as network 
interfaces.

I am not sure, but one of the initial problems was that this information 
should already be there before the driver actually gets loaded, no? 
These changes don't solve this problem either?

Thanks,
Hannes