Messages in this thread | | | Date | Tue, 2 Apr 2024 15:45:54 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver |
| |
On Mon, Apr 01, 2024 at 07:50:03AM -0700, Jakub Kicinski wrote: > On Mon, 1 Apr 2024 15:30:03 +0300 Leon Romanovsky wrote: > > > The proposal is an attempt at a common interface and common tooling to a > > > degree but independent of any specific subsystem of which many are > > > supported by the device. > > > > > > Your responses continue to align with the notion that because the device > > > can spit out ethernet frames, all diagnostics, debugging, configuration, > > > etc. MUST go through networking APIs. > > > > > > You seem unwilling to acknowledge that devices can work for various use > > > cases without a netdev driver, and thus aspects of managing that device > > > should be done outside of a netdev driver. > > > > HNS driver is a good example of such device. It has nothing to do with > > netdev and needs common and reliable way to configure FW. > > Sorry, I have a completely different reading of that thread. > Thanks for bringing it up, tho. > > As I said multiple times I agree that configuring custom parameters > in RDMA is a necessity. Junxian's approach of putting such code in > the RDMA driver / subsystem is more than reasonable. Even better, > it looks like the API is fairly narrowly defined.
Uh, if I understand netdev rules aren't read/write sysfs created from drivers banned?
So reasonable for RDMA but unacceptable to netdev? My brain hurts.
FWIW, I've been trying to push RDMA away from driver created sysfs for a while now. Aside from the API complexity, implementations have messed up using the sysfs APIs and resulted in some significant problems :(
Jason
| |