Hi Harald, > -----Original Message----- > From: Harald Welte <[email protected]> > Sent: piątek, 11 lutego 2022 10:16 > To: Drewek, Wojciech <[email protected]> > Cc: Marcin Szycik <[email protected]>; [email protected]; > [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > 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 <[email protected]> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)
