[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f2333fb-707a-4d21-a32d-776489ddc343@davidwei.uk>
Date: Tue, 28 Oct 2025 15:41:55 -0700
From: David Wei <dw@...idwei.uk>
To: Jakub Kicinski <kuba@...nel.org>, Daniel Borkmann <daniel@...earbox.net>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, davem@...emloft.net,
 razor@...ckwall.org, pabeni@...hat.com, willemb@...gle.com, sdf@...ichev.me,
 john.fastabend@...il.com, martin.lau@...nel.org, jordan@...fe.io,
 maciej.fijalkowski@...el.com, magnus.karlsson@...el.com, toke@...hat.com,
 yangzhenze@...edance.com, wangdongdong.6@...edance.com
Subject: Re: [PATCH net-next v3 02/15] net: Implement
 netdev_nl_bind_queue_doit
On 2025-10-23 19:28, Jakub Kicinski wrote:
> On Mon, 20 Oct 2025 18:23:42 +0200 Daniel Borkmann wrote:
>> +void netdev_rx_queue_peer(struct net_device *src_dev,
>> +			  struct netdev_rx_queue *src_rxq,
>> +			  struct netdev_rx_queue *dst_rxq)
>> +{
>> +	netdev_assert_locked(src_dev);
>> +	netdev_assert_locked(dst_rxq->dev);
>> +
>> +	netdev_hold(src_dev, &src_rxq->dev_tracker, GFP_KERNEL);
> 
> Isn't ->dev_tracker already used by sysfs?
You're right, it is. Can netdevice_tracker not be shared?
> 
> Are you handling the underlying device going away?
Ah, good point, no we're not handling that right now. Reading the code
and intuitively, it doesn't look like holding the netdev refc will
prevent something like unplugging the device...
I take it an unregistration notifier e.g. xsk_notifier() is the way to
handle it?
> 
>> +	__netdev_rx_queue_peer(src_rxq, dst_rxq);
>> +}
Powered by blists - more mailing lists
 
