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.
