Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 1 Apr 2024 21:10:33 +0300 | From | Leon Romanovsky <> | 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.
Different people have different opinions, and it is fine.
> > 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.
It was a tiny example, which emphasizes the need for a common way.
If we were listen to average RDMA driver author, we would find ourselves with gazillion different sysfs knobs which do nothing except sending raw data to FW. As a subsystem, we don't want to waste our time in not-beneficial to the subsystem code.
Thanks
| ![\](/images/icornerr.gif) |