netdev - Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 10 May 2019 15:17:17 -0300
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Shiraz Saleem <shiraz.saleem@...el.com>
Cc:     "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "Ertman, David M" <david.m.ertman@...el.com>,
        "dledford@...hat.com" <dledford@...hat.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Ismail, Mustafa" <mustafa.ismail@...el.com>,
        "Patil, Kiran" <kiran.patil@...el.com>
Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
 i40e_netdev_priv

On Fri, May 10, 2019 at 08:31:02AM -0500, Shiraz Saleem wrote:
> On Wed, Mar 13, 2019 at 07:28:41AM -0600, Jason Gunthorpe wrote:
> > 
> > > > Register a device driver to the driver core and wait for the driver
> > > > core to call that driver's probe method.
> > > 
> > > Yes, the LAN PF driver is the software component exposing and managing the
> > > bus, so it is the one who will call probe/remove of the peer driver (RDMA
> > > driver).  Although netdev notifiers based approach is needed if the RDMA
> > > driver was loaded first before the LAN PF driver (i40e or ice) is loaded.
> > 
> > Why would notifiers be needed? Driver core handles all these ordering
> > things. If you have a device_driver with no device it waits until a
> > device gets plugged in to call probe.
> > 
> 
> Hi Jason - Your feedback here is much appreciated and we have revisited our design based on it.
> The platform driver/device model is a good fit for us with the addition of RDMA capable devices
> to the virtual platform bus. Here are the highlights of design and how they address your concerns.
> 
> (1) irdma driver registers itself as a platform driver with its own probe()/remove() routines.
>     It will support RDMA capable platform devices from different Intel HW generations. 
> (2) The intel net driver will register RDMA capable devices on the platform bus.
> (3) Exposing a virtual bus type in the netdev driver is redundant and thus removed.
>     Additionally, it would require the bus object to be exported in order for irdma to register,
>     which doesnt allow irdma to be unified. 
> (4) In irdma bus probe(), we are able to reach each platform dev's associated net-specific
>     data including the netdev. 
> (5) There are no ordering dependencies between net-driver and irdma since it's managed by driver
>     core as you stated. Listening to netdev notifiers for attachment is no longer required and
>     thus removed.

This sounds a bount right, but you will want to run these details by
Greg KH. I think he will tell you to use the multi-function device
stuff, not a platform device.

Jason