11 Feb
2022
11 Feb
'22
1:48 p.m.
Hi Harald
-----Original Message-----
From: Drewek, Wojciech
Sent: piątek, 11 lutego 2022 11:27
To: Harald Welte <laforge(a)osmocom.org>
Cc: Marcin Szycik <marcin.szycik(a)linux.intel.com>om>; netdev(a)vger.kernel.org;
michal.swiatkowski(a)linux.intel.com;
davem(a)davemloft.net; kuba(a)kernel.org; pablo(a)netfilter.org;
osmocom-net-gprs(a)lists.osmocom.org
Subject: RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response
Hi Harald,
I have one question. The new cmd should be allowed to send echo request
only to the peers stored in the kernel space (PDP contexts) or the userspace
daemon has its own list of peers and any request should be allowed to be send?
Regards,
Wojtek
-----Original Message-----
From: Harald Welte <laforge(a)osmocom.org>
Sent: piątek, 11 lutego 2022 10:16
To: Drewek, Wojciech <wojciech.drewek(a)intel.com>
Cc: Marcin Szycik <marcin.szycik(a)linux.intel.com>om>; netdev(a)vger.kernel.org;
michal.swiatkowski(a)linux.intel.com;
davem(a)davemloft.net; kuba(a)kernel.org; pablo(a)netfilter.org;
osmocom-net-gprs(a)lists.osmocom.org
Subject: Re: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response
Hi Wojciech,
On Tue, Feb 08, 2022 at 02:12:33PM +0000, Drewek, Wojciech wrote:
Interesting proposal. However, it raises the next question of what to do if
the path is deemed to be lost (N out of M recent echo requests unanswered)? It
would have to notify the userspace daemon (control plane) via a netlink event
or the like. So at that point you need to implement some special processing in
that userspace daemon...
I agree that second option is better so I'll start to implementing it.
Remember,
GTP-U uses different IP addresses and also typically completely
different hosts/systems, so having GTP-C connectivity between two GSN
doesn't say anything about the GTP-U path.
Two approaches come to mind.
The first one assumes that peers are stored in kernel as PDP contexts in
gtp_dev (tid_hash and addr_hash). Then we could enable a watchdog
that could in regular intervals (defined by the user) send echo requests
to all peers. In the second one user could trigger echo request
from userspace
(using new genl cmd) at any time. However this approach would require that
some userspace daemon would implement triggering this command.
I think this is the better approach. It keeps a lot of logic like timeouts,
frequency of transmission, determining when a path is considered dead, ... out
of the kernel, where it doesn't need to be.
What do you think?
As both approaches require some support from the userspace control plane instance,
I would argue that the second proposal is superior.
Regards,
Harald
Regards,
Wojtek
>
> --
> - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)