From: Harald Welte <laforge@gnumonks.org>
To: "Drewek, Wojciech" <wojciech.drewek@intel.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"michal.swiatkowski@linux.intel.com"
<michal.swiatkowski@linux.intel.com>,
Marcin Szycik <marcin.szycik@linux.intel.com>
Subject: Re: PFCP support in kernel
Date: Thu, 10 Mar 2022 18:48:47 +0100 [thread overview]
Message-ID: <Yio5/+Ko77tu4Vi6@nataraja> (raw)
In-Reply-To: <MW4PR11MB5776AB46BC5702BD0120A7C3FD0B9@MW4PR11MB5776.namprd11.prod.outlook.com>
Hi Wojciech,
On Thu, Mar 10, 2022 at 03:24:07PM +0000, Drewek, Wojciech wrote:
> > I'm sorry, I have very limited insight into geneve/vxlan. It may
> > be of interest to you that within Osmocom we are currently implementing
> > a UPF that uses nftables as the backend. The UPF runs in userspace,
> > handles a minimal subset of PFCP (no qos/shaping, for example), and then
> > installs rules into nftables to perform packet matching and
> > manipulation. Contrary to the old kernel GTP driver, this approach is
> > more flexible as it can also cover the TEID mapping case which you find
> > at SGSN/S-GW or in roaming hubs. We currently are just about to
> > complete a prof-of-concept of that.
>
> That's interesting, I have two questions:
> - is it going to be possible to math packets based on SEID?
I'm sorry, I'm not following you. The SEID I know (TS 29.244 Section 5.6.2)
has only significance on the PFCP session between control and user plane.
The PFCP peers (e.g. SMF and UPF in a PGW use case) use the SEID to
differentiate between different PFCP sessions.
IMHO this has nothing to do with matching of user plane packets in the
actual UFP?
> - any options for offloading this nftables filters to the hardware?
You would have to talk to the netfilter project if there are any related
approaches for nftables hardware offload, I am no longer involved in
netfilter development for more than a decade by now.
In the context of the "osmo-upf" proof-of-concept we're working on at
sysmocom, the task is explicitly to avoid any type of hardware
acceleration and to see what kind of performance we can reach with a
current mainline kernel in pure software.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
next prev parent reply other threads:[~2022-03-10 17:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 12:27 PFCP support in kernel Drewek, Wojciech
2022-03-09 18:16 ` Harald Welte
2022-03-10 15:24 ` Drewek, Wojciech
2022-03-10 17:48 ` Harald Welte [this message]
2022-03-17 11:16 ` Drewek, Wojciech
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yio5/+Ko77tu4Vi6@nataraja \
--to=laforge@gnumonks.org \
--cc=marcin.szycik@linux.intel.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=wojciech.drewek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.