From: David Ahern <dsahern@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Lahav Schlesinger <lschlesinger@drivenets.com>,
netdev@vger.kernel.org, nikolay@nvidia.com
Subject: Re: [PATCH net-next v5] rtnetlink: Support fine-grained netdevice bulk deletion
Date: Wed, 8 Dec 2021 17:18:48 -0700 [thread overview]
Message-ID: <7ae281fa-3d05-542f-941c-ba86bd35c31e@gmail.com> (raw)
In-Reply-To: <20211208160405.18c7d30f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 12/8/21 5:04 PM, Jakub Kicinski wrote:
> On Wed, 8 Dec 2021 16:43:28 -0700 David Ahern wrote:
>> On 12/8/21 2:47 PM, Lahav Schlesinger wrote:
>>> No visible changes from what I saw, this API is as fast as group
>>> deletion. Maybe a few tens of milliseconds slower, but it's lost in the
>>> noise.
>>> I'll run more thorough benchmarks to get to a more conclusive conclusion.
>>>
>>> Also just pointing out that the sort will be needed even if we pass an
>>> array (IFLA_IFINDEX_LIST) instead.
>>> Feels like CS 101, but do you have a better approach for detecting
>>> duplicates in an array? I imagine a hash table will be slower as it will
>>> need to allocate a node object for each device (assuming we don't want
>>> to add a new hlist_node to 'struct net_device' just for this)
>>
>> I think marking the dev's and then using a delete loop is going to be
>> the better approach - avoid the sort and duplicate problem. I use that
>> approach for nexthop deletes:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/net/ipv4/nexthop.c#n1849
>>
>> Find a hole in net_device struct in an area used only for control path
>> and add 'bool grp_delete' (or a 1-bit hole). Mark the devices on pass
>> and delete them on another.
>
> If we want to keep state in the netdev itself we can probably piggy
> back on dev->unreg_list. It should be initialized to empty and not
> touched unless device goes thru unregister.
>
isn't that used when the delink function calls unregister_netdevice_queue?
next prev parent reply other threads:[~2021-12-09 0:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-05 9:36 [PATCH net-next v5] rtnetlink: Support fine-grained netdevice bulk deletion Lahav Schlesinger
2021-12-05 10:28 ` Nikolay Aleksandrov
2021-12-06 8:25 ` Nicolas Dichtel
2021-12-06 15:20 ` David Ahern
2021-12-07 8:27 ` Nicolas Dichtel
2021-12-07 12:48 ` Lahav Schlesinger
2021-12-08 7:44 ` Nicolas Dichtel
2021-12-07 4:12 ` David Ahern
2021-12-07 15:37 ` Jakub Kicinski
2021-12-08 21:50 ` Lahav Schlesinger
2021-12-08 21:47 ` Lahav Schlesinger
2021-12-08 23:43 ` David Ahern
2021-12-09 0:04 ` Jakub Kicinski
2021-12-09 0:18 ` David Ahern [this message]
2021-12-09 0:45 ` Jakub Kicinski
2021-12-09 0:47 ` David Ahern
2022-01-04 8:21 ` Lahav Schlesinger
2022-01-04 14:55 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ae281fa-3d05-542f-941c-ba86bd35c31e@gmail.com \
--to=dsahern@gmail.com \
--cc=kuba@kernel.org \
--cc=lschlesinger@drivenets.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.