linux-kernel - Re: [PATCH 06/15] net: hbl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 23 Jun 2024 06:57:51 +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/21/24 18:33, Andrew Lunn wrote:
>> I see other vendors have debugfs entries for debug configurations or
>> settings, not just for dumping debug info.
> 
> Did you see any added in the last few years? This is also something
> DaveM pushed back on. We want uniform APIs so that all devices look
> alike. Please consider what you are exporting here, how it should
> cleanly fit into ethtool, devlink, etc, and expand these APIs to cover
> your needs.
> 

If it's problematic then I'll try to stick to the ones which expose debug
info and maybe some other necessary debug options e.g. loopback. I'll try
to minimize by removing anything that is not mandatory.

>>
>>>> +What:           /sys/kernel/debug/habanalabs_cn/hbl_cn<n>/nic_mac_loopback
>>>
>>> Why not use ethtool ?
>>>
>>
>> We have an ethtool option for that, but we have also internal NIC ports
>> that are not exposed as netdevices and for them the ethtool path is
>> irrelevant. Hence we need this debugfs option as well.
> 
> 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. That's how we can pinpoint problems like
packet drops or performance degradation. For example, if packet drops were
seen on the port then it is crucial to know if these drops are
reproducible in loopback mode. If they are, then the root cause is
probably some internal HW failure or misconfiguration. If not, then the
packet drops might be related to the link quality.
We send these packets by setting a loopback bypass in the MAC layer. The
packets themselves and the NIC HW logic are agnostic to the loopback
setting (except of the packet's MAC address).
We receive and validate them and in the same way we receive and validate
regular packets - the loopback bypass is in the MAC layer which is in a
lower layer than our NIC HW logic.