| Message ID | 20231207164911.14330-1-marcin.szycik@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add PFCP filter support | expand |
On 12/7/2023 8:49 AM, Marcin Szycik wrote: > Add support for creating PFCP filters in switchdev mode. Add pfcp module > that allows to create a PFCP-type netdev. The netdev then can be passed to > tc when creating a filter to indicate that PFCP filter should be created. > > To add a PFCP filter, a special netdev must be created and passed to tc > command: > > ip link add pfcp0 type pfcp > tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ > 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ > dev pfcp0 > > Changes in iproute2 [1] are required to use pfcp_opts in tc. > > ICE COMMS package is required as it contains PFCP profiles. > > Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously > stored in a __be16. All possible values have already been used, making it > impossible to add new ones. > > [1] https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com > --- > This patchset should be applied on top of the "boys" tree [2], as it > depends on recent bitmap changes. Is this for comment only (RFC)? This doesn't seem to apply to iwl-next and if this based on, and has dependencies from, another tree, I can't apply them here. > [2] https://github.com/norov/linux/commits/boys > --- > v3: https://lore.kernel.org/intel-wired-lan/20230721071532.613888-1-marcin.szycik@linux.intel.com > v2: https://lore.kernel.org/intel-wired-lan/20230607112606.15899-1-marcin.szycik@linux.intel.com > v1: https://lore.kernel.org/intel-wired-lan/20230601131929.294667-1-marcin.szycik@linux.intel.com > --- > > Alexander Lobakin (3): > ip_tunnel: use a separate struct to store tunnel params in the kernel > ip_tunnel: convert __be16 tunnel flags to bitmaps > lib/bitmap: add tests for IP tunnel flags conversion helpers > > Marcin Szycik (2): > ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS > ice: Add support for PFCP hardware offload in switchdev > > Michal Swiatkowski (1): > pfcp: always set pfcp metadata > > Wojciech Drewek (1): > pfcp: add PFCP module > > drivers/net/Kconfig | 13 + > drivers/net/Makefile | 1 + > drivers/net/bareudp.c | 19 +- > drivers/net/ethernet/intel/ice/ice_ddp.c | 9 + > .../net/ethernet/intel/ice/ice_flex_type.h | 4 +- > .../ethernet/intel/ice/ice_protocol_type.h | 12 + > drivers/net/ethernet/intel/ice/ice_switch.c | 85 +++++ > drivers/net/ethernet/intel/ice/ice_switch.h | 2 + > drivers/net/ethernet/intel/ice/ice_tc_lib.c | 68 +++- > drivers/net/ethernet/intel/ice/ice_tc_lib.h | 8 +- > .../ethernet/mellanox/mlx5/core/en/tc_tun.h | 2 +- > .../mellanox/mlx5/core/en/tc_tun_encap.c | 6 +- > .../mellanox/mlx5/core/en/tc_tun_geneve.c | 12 +- > .../mellanox/mlx5/core/en/tc_tun_gre.c | 8 +- > .../mellanox/mlx5/core/en/tc_tun_vxlan.c | 9 +- > .../net/ethernet/mellanox/mlx5/core/en_tc.c | 16 +- > .../ethernet/mellanox/mlxsw/spectrum_ipip.c | 56 ++-- > .../ethernet/mellanox/mlxsw/spectrum_ipip.h | 2 +- > .../ethernet/mellanox/mlxsw/spectrum_span.c | 10 +- > .../ethernet/netronome/nfp/flower/action.c | 27 +- > drivers/net/geneve.c | 44 ++- > drivers/net/pfcp.c | 302 ++++++++++++++++++ > drivers/net/vxlan/vxlan_core.c | 14 +- > include/linux/netdevice.h | 7 +- > include/net/dst_metadata.h | 10 +- > include/net/flow_dissector.h | 2 +- > include/net/gre.h | 70 ++-- > include/net/ip6_tunnel.h | 4 +- > include/net/ip_tunnels.h | 139 ++++++-- > include/net/pfcp.h | 90 ++++++ > include/net/udp_tunnel.h | 4 +- > include/uapi/linux/if_tunnel.h | 36 +++ > include/uapi/linux/pkt_cls.h | 14 + > lib/test_bitmap.c | 100 ++++++ > net/bridge/br_vlan_tunnel.c | 9 +- > net/core/filter.c | 26 +- > net/core/flow_dissector.c | 20 +- > net/ipv4/fou_bpf.c | 2 +- > net/ipv4/gre_demux.c | 2 +- > net/ipv4/ip_gre.c | 144 +++++---- > net/ipv4/ip_tunnel.c | 109 +++++-- > net/ipv4/ip_tunnel_core.c | 82 +++-- > net/ipv4/ip_vti.c | 41 ++- > net/ipv4/ipip.c | 33 +- > net/ipv4/ipmr.c | 2 +- > net/ipv4/udp_tunnel_core.c | 5 +- > net/ipv6/addrconf.c | 3 +- > net/ipv6/ip6_gre.c | 85 ++--- > net/ipv6/ip6_tunnel.c | 14 +- > net/ipv6/sit.c | 38 ++- > net/netfilter/ipvs/ip_vs_core.c | 6 +- > net/netfilter/ipvs/ip_vs_xmit.c | 20 +- > net/netfilter/nft_tunnel.c | 44 +-- > net/openvswitch/flow_netlink.c | 61 ++-- > net/psample/psample.c | 26 +- > net/sched/act_tunnel_key.c | 36 +-- > net/sched/cls_flower.c | 134 +++++++- > 57 files changed, 1652 insertions(+), 495 deletions(-) > create mode 100644 drivers/net/pfcp.c > create mode 100644 include/net/pfcp.h >
From: Tony Nguyen <anthony.l.nguyen@intel.com> Date: Fri, 8 Dec 2023 13:34:10 -0800 > > > On 12/7/2023 8:49 AM, Marcin Szycik wrote: >> Add support for creating PFCP filters in switchdev mode. Add pfcp module >> that allows to create a PFCP-type netdev. The netdev then can be >> passed to >> tc when creating a filter to indicate that PFCP filter should be created. >> >> To add a PFCP filter, a special netdev must be created and passed to tc >> command: >> >> ip link add pfcp0 type pfcp >> tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ >> 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ >> dev pfcp0 >> >> Changes in iproute2 [1] are required to use pfcp_opts in tc. >> >> ICE COMMS package is required as it contains PFCP profiles. >> >> Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously >> stored in a __be16. All possible values have already been used, making it >> impossible to add new ones. >> >> [1] >> https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com >> --- >> This patchset should be applied on top of the "boys" tree [2], as it >> depends on recent bitmap changes. > > Is this for comment only (RFC)? This doesn't seem to apply to iwl-next > and if this based on, and has dependencies from, another tree, I can't > apply them here. It's not an RFC. The series contains generic code changes and must go directly through net-next. The dependency on the bitmap tree was discussed with Jakub and Yury and we agreed that the netdev guys will pull it before applying this one. Thanks, Olek
On 12/11/2023 4:38 AM, Alexander Lobakin wrote: > From: Tony Nguyen <anthony.l.nguyen@intel.com> > Date: Fri, 8 Dec 2023 13:34:10 -0800 > >> >> >> On 12/7/2023 8:49 AM, Marcin Szycik wrote: >>> Add support for creating PFCP filters in switchdev mode. Add pfcp module >>> that allows to create a PFCP-type netdev. The netdev then can be >>> passed to >>> tc when creating a filter to indicate that PFCP filter should be created. >>> >>> To add a PFCP filter, a special netdev must be created and passed to tc >>> command: >>> >>> ip link add pfcp0 type pfcp >>> tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ >>> 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ >>> dev pfcp0 >>> >>> Changes in iproute2 [1] are required to use pfcp_opts in tc. >>> >>> ICE COMMS package is required as it contains PFCP profiles. >>> >>> Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously >>> stored in a __be16. All possible values have already been used, making it >>> impossible to add new ones. >>> >>> [1] >>> https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com >>> --- >>> This patchset should be applied on top of the "boys" tree [2], as it >>> depends on recent bitmap changes. >> >> Is this for comment only (RFC)? This doesn't seem to apply to iwl-next >> and if this based on, and has dependencies from, another tree, I can't >> apply them here. > > It's not an RFC. > The series contains generic code changes and must go directly through > net-next. Should this be marked for 'net-next' rather than 'iwl-next' then? Thanks, Tony > The dependency on the bitmap tree was discussed with Jakub and > Yury and we agreed that the netdev guys will pull it before applying > this one. > > Thanks, > Olek
On 11.12.2023 22:23, Tony Nguyen wrote: > > > On 12/11/2023 4:38 AM, Alexander Lobakin wrote: >> From: Tony Nguyen <anthony.l.nguyen@intel.com> >> Date: Fri, 8 Dec 2023 13:34:10 -0800 >> >>> >>> >>> On 12/7/2023 8:49 AM, Marcin Szycik wrote: >>>> Add support for creating PFCP filters in switchdev mode. Add pfcp module >>>> that allows to create a PFCP-type netdev. The netdev then can be >>>> passed to >>>> tc when creating a filter to indicate that PFCP filter should be created. >>>> >>>> To add a PFCP filter, a special netdev must be created and passed to tc >>>> command: >>>> >>>> ip link add pfcp0 type pfcp >>>> tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ >>>> 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ >>>> dev pfcp0 >>>> >>>> Changes in iproute2 [1] are required to use pfcp_opts in tc. >>>> >>>> ICE COMMS package is required as it contains PFCP profiles. >>>> >>>> Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously >>>> stored in a __be16. All possible values have already been used, making it >>>> impossible to add new ones. >>>> >>>> [1] >>>> https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com >>>> --- >>>> This patchset should be applied on top of the "boys" tree [2], as it >>>> depends on recent bitmap changes. >>> >>> Is this for comment only (RFC)? This doesn't seem to apply to iwl-next >>> and if this based on, and has dependencies from, another tree, I can't >>> apply them here. >> >> It's not an RFC. >> The series contains generic code changes and must go directly through >> net-next. > > Should this be marked for 'net-next' rather than 'iwl-next' then? My bad, sorry. This series should go directly to net-next. Thanks, Marcin > > Thanks, > Tony > >> The dependency on the bitmap tree was discussed with Jakub and >> Yury and we agreed that the netdev guys will pull it before applying >> this one. >> >> Thanks, >> Olek > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
From: Marcin Szycik <marcin.szycik@linux.intel.com> Date: Tue, 12 Dec 2023 11:45:24 +0100 > > > On 11.12.2023 22:23, Tony Nguyen wrote: >> >> >> On 12/11/2023 4:38 AM, Alexander Lobakin wrote: >>> From: Tony Nguyen <anthony.l.nguyen@intel.com> >>> Date: Fri, 8 Dec 2023 13:34:10 -0800 >>> >>>> >>>> >>>> On 12/7/2023 8:49 AM, Marcin Szycik wrote: >>>>> Add support for creating PFCP filters in switchdev mode. Add pfcp module >>>>> that allows to create a PFCP-type netdev. The netdev then can be >>>>> passed to >>>>> tc when creating a filter to indicate that PFCP filter should be created. >>>>> >>>>> To add a PFCP filter, a special netdev must be created and passed to tc >>>>> command: >>>>> >>>>> ip link add pfcp0 type pfcp >>>>> tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ >>>>> 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ >>>>> dev pfcp0 >>>>> >>>>> Changes in iproute2 [1] are required to use pfcp_opts in tc. >>>>> >>>>> ICE COMMS package is required as it contains PFCP profiles. >>>>> >>>>> Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously >>>>> stored in a __be16. All possible values have already been used, making it >>>>> impossible to add new ones. >>>>> >>>>> [1] >>>>> https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com >>>>> --- >>>>> This patchset should be applied on top of the "boys" tree [2], as it >>>>> depends on recent bitmap changes. >>>> >>>> Is this for comment only (RFC)? This doesn't seem to apply to iwl-next >>>> and if this based on, and has dependencies from, another tree, I can't >>>> apply them here. >>> >>> It's not an RFC. >>> The series contains generic code changes and must go directly through >>> net-next. >> >> Should this be marked for 'net-next' rather than 'iwl-next' then? > > My bad, sorry. > This series should go directly to net-next. > > Thanks, > Marcin > >> >> Thanks, >> Tony >> >>> The dependency on the bitmap tree was discussed with Jakub and >>> Yury and we agreed that the netdev guys will pull it before applying >>> this one. Ping? :s Or should we resubmit? Thanks, Olek
On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote: > Ping? :s > Or should we resubmit? Can you wait for next merge window instead? We're getting flooded with patches as everyone seemingly tries to get their own (i.e. the most important!) work merged before the end of the year. The set of PRs from the bitmap tree which Linus decided not to pull is not empty. So we'd have to go figure out what's exactly is in that branch we're supposed to pull, and whether it's fine. It probably is, but you see, this is a problem which can be solved by waiting, and letting Linus pull it himself. While the 150 patches we're getting a day now have to be looked at.
On 15.12.2023 17:49, Jakub Kicinski wrote: > On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote: >> Ping? :s >> Or should we resubmit? > > Can you wait for next merge window instead? > We're getting flooded with patches as everyone seemingly tries to get > their own (i.e. the most important!) work merged before the end of > the year. The set of PRs from the bitmap tree which Linus decided > not to pull is not empty. So we'd have to go figure out what's exactly > is in that branch we're supposed to pull, and whether it's fine. > It probably is, but you see, this is a problem which can be solved by > waiting, and letting Linus pull it himself. While the 150 patches we're > getting a day now have to be looked at. Let's wait to the next window then. Thanks, Marcin
From: Marcin Szycik <marcin.szycik@linux.intel.com> Date: Mon, 18 Dec 2023 11:04:01 +0100 > > > On 15.12.2023 17:49, Jakub Kicinski wrote: >> On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote: >>> Ping? :s >>> Or should we resubmit? >> >> Can you wait for next merge window instead? >> We're getting flooded with patches as everyone seemingly tries to get >> their own (i.e. the most important!) work merged before the end of >> the year. The set of PRs from the bitmap tree which Linus decided >> not to pull is not empty. So we'd have to go figure out what's exactly >> is in that branch we're supposed to pull, and whether it's fine. >> It probably is, but you see, this is a problem which can be solved by >> waiting, and letting Linus pull it himself. While the 150 patches we're >> getting a day now have to be looked at. > > Let's wait to the next window then. Hey Yury, Given that PFCP will be resent in the next window... Your "boys" tree is in fact self-contained -- those are mostly optimizations and cleanups, and for the new API -- bitmap_{read,write}() -- it has internal users (after "bitmap: make bitmap_{get,set}_value8() use bitmap_{read,write}()"). IOW, I don't see a reason for not merging it into your main for-next tree (this week :p). What do you think? > > Thanks, > Marcin Thanks, Olek
+ Alexander Potapenko On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote: > From: Marcin Szycik <marcin.szycik@linux.intel.com> > Date: Mon, 18 Dec 2023 11:04:01 +0100 > > > > > > > On 15.12.2023 17:49, Jakub Kicinski wrote: > >> On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote: > >>> Ping? :s > >>> Or should we resubmit? > >> > >> Can you wait for next merge window instead? > >> We're getting flooded with patches as everyone seemingly tries to get > >> their own (i.e. the most important!) work merged before the end of > >> the year. The set of PRs from the bitmap tree which Linus decided > >> not to pull is not empty. So we'd have to go figure out what's exactly > >> is in that branch we're supposed to pull, and whether it's fine. > >> It probably is, but you see, this is a problem which can be solved by > >> waiting, and letting Linus pull it himself. While the 150 patches we're > >> getting a day now have to be looked at. > > > > Let's wait to the next window then. > > Hey Yury, > > Given that PFCP will be resent in the next window... > > Your "boys" tree is in fact self-contained -- those are mostly > optimizations and cleanups, and for the new API -- bitmap_{read,write}() > -- it has internal users (after "bitmap: make bitmap_{get,set}_value8() > use bitmap_{read,write}()"). IOW, I don't see a reason for not merging > it into your main for-next tree (this week :p). > What do you think? I think that there's already enough mess with this patch. Alexander submitted new version of his MTE series together with the patch. https://lore.kernel.org/lkml/ZXtciaxTKFBiui%2FX@yury-ThinkPad/T/ Now you're asking me to merge it separately. I don't want to undercut arm64 folks. Can you guys decide what you want? If you want to move bitmap_read/write() with my branch, I need to send it in -next for testing ASAP. And for that, as I already said, I need at least one active user in current kernel tree. (Yes, bitmap_get_value8() counts.) If you want to move it this way, please resend all the patches together. Thanks, Yury
On Mon, Dec 18, 2023 at 4:57 PM Yury Norov <yury.norov@gmail.com> wrote: > > + Alexander Potapenko > > On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote: > > From: Marcin Szycik <marcin.szycik@linux.intel.com> > > Date: Mon, 18 Dec 2023 11:04:01 +0100 > > > > > > > > > > > On 15.12.2023 17:49, Jakub Kicinski wrote: > > >> On Fri, 15 Dec 2023 11:11:23 +0100 Alexander Lobakin wrote: > > >>> Ping? :s > > >>> Or should we resubmit? > > >> > > >> Can you wait for next merge window instead? > > >> We're getting flooded with patches as everyone seemingly tries to get > > >> their own (i.e. the most important!) work merged before the end of > > >> the year. The set of PRs from the bitmap tree which Linus decided > > >> not to pull is not empty. So we'd have to go figure out what's exactly > > >> is in that branch we're supposed to pull, and whether it's fine. > > >> It probably is, but you see, this is a problem which can be solved by > > >> waiting, and letting Linus pull it himself. While the 150 patches we're > > >> getting a day now have to be looked at. > > > > > > Let's wait to the next window then. > > > > Hey Yury, > > > > Given that PFCP will be resent in the next window... > > > > Your "boys" tree is in fact self-contained -- those are mostly > > optimizations and cleanups, and for the new API -- bitmap_{read,write}() > > -- it has internal users (after "bitmap: make bitmap_{get,set}_value8() > > use bitmap_{read,write}()"). IOW, I don't see a reason for not merging > > it into your main for-next tree (this week :p). > > What do you think? > > I think that there's already enough mess with this patch. Alexander > submitted new version of his MTE series together with the patch. Yeah, sorry about that. Because the MTE part of the patches was still awaiting review, I thought it would be better to land the bitmap API separately, but as you pointed out there should be at least one user for it, which it wouldn't have in that case. I don't have a strong preference about whether to submit the patches before or after the end of year - in fact I don't think they are urgent enough, and we'd better postpone them till January. So unless Alexander has urgent fixes depending on my bitmap patches, I'd suggest waiting till they are taken via the arm64 tree. > https://lore.kernel.org/lkml/ZXtciaxTKFBiui%2FX@yury-ThinkPad/T/ > > Now you're asking me to merge it separately. I don't want to undercut > arm64 folks. > > Can you guys decide what you want? If you want to move > bitmap_read/write() with my branch, I need to send it in -next for > testing ASAP. And for that, as I already said, I need at least one > active user in current kernel tree. (Yes, bitmap_get_value8() counts.) > > If you want to move it this way, please resend all the patches > together. > > Thanks, > Yury -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
From: Alexander Potapenko <glider@google.com> Date: Mon, 18 Dec 2023 17:16:09 +0100 > On Mon, Dec 18, 2023 at 4:57 PM Yury Norov <yury.norov@gmail.com> wrote: >> >> + Alexander Potapenko >> >> On Mon, Dec 18, 2023 at 01:47:01PM +0100, Alexander Lobakin wrote: [...] >>> Hey Yury, >>> >>> Given that PFCP will be resent in the next window... >>> >>> Your "boys" tree is in fact self-contained -- those are mostly >>> optimizations and cleanups, and for the new API -- bitmap_{read,write}() >>> -- it has internal users (after "bitmap: make bitmap_{get,set}_value8() >>> use bitmap_{read,write}()"). IOW, I don't see a reason for not merging >>> it into your main for-next tree (this week :p). >>> What do you think? >> >> I think that there's already enough mess with this patch. Alexander >> submitted new version of his MTE series together with the patch. > > Yeah, sorry about that. Because the MTE part of the patches was still > awaiting review, I thought it would be better to land the bitmap API > separately, but as you pointed out there should be at least one user > for it, which it wouldn't have in that case. > > I don't have a strong preference about whether to submit the patches > before or after the end of year - in fact I don't think they are > urgent enough, and we'd better postpone them till January. > > So unless Alexander has urgent fixes depending on my bitmap patches, > I'd suggest waiting till they are taken via the arm64 tree. No, nothing urgent. Sounds good, no need to rush at the end of the dev cycle. > >> https://lore.kernel.org/lkml/ZXtciaxTKFBiui%2FX@yury-ThinkPad/T/ >> >> Now you're asking me to merge it separately. I don't want to undercut >> arm64 folks. >> >> Can you guys decide what you want? If you want to move >> bitmap_read/write() with my branch, I need to send it in -next for >> testing ASAP. And for that, as I already said, I need at least one >> active user in current kernel tree. (Yes, bitmap_get_value8() counts.) >> >> If you want to move it this way, please resend all the patches >> together. [...] Thanks, Olek
Add support for creating PFCP filters in switchdev mode. Add pfcp module that allows to create a PFCP-type netdev. The netdev then can be passed to tc when creating a filter to indicate that PFCP filter should be created. To add a PFCP filter, a special netdev must be created and passed to tc command: ip link add pfcp0 type pfcp tc filter add dev eth0 ingress prio 1 flower pfcp_opts \ 1:12ab/ff:fffffffffffffff0 skip_hw action mirred egress redirect \ dev pfcp0 Changes in iproute2 [1] are required to use pfcp_opts in tc. ICE COMMS package is required as it contains PFCP profiles. Part of this patchset modifies IP_TUNNEL_*_OPTs, which were previously stored in a __be16. All possible values have already been used, making it impossible to add new ones. [1] https://lore.kernel.org/netdev/20230614091758.11180-1-marcin.szycik@linux.intel.com --- This patchset should be applied on top of the "boys" tree [2], as it depends on recent bitmap changes. [2] https://github.com/norov/linux/commits/boys --- v3: https://lore.kernel.org/intel-wired-lan/20230721071532.613888-1-marcin.szycik@linux.intel.com v2: https://lore.kernel.org/intel-wired-lan/20230607112606.15899-1-marcin.szycik@linux.intel.com v1: https://lore.kernel.org/intel-wired-lan/20230601131929.294667-1-marcin.szycik@linux.intel.com --- Alexander Lobakin (3): ip_tunnel: use a separate struct to store tunnel params in the kernel ip_tunnel: convert __be16 tunnel flags to bitmaps lib/bitmap: add tests for IP tunnel flags conversion helpers Marcin Szycik (2): ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS ice: Add support for PFCP hardware offload in switchdev Michal Swiatkowski (1): pfcp: always set pfcp metadata Wojciech Drewek (1): pfcp: add PFCP module drivers/net/Kconfig | 13 + drivers/net/Makefile | 1 + drivers/net/bareudp.c | 19 +- drivers/net/ethernet/intel/ice/ice_ddp.c | 9 + .../net/ethernet/intel/ice/ice_flex_type.h | 4 +- .../ethernet/intel/ice/ice_protocol_type.h | 12 + drivers/net/ethernet/intel/ice/ice_switch.c | 85 +++++ drivers/net/ethernet/intel/ice/ice_switch.h | 2 + drivers/net/ethernet/intel/ice/ice_tc_lib.c | 68 +++- drivers/net/ethernet/intel/ice/ice_tc_lib.h | 8 +- .../ethernet/mellanox/mlx5/core/en/tc_tun.h | 2 +- .../mellanox/mlx5/core/en/tc_tun_encap.c | 6 +- .../mellanox/mlx5/core/en/tc_tun_geneve.c | 12 +- .../mellanox/mlx5/core/en/tc_tun_gre.c | 8 +- .../mellanox/mlx5/core/en/tc_tun_vxlan.c | 9 +- .../net/ethernet/mellanox/mlx5/core/en_tc.c | 16 +- .../ethernet/mellanox/mlxsw/spectrum_ipip.c | 56 ++-- .../ethernet/mellanox/mlxsw/spectrum_ipip.h | 2 +- .../ethernet/mellanox/mlxsw/spectrum_span.c | 10 +- .../ethernet/netronome/nfp/flower/action.c | 27 +- drivers/net/geneve.c | 44 ++- drivers/net/pfcp.c | 302 ++++++++++++++++++ drivers/net/vxlan/vxlan_core.c | 14 +- include/linux/netdevice.h | 7 +- include/net/dst_metadata.h | 10 +- include/net/flow_dissector.h | 2 +- include/net/gre.h | 70 ++-- include/net/ip6_tunnel.h | 4 +- include/net/ip_tunnels.h | 139 ++++++-- include/net/pfcp.h | 90 ++++++ include/net/udp_tunnel.h | 4 +- include/uapi/linux/if_tunnel.h | 36 +++ include/uapi/linux/pkt_cls.h | 14 + lib/test_bitmap.c | 100 ++++++ net/bridge/br_vlan_tunnel.c | 9 +- net/core/filter.c | 26 +- net/core/flow_dissector.c | 20 +- net/ipv4/fou_bpf.c | 2 +- net/ipv4/gre_demux.c | 2 +- net/ipv4/ip_gre.c | 144 +++++---- net/ipv4/ip_tunnel.c | 109 +++++-- net/ipv4/ip_tunnel_core.c | 82 +++-- net/ipv4/ip_vti.c | 41 ++- net/ipv4/ipip.c | 33 +- net/ipv4/ipmr.c | 2 +- net/ipv4/udp_tunnel_core.c | 5 +- net/ipv6/addrconf.c | 3 +- net/ipv6/ip6_gre.c | 85 ++--- net/ipv6/ip6_tunnel.c | 14 +- net/ipv6/sit.c | 38 ++- net/netfilter/ipvs/ip_vs_core.c | 6 +- net/netfilter/ipvs/ip_vs_xmit.c | 20 +- net/netfilter/nft_tunnel.c | 44 +-- net/openvswitch/flow_netlink.c | 61 ++-- net/psample/psample.c | 26 +- net/sched/act_tunnel_key.c | 36 +-- net/sched/cls_flower.c | 134 +++++++- 57 files changed, 1652 insertions(+), 495 deletions(-) create mode 100644 drivers/net/pfcp.c create mode 100644 include/net/pfcp.h