[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4b6f2e30-5e94-475d-97ec-d59e59f0bf6b@gmail.com>
Date: Sun, 10 Nov 2024 22:42:40 +0200
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
Shuah Khan <shuah@...nel.org>, sd@...asysnail.net,
Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 04/23] ovpn: add basic interface
creation/destruction/management routines
Missed the most essential note regarding this patch :)
On 29.10.2024 12:47, Antonio Quartulli wrote:
> +static int ovpn_net_open(struct net_device *dev)
> +{
> + netif_tx_start_all_queues(dev);
> + return 0;
> +}
> +
> +static int ovpn_net_stop(struct net_device *dev)
> +{
> + netif_tx_stop_all_queues(dev);
Here we stop a user generated traffic in downlink. Shall we take care
about other kinds of traffic: keepalive, uplink?
I believe we should remove all the peers here or at least stop the
keepalive generation. But peers removing is better since
administratively down is administratively down, meaning user expected
full traffic stop in any direction. And even if we only stop the
keepalive generation then peer(s) anyway will destroy the tunnel on
their side.
This way we even should not care about peers removing on the device
unregistering. What do you think?
> + return 0;
> +}
Powered by blists - more mailing lists