netdev - Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and attributes

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: <20190709061711.GH2282@nanopsycho.orion>
Date:   Tue, 9 Jul 2019 08:17:11 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Parav Pandit <parav@...lanox.com>, netdev@...r.kernel.org,
        jiri@...lanox.com, saeedm@...lanox.com
Subject: Re: [PATCH net-next v6 0/5] devlink: Introduce PCI PF, VF ports and
 attributes

Tue, Jul 09, 2019 at 07:40:12AM CEST, jakub.kicinski@...ronome.com wrote:
>On Mon,  8 Jul 2019 23:17:34 -0500, Parav Pandit wrote:
>> This patchset carry forwards the work initiated in [1] and discussion
>> futher concluded at [2].
>> 
>> To improve visibility of representor netdevice, its association with
>> PF or VF, physical port, two new devlink port flavours are added as
>> PCI PF and PCI VF ports.
>> 
>> A sample eswitch view can be seen below, which will be futher extended to
>> mdev subdevices of a PCI function in future.
>> 
>> Patch-1 moves physical port's attribute to new structure
>> Patch-2 enhances netlink response to consider port flavour
>> Patch-3,4 extends devlink port attributes and port flavour
>> Patch-5 extends mlx5 driver to register devlink ports for PF, VF and
>> physical link.
>
>The coding leaves something to be desired:
>
>1) flavour handling in devlink_nl_port_attrs_put() really calls for a
>   switch statement,
>2) devlink_port_attrs_.*set() can take a pointer to flavour specific
>   structure instead of attr structure for setting the parameters,
>3) the "ret" variable there is unnecessary,
>4) there is inconsistency in whether there is an empty line between
>   if (ret) return; after __devlink_port_attrs_set() and attr setting,
>5) /* Associated PCI VF for of the PCI PF for this port. */ doesn't
>   read great;
>6) mlx5 functions should preferably have an appropriate prefix - f.e.
>   register_devlink_port() or is_devlink_port_supported().
>
>But I'll leave it to Jiri and Dave to decide if its worth a respin :)
>Functionally I think this is okay.
>

I'm happy with the set as it is right now. Anyway, if you want your
concerns to be addresses, you should write them to the appropriate code.
This list is hard to follow.


>Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>