[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW4PR11MB577600AC075530F7C3D2F06DFD0A9@MW4PR11MB5776.namprd11.prod.outlook.com>
Date: Wed, 9 Mar 2022 12:27:01 +0000
From: "Drewek, Wojciech" <wojciech.drewek@...el.com>
To: Harald Welte <laforge@...monks.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"michal.swiatkowski@...ux.intel.com"
<michal.swiatkowski@...ux.intel.com>,
Marcin Szycik <marcin.szycik@...ux.intel.com>
Subject: PFCP support in kernel
Hi Harald,
First of all I want to thank you for your revision of our GTP changes, we've learned a lot from your
comments.
So, as you may know our changes were focused around implementing offload of GTP traffic.
We wanted to introduce a consistent solution so we followed the approach used for geneve/vxlan.
In general this approach looks like that:
- create tunnel device (geneve/vxlan/GTP)
- use that device in tc filter command
- based on the type of the device used in tc filter, our driver knows what traffic should be offloaded
Going to the point, now we want to do the same with PFCP.
The question is: does it even make sense to create PFCP device and parse PFCP messages in kernel space?
My understanding is that PFCP is some kind of equivalent of GTP-C and since GTP-C was purposely not
implemented in the kernel I feel like PFCP wouldn't fit there either.
Maybe there is something that PFCP module could implement and it would be useful.
Lastly, if you are wrong person to ask such question then I'm sorry.
Maybe you know someone else who could help us?
Regards,
Wojtek
Powered by blists - more mailing lists