Thread (51 messages) 51 messages, 4 authors, 2020-04-28

RE: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework definitions

flat view

From: Saleem, Shiraz <hidden>
Date: 2020-04-23 23:54:21
Also in: linux-rdma

Subject: Re: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework
definitions

On Thu, Apr 23, 2020 at 05:15:22PM +0000, Saleem, Shiraz wrote:
quoted
quoted
Subject: Re: [RFC PATCH v5 01/16] RDMA/irdma: Add driver framework
definitions

On Thu, Apr 23, 2020 at 12:32:48AM +0000, Saleem, Shiraz wrote:
quoted
we have a split initialization design for gen2 and future products.
phase1 is control path resource initialization in irdma_probe_dev
and
phase-2 is the rest of the resources with the ib registration at
the end of irdma_open. irdma_close must de-register the ib device
which will take care of ibdev free too. So it makes sense to keep
allocation of the ib device in irdma_open.
The best driver pattern is to allocate the ib_device at the very
start of probe() and use this to anchor all the device resources and memories.

The whole close/open thing is really weird, you should get rid of it.
maybe I missing something. But why is it weird?
Because the RDMA driver should exist as its own entity. It does not shutdown
unless the remove() method on is struct device_driver is closed.
So what exactly are open/cose supposed to be doing? I think it is a left over of
trying to re-implement the driver model.
quoted
underlying configuration changes and reset management for the physical
function need a light-weight mechanism which is realized with the
close/open from netdev PCI drv --> rdma drv.
quoted
Without a teardown and re-add of virtual device off the bus.
Yes, that is exactly right. If you have done something so disruptive that the
ib_device needs to be destroyed then you should unplug/replug the entire virtual
bus device, that is the correct and sane thing to do.
Well we have resources created in rdma driver probe which are used by any
VF's regardless of the registration of the ib device on the PF.
So doing a virtbus device unregister here for underlying config changes
is more destructive than it needs to be as will trigger the remove()
and blow out those resources too.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help