All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@idosch.org>
To: Martin Zaharinov <micron10@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>, netdev <netdev@vger.kernel.org>
Subject: Re: Very slow remove interface from kernel
Date: Tue, 9 May 2023 23:08:20 +0300	[thread overview]
Message-ID: <ZFqoNJqwLjaVFGaa@shredder> (raw)
In-Reply-To: <FE7CE62C-DBEB-4FE1-8ACB-C8B7DAF15710@gmail.com>

On Tue, May 09, 2023 at 09:50:18PM +0300, Martin Zaharinov wrote:
> i try on kernel 6.3.1 
> 
> 
> time for i in $(seq 2 4094); do ip link del link eth1 name vlan$i type vlan id $i; done
> 
> real	4m51.633s  —— here i stop with Ctrl + C  -  and rerun  and second part finish after 3 min
> user	0m7.479s
> sys	0m0.367s

You are off-CPU most of the time, the question is what is blocking. I'm
getting the following results with net-next:

# time -p for i in $(seq 2 4094); do ip link del dev eth0.$i; done
real 177.09
user 3.85
sys 31.26

When using a batch file to perform the deletion:

# time -p ip -b vlan_del.batch 
real 35.25
user 0.02
sys 3.61

And to check where we are blocked most of the time while using the batch
file:

# ../bcc/libbpf-tools/offcputime -p `pgrep -nx ip`
[...]
    __schedule
    schedule
    schedule_timeout
    wait_for_completion
    rcu_barrier
    netdev_run_todo
    rtnetlink_rcv_msg
    netlink_rcv_skb
    netlink_unicast
    netlink_sendmsg
    ____sys_sendmsg
    ___sys_sendmsg
    __sys_sendmsg
    do_syscall_64
    entry_SYSCALL_64_after_hwframe
    -                ip (3660)
        25089479
[...]

We are blocked for around 70% of the time on the rcu_barrier() in
netdev_run_todo().

Note that one big difference between my setup and yours is that in my
case eth0 is a dummy device and in your case it's probably a physical
device that actually implements netdev_ops::ndo_vlan_rx_kill_vid(). If
so, it's possible that a non-negligible amount of time is spent talking
to hardware/firmware to delete the 4K VIDs from the device's VLAN
filter.

> 
> 
> Config is very clean i remove big part of CONFIG options .
> 
> is there options to debug what is happen.
> 
> m

  reply	other threads:[~2023-05-09 20:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  8:22 Very slow remove interface from kernel Martin Zaharinov
2023-05-09 10:20 ` Ido Schimmel
2023-05-09 10:32   ` Eric Dumazet
2023-05-09 11:10     ` Martin Zaharinov
2023-05-09 12:36       ` Eric Dumazet
2023-05-09 18:50         ` Martin Zaharinov
2023-05-09 20:08           ` Ido Schimmel [this message]
2023-05-09 20:16             ` Martin Zaharinov
2023-05-10  5:31             ` Martin Zaharinov
2023-05-10  6:06             ` Martin Zaharinov
2023-05-10  9:40               ` Eric Dumazet
2023-05-10 13:15                 ` Martin Zaharinov
2023-05-25  7:50                 ` Martin Zaharinov
2023-05-10  9:16             ` Martin Zaharinov
2023-05-10  9:22               ` Eric Dumazet
2023-05-09 20:08         ` Martin Zaharinov

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=ZFqoNJqwLjaVFGaa@shredder \
    --to=idosch@idosch.org \
    --cc=edumazet@google.com \
    --cc=micron10@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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.