[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bd834ad7-b06e-69f0-40a6-5f4a21a1eba2@6wind.com>
Date: Wed, 26 Aug 2020 09:47:54 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Harald Welte <laforge@...monks.org>
Cc: davem@...emloft.net, kuba@...nel.org, pablo@...filter.org,
osmocom-net-gprs@...ts.osmocom.org, netdev@...r.kernel.org,
Gabriel Ganne <gabriel.ganne@...nd.com>
Subject: Re: [PATCH net-next v2] gtp: add notification mechanism
Le 25/08/2020 à 19:01, Harald Welte a écrit :
> Hi Nicolas,
>
> thanks a lot for your patch.
>
> On Tue, Aug 25, 2020 at 05:57:15PM +0200, Nicolas Dichtel wrote:
>> Like all other network functions, let's notify gtp context on creation and
>> deletion.
>
> While this may be in-line with typical kernel tunnel device practises, I am not
> convinced it is the right way to go for GTP.
>
> Contrary to other tunneling mechansims, GTP doesn't have a 1:1 rlationship between
> tunnels and netdev's. You can easily have tens of thousands - or even many more -
> PDP contexts (at least one per subscriber) within one "gtp0" netdev. Also, the state
> is highly volatile. Every time a subscriber registers/deregisters, goes in or out of
> coverage, in or out of airplane mode, etc. those PDP contexts go up and down.
>
> Sending (unsolicited) notifications about all of those seems quite heavyweight to me.
There is no 'unsolicited' notifications with this patch. Notifications are sent
only if a userspace application has subscribed to the gtp mcast group.
ip routes or conntrack entries are notified in the same way and there could a
lot of them also (more than 100k conntrack entries for example).
Powered by blists - more mailing lists