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]

Message-ID: <4436da3d-4b99-f792-8e77-695d5958794d@intel.com>
Date:   Thu, 14 Mar 2019 19:15:50 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Parav Pandit <parav@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
 ports



On 3/14/2019 6:28 PM, Parav Pandit wrote:
> 
> 
>> -----Original Message-----
>> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
>> Sent: Thursday, March 14, 2019 6:39 PM
>> To: Parav Pandit <parav@...lanox.com>
>> Cc: Jiri Pirko <jiri@...nulli.us>; 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
>>
>> On Thu, 14 Mar 2019 22:35:36 +0000, Parav Pandit wrote:
>>>>> Then instances of flavour pci_vf are going to appear in the same
>>>>> devlink instance. Those are the switch ports:
>>>>> pci/0000:05:00.0/10002: type eth netdev enp5s0npf0pf0s0
>>>>>                          flavour pci_vf pf 0 vf 0
>>>>>                          switch_id 00154d130d2f peer
>>>>> pci/0000:05:10.1/0
>>>>> pci/0000:05:00.0/10003: type eth netdev enp5s0npf0pf0s0
>>>>>                          flavour pci_vf pf 0 vf 0 subport 1
>>>>>                          switch_id 00154d130d2f peer
>>>>> pci/0000:05:10.1/1
>>>>>
>>>>> With that, peers are going to appear too, and those are the actual
>>>>> VF/VF
>>>>> subport:
>>>>> pci/0000:05:10.1/0: type eth netdev ??? flavour pci_vf_host
>>>>>                      peer pci/0000:05:00.0/10002
>>>>> pci/0000:05:10.1/1: type eth netdev ??? flavour pci_vf_host
>>>>>                      peer pci/0000:05:00.0/10003
>>>>>
>>>>> Later you can push this VF along with all subports to VM. So in
>>>>> VM, you are going to see the VF like this:
>>>>> $ devlink dev
>>>>> pci/0000:00:08.0
>>>>> $ devlink port
>>>>> pci/0000:00:08.0/0: type eth netdev ??? flavour pci_vf_host
>>>>> pci/0000:00:08.0/1: type eth netdev ??? flavour pci_vf_host
>>>>>
>>>>> And back to your question of how are they connected in eswitch.
>>>>> That is totally up to the original user John who did the creation.
>>>>> He is in charge of the eswitch on baremetal, he would configure
>>>>> the forwarding however he likes.
>>>>
>>>> Ack, so I think you're saying VM has to communicate to the cloud
>>>> environment to have this provisioned using some service API, not a
>>>> kernel API.  That's what I wanted to confirm.
>>>>
>>>> I don't see any benefit to having the "host ports" under devlink, as such I
>>>> think it's a matter of preference.
>>>
>>> We need 'host ports' to configure parameters of this host port which
>>> is not exposed by the rep-netdev.
>>> Such as mac address.
>>
>> Please look at the quote of what Jiri wrote above - the host port gets passed
>> to the VM, you can't use it as a handle to set the MAC.
>>
>> The way to set the MAC remains:
>>
>> # devlink port set pci/0000:05:00.0/10002 peer mac_addr 00:11:22:33:44:55
>>
> Even though it can be done, I think this is wrong model to program hostport mac address using eswitch port.
> All devlink objects are control objects, so what is passed to VM is what is represented by devlink.
> VF in the VM will anyway create its devlink object.
> What is wrong in programming hostport?
> It gives a very clear view to users of topology and objects.

The VF or any subport MAC address should be configured by the 
orchestration layer that is running on the hypervisor and when a VF is 
assigned to a VF, the host port is not visible to the hypervisor.
Currently we have ndo_set_vf_mac_addr api that works with PF netdev, but 
i think we are trying to move away from that API and do all the 
configuration via the port representor netdevs. As the mac address 
cannot be configured using this netdev, i think Jakub is suggesting 
creating a devlink opject for each port representor and use that 
interface to set peer mac address. We should be able use this to 
configure port vlan too.

Also, instead of subport, can we call vport and support different types 
of vports - sr-iov, siov, vmdq etc.

> 
> Also eswitch is flat. There is no need of pf/vf flavour for port.
> It doesn't make sense to define 'mdev' flavour which we are already working.
> At eswitch level it is just a port, it happen to be connected to vf or pf or other objects, it doesn't matter.
> Port should be flavoured as 'hostport' or 'switchport'.
> 
> 
>> (using the port ids from above)