On 3/11/26 4:01 PM, Yanjun.Zhu wrote: > Got it. The commit log explains how the netdev_notifier mechanism is
netdev notifiers are the NETDEV_UNREGISTER and friends. This dellink handler is not related to that; this is an IB stack thing when the rxe link is removed. > used to clean up the related resources. > > In the source code, additional comments have been added to explain how > the dellink operation for rxe is triggered. For iWARP, this change > should not make any difference because iWARP does not implement the > dellink function. > > The commit is shown below. Please take a look and share your comments. > If you agree, I will send out the latest commits out very soon. > > From c05038dcdf69c5985837736a8926ba76d9f3e8e4 Mon Sep 17 00:00:00 2001 > From: Zhu Yanjun <[email protected]> > Date: Fri, 23 Sep 2022 16:52:45 +0000 > Subject: [PATCH 1/1] RDMA/nldev: Add dellink function pointer > > The newlink function pointer was previously added to support > dynamic RDMA link creation. In the RXE driver, this path creates > a transport socket listening on port 4791. Consequently, a dellink > function pointer is required to ensure these sockets are properly > closed when a user administratively removes a link via rdma link > delete <dev>. > > Furthermore, RXE does not rely solely on this nldev path for resource > management. It also monitors the underlying net_device state via a > registered netdev_notifier. The rxe_net_event callback serves as a > fallback mechanism to ensure that transport sockets are forcibly closed > and all resources are released even if dellink is not explicitly called > (e.g., if the parent NIC interface is removed or the driver is forcefully > unloaded). IMHO, this explanation belongs in the patch that implements dellink for rxe. This patch adds the handler to allow link implementations to cleanup any resources created by newklink as needed.
