From: Andy Shevchenko <andy@kernel.org> To: Marcin Szycik <marcin.szycik@linux.intel.com> Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, wojciech.drewek@intel.com, michal.swiatkowski@linux.intel.com, aleksander.lobakin@intel.com, davem@davemloft.net, kuba@kernel.org, jiri@resnulli.us, pabeni@redhat.com, jesse.brandeburg@intel.com, simon.horman@corigine.com, idosch@nvidia.com Subject: Re: [PATCH iwl-next v3 3/6] pfcp: add PFCP module Date: Fri, 21 Jul 2023 17:54:05 +0300 [thread overview] Message-ID: <ZLqcDf68HgB6Knnk@smile.fi.intel.com> (raw) In-Reply-To: <20230721071532.613888-4-marcin.szycik@linux.intel.com> On Fri, Jul 21, 2023 at 09:15:29AM +0200, Marcin Szycik wrote: > From: Wojciech Drewek <wojciech.drewek@intel.com> > > Packet Forwarding Control Protocol (PFCP) is a 3GPP Protocol > used between the control plane and the user plane function. > It is specified in TS 29.244[1]. > > Note that this module is not designed to support this Protocol > in the kernel space. There is no support for parsing any PFCP messages. > There is no API that could be used by any userspace daemon. > Basically it does not support PFCP. This protocol is sophisticated > and there is no need for implementing it in the kernel. The purpose > of this module is to allow users to setup software and hardware offload > of PFCP packets using tc tool. > > When user requests to create a PFCP device, a new socket is created. > The socket is set up with port number 8805 which is specific for > PFCP [29.244 4.2.2]. This allow to receive PFCP request messages, > response messages use other ports. > > Note that only one PFCP netdev can be created. > > Only IPv4 is supported at this time. > > [1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111 > Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Co-developed-by: Marcin...? > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> ... > +/* PFCP according to 3GPP TS 29.244 > + * > + * Copyright (C) 2022, Intel Corporation. > + * (C) 2022 by Wojciech Drewek <wojciech.drewek@intel.com> Is it approved by our Legal? First time I see such (c) together with Intel's and correct authorship. > + * Author: Wojciech Drewek <wojciech.drewek@intel.com> > + */ ... > +struct pfcp_dev { > + struct list_head list; This is defined in types.h which is missing. > + struct socket *sock; > + struct net_device *dev; > + struct net *net; > +}; ... > + dev->needs_free_netdev = true; Single space is enough. ... > +static int pfcp_newlink(struct net *net, struct net_device *dev, > + struct nlattr *tb[], struct nlattr *data[], > + struct netlink_ext_ack *extack) > +{ > + struct pfcp_dev *pfcp = netdev_priv(dev); > + struct pfcp_net *pn; > + int err; > + > + pfcp->net = net; > + > + err = pfcp_add_sock(pfcp); > + if (err) { > + netdev_dbg(dev, "failed to add pfcp socket %d\n", err); > + goto exit; > + } > + > + err = register_netdevice(dev); > + if (err) { > + netdev_dbg(dev, "failed to register pfcp netdev %d\n", err); > + goto exit_reg_netdev; > + } > + > + pn = net_generic(dev_net(dev), pfcp_net_id); > + list_add_rcu(&pfcp->list, &pn->pfcp_dev_list); > + > + netdev_dbg(dev, "registered new PFCP interface\n"); > + > + return 0; > + > +exit_reg_netdev: The label naming should tell what _will_ happen if goto $LABEL. Something like exit_del_pfcp_sock: Ditto for all labels in your code. > + pfcp_del_sock(pfcp); > +exit: Shouldn't here be ->net = NULL; ? > + return err; > +} ... > +#ifndef _PFCP_H_ > +#define _PFCP_H_ Missing headers: For net_device internals, bool type, and strcpm() call. > +#define PFCP_PORT 8805 > + > +static inline bool netif_is_pfcp(const struct net_device *dev) > +{ > + return dev->rtnl_link_ops && > + !strcmp(dev->rtnl_link_ops->kind, "pfcp"); > +} > + > +#endif -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy@kernel.org> To: Marcin Szycik <marcin.szycik@linux.intel.com> Cc: jiri@resnulli.us, netdev@vger.kernel.org, idosch@nvidia.com, jesse.brandeburg@intel.com, intel-wired-lan@lists.osuosl.org, kuba@kernel.org, simon.horman@corigine.com, pabeni@redhat.com, davem@davemloft.net Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3 3/6] pfcp: add PFCP module Date: Fri, 21 Jul 2023 17:54:05 +0300 [thread overview] Message-ID: <ZLqcDf68HgB6Knnk@smile.fi.intel.com> (raw) In-Reply-To: <20230721071532.613888-4-marcin.szycik@linux.intel.com> On Fri, Jul 21, 2023 at 09:15:29AM +0200, Marcin Szycik wrote: > From: Wojciech Drewek <wojciech.drewek@intel.com> > > Packet Forwarding Control Protocol (PFCP) is a 3GPP Protocol > used between the control plane and the user plane function. > It is specified in TS 29.244[1]. > > Note that this module is not designed to support this Protocol > in the kernel space. There is no support for parsing any PFCP messages. > There is no API that could be used by any userspace daemon. > Basically it does not support PFCP. This protocol is sophisticated > and there is no need for implementing it in the kernel. The purpose > of this module is to allow users to setup software and hardware offload > of PFCP packets using tc tool. > > When user requests to create a PFCP device, a new socket is created. > The socket is set up with port number 8805 which is specific for > PFCP [29.244 4.2.2]. This allow to receive PFCP request messages, > response messages use other ports. > > Note that only one PFCP netdev can be created. > > Only IPv4 is supported at this time. > > [1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111 > Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Co-developed-by: Marcin...? > Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> ... > +/* PFCP according to 3GPP TS 29.244 > + * > + * Copyright (C) 2022, Intel Corporation. > + * (C) 2022 by Wojciech Drewek <wojciech.drewek@intel.com> Is it approved by our Legal? First time I see such (c) together with Intel's and correct authorship. > + * Author: Wojciech Drewek <wojciech.drewek@intel.com> > + */ ... > +struct pfcp_dev { > + struct list_head list; This is defined in types.h which is missing. > + struct socket *sock; > + struct net_device *dev; > + struct net *net; > +}; ... > + dev->needs_free_netdev = true; Single space is enough. ... > +static int pfcp_newlink(struct net *net, struct net_device *dev, > + struct nlattr *tb[], struct nlattr *data[], > + struct netlink_ext_ack *extack) > +{ > + struct pfcp_dev *pfcp = netdev_priv(dev); > + struct pfcp_net *pn; > + int err; > + > + pfcp->net = net; > + > + err = pfcp_add_sock(pfcp); > + if (err) { > + netdev_dbg(dev, "failed to add pfcp socket %d\n", err); > + goto exit; > + } > + > + err = register_netdevice(dev); > + if (err) { > + netdev_dbg(dev, "failed to register pfcp netdev %d\n", err); > + goto exit_reg_netdev; > + } > + > + pn = net_generic(dev_net(dev), pfcp_net_id); > + list_add_rcu(&pfcp->list, &pn->pfcp_dev_list); > + > + netdev_dbg(dev, "registered new PFCP interface\n"); > + > + return 0; > + > +exit_reg_netdev: The label naming should tell what _will_ happen if goto $LABEL. Something like exit_del_pfcp_sock: Ditto for all labels in your code. > + pfcp_del_sock(pfcp); > +exit: Shouldn't here be ->net = NULL; ? > + return err; > +} ... > +#ifndef _PFCP_H_ > +#define _PFCP_H_ Missing headers: For net_device internals, bool type, and strcpm() call. > +#define PFCP_PORT 8805 > + > +static inline bool netif_is_pfcp(const struct net_device *dev) > +{ > + return dev->rtnl_link_ops && > + !strcmp(dev->rtnl_link_ops->kind, "pfcp"); > +} > + > +#endif -- With Best Regards, Andy Shevchenko _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-07-21 14:54 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-21 7:15 [PATCH iwl-next v3 0/6] ice: Add PFCP filter support Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 7:15 ` [PATCH iwl-next v3 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 14:21 ` Andy Shevchenko 2023-07-21 14:21 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-24 14:21 ` Alexander Lobakin 2023-07-24 14:21 ` [Intel-wired-lan] " Alexander Lobakin 2023-07-21 7:15 ` [PATCH iwl-next v3 2/6] ip_tunnel: convert __be16 tunnel flags to bitmaps Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik [not found] ` <ZLqZRFa1VOHHWCqX@smile.fi.intel.com> 2023-07-26 11:09 ` Alexander Lobakin 2023-07-26 11:09 ` Alexander Lobakin 2023-07-26 12:01 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-26 12:01 ` Andy Shevchenko 2023-07-26 12:05 ` Andy Shevchenko 2023-07-26 12:05 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-26 13:16 ` Alexander Lobakin 2023-07-26 13:16 ` Alexander Lobakin 2023-07-26 14:32 ` Andy Shevchenko 2023-07-26 14:32 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-21 7:15 ` [PATCH iwl-next v3 3/6] pfcp: add PFCP module Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 14:54 ` Andy Shevchenko [this message] 2023-07-21 14:54 ` Andy Shevchenko 2023-07-24 10:36 ` Marcin Szycik 2023-07-24 10:36 ` Marcin Szycik 2023-07-21 7:15 ` [PATCH iwl-next v3 4/6] pfcp: always set pfcp metadata Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 15:02 ` Andy Shevchenko 2023-07-21 15:02 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-24 13:19 ` Marcin Szycik 2023-07-24 13:19 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 7:15 ` [PATCH iwl-next v3 5/6] ice: refactor ICE_TC_FLWR_FIELD_ENC_OPTS Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 7:15 ` [PATCH iwl-next v3 6/6] ice: Add support for PFCP hardware offload in switchdev Marcin Szycik 2023-07-21 7:15 ` [Intel-wired-lan] " Marcin Szycik 2023-07-21 15:07 ` Andy Shevchenko 2023-07-21 15:07 ` [Intel-wired-lan] " Andy Shevchenko 2023-07-24 13:58 ` Marcin Szycik 2023-07-24 13:58 ` [Intel-wired-lan] " Marcin Szycik 2023-07-24 14:10 ` Andy Shevchenko 2023-07-24 14:10 ` [Intel-wired-lan] " Andy Shevchenko
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=ZLqcDf68HgB6Knnk@smile.fi.intel.com \ --to=andy@kernel.org \ --cc=aleksander.lobakin@intel.com \ --cc=davem@davemloft.net \ --cc=idosch@nvidia.com \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=jesse.brandeburg@intel.com \ --cc=jiri@resnulli.us \ --cc=kuba@kernel.org \ --cc=marcin.szycik@linux.intel.com \ --cc=michal.swiatkowski@linux.intel.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=simon.horman@corigine.com \ --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: linkBe 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.