Received-SPF: pass (google.com: domain of linux-kernel+bounces-99356-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 11 Mar 2024 11:25:32 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Breno Leitao <leitao@debian.org>, Dennis Dalessandro
 <dennis.dalessandro@cornelisnetworks.com>, Jason Gunthorpe <jgg@ziepe.ca>,
 keescook@chromium.org, "open list:HFI1 DRIVER"
 <linux-rdma@vger.kernel.org>, open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] IB/hfi1: allocate dummy net_device dynamically
Message-ID: <20240311112532.71f1cb35@kernel.org>
In-Reply-To: <20240311102251.GJ12921@unreal>
References: <20240308182951.2137779-1-leitao@debian.org>
	<20240310101451.GD12921@unreal>
	<Ze7YNu5TrzClQcxy@gmail.com>
	<20240311102251.GJ12921@unreal>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 11 Mar 2024 12:22:51 +0200 Leon Romanovsky wrote:
> > From my experience, you can leverage all the helpers to deal with the
> > relationship between struct net_device and you private structure. Here
> > are some examples that comes to my mind:
> > 
> > * alloc_netdev() allocates the private structure for you
> > * netdev_priv() gets the private structure for you
> > * dev->priv_destructor sets the destructure to be called when the
> >   interface goes away or failures.  
> 
> Everything above is true, but it doesn't relevant to HFI1 devices which
> are not netdev devices.

Why are they abusing struct net_device then?
If you're willing to take care of removing the use of NAPI from this
driver completely, that'd be great.

> > > Will it create multiple "dummy" netdev in the system? Will all devices
> > > have the same "dummy" name?  
> > 
> > Are these devices visible to userspace?  
> 
> HFI devices yes, dummy device no.
> 
> > 
> > This allocation are using NET_NAME_UNKNOWN, which implies that the
> > device is not expose to userspace.  
> 
> Great
> 
> > 
> > Would you prefer a different name?  
> 
> I prefer to see some new wrapper over plain alloc_netdev, which will
> create this dummy netdevice. For example, alloc_dummy_netdev(...).

Nope, no bona fide APIs for hacky uses.