netdev - Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports

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]

Date:   Tue, 5 Mar 2019 12:09:20 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        oss-drivers@...ronome.com
Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
 ports

Tue, Mar 05, 2019 at 01:51:59AM CET, jakub.kicinski@...ronome.com wrote:
>On Mon, 4 Mar 2019 12:08:57 +0100, Jiri Pirko wrote:
>> Fri, Mar 01, 2019 at 07:04:50PM CET, jakub.kicinski@...ronome.com wrote:
>> >PCI endpoint corresponds to a PCI device, but such device
>> >can have one more more logical device ports associated with it.
>> >We need a way to distinguish those. Add a PCI subport in the
>> >dumps and print the info in phys_port_name appropriately.
>> >
>> >This is not equivalent to port splitting, there is no split
>> >group. It's just a way of representing multiple netdevs on
>> >a single PCI function.
>> >
>> >Note that the quality of being multiport pertains only to
>> >the PCI function itself. A PF having multiple netdevs does
>> >not mean that its VFs will also have multiple, or that VFs
>> >are associated with any particular port of a multiport VF.
>> >
>> >Example (bus 05 device has subports, bus 82 has only one port per
>> >function):  
>> 
>> How do you plan to added/remove these subports?
>
>I can't say I got that figured out fully, but I was wondering if we can
>have some form of:
>
>$ devlink partition pci/0000:82:00.0 new
>pci/0000:82:00.0/1001002

Parav has something similar in his proposal. Lets figure out the
port/non-port dillema first, then we can design this api.


>
>Which would create appropriate sub-port and port (-repr-) netdev.
>
>Plus optionally the ability to work with something like the already
>existing mdev infrastructure for passing to a VM.  But I haven't even
>looked at that, yet.