lkml.org 
[lkml]   [2021]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC net-next 0/8] Introducing subdev bus and devlink extension
    Date


    > From: Yunsheng Lin <linyunsheng@huawei.com>
    > Sent: Thursday, June 10, 2021 12:34 PM
    >
    > On 2021/6/9 21:45, Parav Pandit wrote:
    > >> From: Yunsheng Lin <linyunsheng@huawei.com>
    > >> Sent: Wednesday, June 9, 2021 6:00 PM
    > >>
    > >> On 2021/6/9 19:59, Parav Pandit wrote:
    > >>>> From: Yunsheng Lin <linyunsheng@huawei.com>
    > >>>> Sent: Wednesday, June 9, 2021 4:35 PM
    > >>>>
    > >>>> On 2021/6/9 17:38, Parav Pandit wrote:
    > >>>>>
    > >>>>>> From: Yunsheng Lin <linyunsheng@huawei.com>
    > >>>>>> Sent: Wednesday, June 9, 2021 2:46 PM
    > >>>>>>
    > >>>>> [..]
    > >>>>>
    > >>>>>>>> Is there any reason why VF use its own devlink instance?
    > >>>>>>>
    > >>>>>>> Primary use case for VFs is virtual environments where guest
    > >>>>>>> isn't trusted, so tying the VF to the main devlink instance,
    > >>>>>>> over which guest should have no control is counter productive.
    > >>>>>>
    > >>>>>> The security is mainly about VF using in container case, right?
    > >>>>>> Because VF using in VM, it is different host, it means a
    > >>>>>> different devlink instance for VF, so there is no security issue
    > >>>>>> for VF using in VM
    > >>>> case?
    > >>>>>> But it might not be the case for VF using in container?
    > >>>>> Devlink instance has net namespace attached to it controlled using
    > >>>>> devlink
    > >>>> reload command.
    > >>>>> So a VF devlink instance can be assigned to a container/process
    > >>>>> running in a
    > >>>> specific net namespace.
    > >>>>>
    > >>>>> $ ip netns add n1
    > >>>>> $ devlink dev reload pci/0000:06:00.4 netns n1
    > >>>>> ^^^^^^^^^^^^^
    > >>>>> PCI VF/PF/SF.
    > >>>>
    > >>>> Could we create another devlink instance when the net namespace of
    > >>>> devlink port instance is changed?
    > >>> Net namespace of (a) netdevice (b) rdma device (c) devlink instance
    > >>> can be
    > >> changed.
    > >>> Net namespace of devlink port cannot be changed.
    > >>
    > >> Yes, net namespace is changed based on the devlink instance, not
    > >> devlink port instance, *right now*.
    > >>
    > >>>
    > >>>> It may seems we need to change the net namespace based on devlink
    > >>>> port instance instead of devlink instance.
    > >>>> This way container case seems be similiar to the VM case?
    > >>> I mostly do not understand the topology you have in mind or if you
    > >> explained previously I missed the thread.
    > >>> In your case what is the flavour of a devlink port?
    > >>
    > >> flavour of the devlink port instance is FLAVOUR_PHYSICAL or
    > >> FLAVOUR_VIRTUAL.
    > >>
    > >> The reason I suggest to change the net namespace on devlink port
    > >> instance instead of devlink instance is:
    > >> I proposed that all the PF and VF in the same ASIC are registered to
    > >> the same devlink instance as flavour FLAVOUR_PHYSICAL or
    > >> FLAVOUR_VIRTUAL when there are in the same host and in the same net
    > namespace.
    > >>
    > >> If a VF's devlink port instance is unregistered from old devlink
    > >> instance in the old net namespace and registered to new devlink
    > >> instance in the new net namespace(create a new devlink instance if
    > >> needed) when devlink port instance's net namespace is changed, then
    > >> the security mentioned by jakub is not a issue any more?
    > >
    > > It seems that devlink instance of VF is not needed in your case, and if so
    > what is the motivation to even have VIRTUAL port attach to the PF?
    >
    > The devlink instance is mainly used to hold the devlink port instance of VF if
    > there is only one VF in vm, we might still need to have param/health specific
    > to the VF to registered to the devlink port instance of that VF.
    >
    This will cover things uniformly with/without container or VM.

    > > If only netdevice of the VF is of interest, it can be assigned to net
    > namespace directly.
    >
    > I think that is another option, if there is nothing in the devlink port instance
    > specific to VF that need exposing to the user in another net namespace.
    >
    Yes. no need for devlink instance or devlink port.

    > >
    > > It doesn’t make sense to me to create new devlink instance in new net
    > namespace, that also needs to be deleted when net ns is deleted.
    > > And pre_exit() routine will mostly deadlock holding global devlink_mutex.
    >
    > Would you be more specific why there is deadlock?
    Net namespace exit routine cannot invoke a devlink API that demands acquiring devlink global mutex.
    \
     
     \ /
      Last update: 2021-06-10 09:17    [W:4.139 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site