Received-SPF: pass (google.com: domain of linux-kernel+bounces-179843-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 15 May 2024 13:55:42 +0200
From: Harald Welte <laforge@gnumonks.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Wojciech Drewek <wojciech.drewek@intel.com>
Subject: Re: [PATCH net-next v6 00/21] ice: add PFCP filter support
Message-ID: <ZkSivjg7uZsA20ft@nataraja>
References: <20240327152358.2368467-1-aleksander.lobakin@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240327152358.2368467-1-aleksander.lobakin@intel.com>

Daer Alexander, Wojciech,

forgive me for being late to the party, but I just saw the PFCP support
hitting Linus'' git repo in 1b294a1f35616977caddaddf3e9d28e576a1adbc
and was trying to figure out what it is all about.  Is there some kind
of article, kernel documentation or other explanation about it?

I have a prehistoric background in Linux kernel networking, and have
been spending much of the last two decades in creating open source
implemenmtations of 3GPP specifications.

So I'm very familiar with what PFCP is, and what it does, and how it is
used as a protocol by the 3GPP control plane to control the user/data
plane.

Conceptually it seems very odd to me to have something like *pfcp
net-devices*.  PFCP is just a control plane protocol, not a tunnel
mechanism.

From the Kconfig:

> +config PFCP
> +	tristate "Packet Forwarding Control Protocol (PFCP)"
> +	depends on INET
> +	select NET_UDP_TUNNEL
> +	help
> +	  This allows one to create PFCP virtual interfaces that allows to
> +	  set up software and hardware offload of PFCP packets.

I'm curious to understand why are *pfcp* packets hardware offloaded?
PFCP is just the control plane, similar to you can consider netlink the
control plane by which userspace programs control the data plane.

I can fully understand that GTP-U packets are offloaded to kernel space or
hardware, and that then some control plane mechanism like PFCP is needed
to control that data plane.  But offloading packets of that control
protocol?

I also see the following in the patch:

> +MODULE_DESCRIPTION("Interface driver for PFCP encapsulated traffic");

PFCP is not an encapsulation protocol for user plane traffic.  It is not
a tunneling protocol.  GTP-U is the tunneling protocol, whose
implementations (typically UPFs) are remote-controlled by PFCP.

> +	  Note that this module does not support PFCP protocol in the kernel space.
> +	  There is no support for parsing any PFCP messages.

If I may be frank, why do we introduce something called "pfcp" to the
kernel, if it doesn't actually implement any of the PFCP specification
3GPP TS 29.244 (which is specifying a very concrete protocol)?

Once again, I just try to understand what you're trying to do here. It's
very much within my professional field, but I somehow cannot align what
I see within this patch set with my existing world view of what PFCP is
and how it works.

If anyone else has a better grasp of the architecture of this kernel
PFCP support, or has any pointers, I'd be very happy to follow up
on that.

Thanks for your time,
	Harald

-- 
- Harald Welte <laforge@gnumonks.org>          https://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)