Thread (80 messages) 80 messages, 6 authors, 2021-02-05

Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and implement private channel OPs

flat view

From: Jason Gunthorpe <jgg@nvidia.com>
Date: 2021-02-02 23:19:22
Also in: linux-rdma

On Tue, Feb 02, 2021 at 07:42:11PM +0000, Saleem, Shiraz wrote:
quoted
quoted
Only loosely following the arguments here, but one of the requirements
of the driver-op scheme is that the notifying agent needs to know the
target device. With the notifier-chain approach the target device
becomes anonymous to the notifier agent.
Yes, and you need to have an aux device in the first place. The netdev side has
neither of this things. 
But we do. The ice PCI driver is thing spawning the aux device. And
we are trying to do something directed here specifically between the
ice PCI driver and the irdma aux driver.  Seems the notifier chain
approach, from the comment above, is less directed and when you want
to broadcast events from core driver to multiple registered
subscribers.
Yes, generally for good design the net and rdma drivers should be
peers, using similar interfaces, otherwise there will be trouble
answering the question what each peice of code is for, and if a net
change breaks rdma land.
quoted
I think it would be a bit odd to have extensive callbacks that
are for RDMA only, that suggests something in the core API is not general enough.
Yes there are some domain specific ops. But it is within the
boundary of how the aux bus should be used no?
Sure is, but I'm not sure it is a great design of a driver.

In the end I don't care alot about which thing you pick, so long as
the peer layer is fused with aux bus and there isn't a 2nd
registration layer for devices.

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