RE: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv

["Saleem, Shiraz" <shiraz.saleem@intel.com>]

>Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct
>i40e_netdev_priv
>
>On Fri, Feb 15, 2019 at 11:10:48AM -0600, Shiraz Saleem wrote:
>> Expose the register/unregister function pointers in the struct
>> i40e_netdev_priv which is accesible via the netdev_priv() interface in
>> the RDMA driver. On a netdev notification in the RDMA driver, the
>> appropriate LAN driver register/unregister functions are invoked from
>> the struct i40e_netdev_priv structure,
>
>Why? In later patches we get an entire device_add() based thing. Why do you
>need two things?
>
>The RDMA driver should bind to the thing that device_add created and from there
>reliably get the netdev. It should not listen to netdev notifiers for attachment.

In the new IDC mechanism between ice<->irdma, the LAN driver setups up the
device for us and attaches it to a software bus via device_add() based mechanism.
However, RDMA driver binds to the device only when the LAN 'register' function is
called in irdma. In order to do a unified RDMA driver, this register function is exposed
in the private netdev struct of each LAN driver, so we need a matching LAN driver
netdev (ice or i40e) in irdma to call the 'register' function in the first place.
.
Once the binding is done, the bus infrastructure triggers the probe() for the device
into the 'ice' driver and it in turn calls the irdma probe() where we can get also get
the netdev like your referring to. But there is no software bus object or device the
RDMA driver can bind to without a matching LAN driver being loaded and calling its
register. 

There is no ordering guarantee in which irdma, i40e and ice modules load.
The netdev notifier is for the case where the irdma loads before i40e or ice.
The irdma driver listen to the notifiers so that when a supporting LAN drivers netdev
appears (on load), it can register with it.

Shiraz