Hi Jonas, On Mon, Feb 06, 2017 at 02:33:07PM +0100, Jonas Bonn wrote: > Hi Pablo, > > On 02/06/2017 12:08 PM, Pablo Neira Ayuso wrote: > >Hi Jonas, > > > >On Fri, Feb 03, 2017 at 10:12:31AM +0100, Jonas Bonn wrote: > >>The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP > >>contexts based on the incoming packets _destination_ address. If we > >>want to write an SGSN, then we want to be idenityfing PDP contexts > >>based on _source_ address. > >> > >>This patch adds a "flags" argument at GTP-link creation time to specify > >>whether we are on the GGSN or SGSN side of the tunnel; this flag is then > >>used to determine which part of the IP packet to use in determining > >>the PDP context. > >So far the implementation that I saw in osmocom relies on userspace code > >to tunnel data from ME to the SSGN/SGW running on the base station. > > > >The data we get from GGSN -> SGSN needs to be places into a SN-PDU (via > >SNDCP) when sending it to the BTS, right? So I wonder how this can be > >useful given that we would need to see real IP packets coming to the > >SSGN that we tunnel into GTP. > > Fair enough. The use-case I am looking at involves PGW load-testing where > the simulated load is generated locally on the SGSN so it _is_ seeing IP > packets and the SNDCP is left out altogether. Perhaps this is too > pathological to warrant messing with the upstream driver... I don't know: > the symmetry does not cost much even if it's of limited use.
Thanks for explaining your use-case. If some basic form of this load-testing tool ends up serving everyone, ie. landing some code in the libgtpnl library that we can all use to benchmark/stress test this driver, then I would be glad to take this. Thanks!
