Hi Harald,
-----Original Message----- From: Harald Welte laforge@osmocom.org Sent: piątek, 11 lutego 2022 10:16 To: Drewek, Wojciech wojciech.drewek@intel.com Cc: Marcin Szycik marcin.szycik@linux.intel.com; netdev@vger.kernel.org; michal.swiatkowski@linux.intel.com; davem@davemloft.net; kuba@kernel.org; pablo@netfilter.org; osmocom-net-gprs@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:
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.
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...
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
I agree that second option is better so I'll start to implementing it.
Regards, Wojtek
--
- Harald Welte laforge@osmocom.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)