[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d79c7f3a-c770-4ef5-b9be-20f0c214b09f@habana.ai>
Date: Mon, 24 Jun 2024 07:21:24 +0000
From: Omer Shpigelman <oshpigelman@...ana.ai>
To: Andrew Lunn <andrew@...n.ch>
CC: Sunil Kovvuri Goutham <sgoutham@...vell.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"ogabbay@...nel.org" <ogabbay@...nel.org>,
Zvika Yehudai <zyehudai@...ana.ai>
Subject: Re: [PATCH 06/15] net: hbl_cn: debugfs support
On 6/23/24 18:02, Andrew Lunn wrote:
>>> If there is no netdev, what is the point of putting it into loopback?
>>> How do you send packets which are to be looped back? How do you
>>> receive them to see if they were actually looped back?
>>>
>>> Andrew
>>
>> To run RDMA test in loopback.
>
> What is special about your RDMA? Why do you need something which other
> vendors don't? Please solve this problem for all RDMA devices, not
> yours.
>
> This all part of the same thing with respect to module
> parameters. Vendors would add module parameters for something. Other
> vendors would have the same concept, but give it a different name,
> different values. It was all poorly documented. You had to read the
> kernel sources to figure out what kernel module parameters do. Same
> goes for debugfs, driver values in /proc, /sysfs or /debugfs. So for
> years we have been pushing back on things like this.
>
> If you have something which is unique to your hardware, no other
> vendor is ever going to have the same, then you can make an argument
> for something driver specific in /debugfs. But RDMA loopback tests is
> clearly not specific to your driver. Extend the KAPI and tools to
> cover this, document the KAPI, write the man page, and let other
> vendors implement the little bit they need in their driver, so users
> have a uniform way of doing things over a rather of devices.
>
> You will get a lot of pushback on everything in /debugfs, so please
> review them all with this in mind.
>
> Andrew
I see your point and I'll keep that in mind. For these kinds of
configurations we can use devlink instead of debugfs.
Powered by blists - more mailing lists