On Tue, Mar 12, 2024 at 10:05:22AM +0200, Leon Romanovsky wrote: > On Mon, Mar 11, 2024 at 10:00:27PM +0800, Junxian Huang wrote: > > > > > > On 2024/3/11 15:11, Leon Romanovsky wrote: > > > On Mon, Mar 11, 2024 at 10:00:51AM +0800, Junxian Huang wrote: > > >> > > >> > > >> On 2024/3/10 18:00, Leon Romanovsky wrote: > > >>> On Fri, Mar 08, 2024 at 06:54:43PM +0800, Junxian Huang wrote: > > >>>> From: Chengchang Tang <tangchengchang@xxxxxxxxxx> > > >>>> > > >>>> hns RoCE supports 4 congestion control algorithms. Each algorihm > > >>>> involves multiple parameters. Add port sysfs directory for each > > >>>> algorithm to allow modifying their parameters. > > >>> > > >>> Unless Jason changed his position after this rewrite [1], we don't allow > > >>> any custom driver sysfs code. > > >>> > > >>> [1] https://lore.kernel.org/all/cover.1623427137.git.leonro@xxxxxxxxxx/ > > >>> > > >> > > >> I didn't quite get the reason from [1], could you please explain it? > > > > > > Before [1], we didn't allow custom sysfs. After [1], the sysfs code > > > started to be more sane and usable for the drivers. However, it is > > > unlikely that the policy is changed to allow driver sysfs code. > > > > > >> > > >> And it would be helpful if you could give us a hint about any other > > >> proper ways to do the algorithm parameter configuration. > > > > > > Like any other FW internals. > > > > > > > If we add the capability of custom driver parameter configuration to > > rdmatool (similar to [2]), would it be acceptable? > > Moshe's patch is for devlink. We are working on a generic solution for > other vendors to control/debug their devices. > https://lwn.net/Articles/955001/ > https://lore.kernel.org/all/20240304160237.GA2909161@xxxxxxxxxx/ > > Feel free to join the discussion and reply that you are interested in > this proposal as well and emphasize that your device is not netdev at > all. Yeah, I'm kind of expecting that all RDMA devices are going to need something like fwctl for exactly reasons like this. Adding a special driver sysfs is, IMHO, worse than just exposing a driver specific sysfs. hns looks like it would fit nicely into that scheme as it has a clean fw RPC interface - indeed this is just welding the FW RPC to sysfs.. Congestion control does seem like it could have some sensible commonality, but there are so many different takes on it and many people are not doing per-port stuff but per-device or per-qp variations, so I'm not really sure. I wish there was more industry standards here.. Anyhow, feel free to respond in that thread that hns is also interested, thanks Jason
