From: Michael Tuexen <tuexen@fh-muenster.de> To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Xin Long <lucien.xin@gmail.com>, kernel test robot <lkp@intel.com>, network dev <netdev@vger.kernel.org>, linux-sctp@vger.kernel.org, kbuild-all@lists.01.org, Neil Horman <nhorman@tuxdriver.com>, davem <davem@davemloft.net> Subject: Re: [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set Date: Mon, 05 Oct 2020 20:08:36 +0000 [thread overview] Message-ID: <029F42A9-31CF-45B6-944D-912A005EE864@fh-muenster.de> (raw) In-Reply-To: <20201005190114.GL70998@localhost.localdomain> [-- Attachment #1: Type: text/plain, Size: 4647 bytes --] > On 5. Oct 2020, at 21:01, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Sat, Oct 03, 2020 at 08:24:34PM +0800, Xin Long wrote: >> On Sat, Oct 3, 2020 at 7:23 PM Xin Long <lucien.xin@gmail.com> wrote: >>> >>> On Sat, Oct 3, 2020 at 4:12 PM Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Sat, Oct 3, 2020 at 12:08 PM Marcelo Ricardo Leitner >>>> <marcelo.leitner@gmail.com> wrote: >>>>> >>>>> On Wed, Sep 30, 2020 at 03:00:42AM +0800, kernel test robot wrote: >>>>>> Hi Xin, >>>>>> >>>>>> Thank you for the patch! Yet something to improve: >>>>> >>>>> I wonder how are you planning to fix this. It is quite entangled. >>>>> This is not performance critical. Maybe the cleanest way out is to >>>>> move it to a .c file. >>>>> >>>>> Adding a >>>>> #if defined(CONFIG_IP_SCTP) || defined(CONFIG_IP_SCTP_MODULE) >>>>> in there doesn't seem good. >>>>> >>>>>> In file included from include/net/sctp/checksum.h:27, >>>>>> from net/netfilter/nf_nat_proto.c:16: >>>>>> include/net/sctp/sctp.h: In function 'sctp_mtu_payload': >>>>>>>> include/net/sctp/sctp.h:583:31: error: 'struct net' has no member named 'sctp'; did you mean 'ct'? >>>>>> 583 | if (sock_net(&sp->inet.sk)->sctp.udp_port) >>>>>> | ^~~~ >>>>>> | ct >>>>>> >>>> Here is actually another problem, I'm still thinking how to fix it. >>>> >>>> Now sctp_mtu_payload() returns different value depending on >>>> net->sctp.udp_port. but net->sctp.udp_port can be changed by >>>> "sysctl -w" anytime. so: > > Good point. > >>>> >>>> In sctp_packet_config() it gets overhead/headroom by calling >>>> sctp_mtu_payload(). When 'udp_port' is 0, it's IP+MAC header >>>> size. Then if 'udp_port' is changed to 9899 by 'sysctl -w', >>>> udphdr will also be added to the packet in sctp_v4_xmit(), >>>> and later the headroom may not be enough for IP+MAC headers. >>>> >>>> I'm thinking to add sctp_sock->udp_port, and it'll be set when >>>> the sock is created with net->udp_port. but not sure if we should >>>> update sctp_sock->udp_port with net->udp_port when sending packets? > > I don't think so, > >>> something like: > ... >> diff --git a/net/sctp/output.c b/net/sctp/output.c >> index 6614c9fdc51e..c96b13ec72f4 100644 >> --- a/net/sctp/output.c >> +++ b/net/sctp/output.c >> @@ -91,6 +91,14 @@ void sctp_packet_config(struct sctp_packet *packet, >> __u32 vtag, >> if (asoc) { >> sk = asoc->base.sk; >> sp = sctp_sk(sk); >> + >> + if (unlikely(sp->udp_port != sock_net(sk)->sctp.udp_port)) { > > RFC6951 has: > > 6.1. Get or Set the Remote UDP Encapsulation Port Number > (SCTP_REMOTE_UDP_ENCAPS_PORT) > ... > sue_assoc_id: This parameter is ignored for one-to-one style > sockets. For one-to-many style sockets, the application may fill > in an association identifier or SCTP_FUTURE_ASSOC for this query. > It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sue_assoc_id. > > sue_address: This specifies which address is of interest. If a > wildcard address is provided, it applies only to future paths. > > So I'm not seeing a reason to have a system wide knob that takes > effect in run time like this. > Enable, start apps, and they keep behaving as initially configured. > Need to disable? Restart the apps/sockets. > > Thoughts? Just note about how things are implemented in FreeBSD. This is not about how it has to be implemented, but how it can be implemented. The local UDP encaps port is controlled by a system wide sysctl. sudo sysctl net.inet.sctp.udp_tunneling_port=9899 will use from that point on port 9899 the local encaps port. The local encaps port can't be controlled by the application. sudo sysctl net.inet.sctp.udp_tunneling_port=9900 will change this port number instantly to 9900. I don't see a use case for this, but it is possible. sudo sysctl net.inet.sctp.udp_tunneling_port=0 disables the sending and receiving of UDP encapsulated packets. The application can only control the remote encapsulation port on a per remote address base. This is mostly relevant for the client side wanting to use UDP encapsulation. Best regards Michael > >> + __u16 port = sock_net(sk)->sctp.udp_port; >> + >> + if (!sp->udp_port || !port) >> + sctp_assoc_update_frag_point(asoc); >> + sp->udp_port = port; >> + } >> } [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5257 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Tuexen <tuexen@fh-muenster.de> To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Cc: Xin Long <lucien.xin@gmail.com>, kernel test robot <lkp@intel.com>, network dev <netdev@vger.kernel.org>, linux-sctp@vger.kernel.org, kbuild-all@lists.01.org, Neil Horman <nhorman@tuxdriver.com>, davem <davem@davemloft.net> Subject: Re: [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set Date: Mon, 5 Oct 2020 22:08:36 +0200 [thread overview] Message-ID: <029F42A9-31CF-45B6-944D-912A005EE864@fh-muenster.de> (raw) Message-ID: <20201005200836.eUMxYopJBNd6KvX6LjzZnXmU_cRNDhg8EOhg2zEcE9o@z> (raw) In-Reply-To: <20201005190114.GL70998@localhost.localdomain> [-- Attachment #1: Type: text/plain, Size: 4647 bytes --] > On 5. Oct 2020, at 21:01, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > > On Sat, Oct 03, 2020 at 08:24:34PM +0800, Xin Long wrote: >> On Sat, Oct 3, 2020 at 7:23 PM Xin Long <lucien.xin@gmail.com> wrote: >>> >>> On Sat, Oct 3, 2020 at 4:12 PM Xin Long <lucien.xin@gmail.com> wrote: >>>> >>>> On Sat, Oct 3, 2020 at 12:08 PM Marcelo Ricardo Leitner >>>> <marcelo.leitner@gmail.com> wrote: >>>>> >>>>> On Wed, Sep 30, 2020 at 03:00:42AM +0800, kernel test robot wrote: >>>>>> Hi Xin, >>>>>> >>>>>> Thank you for the patch! Yet something to improve: >>>>> >>>>> I wonder how are you planning to fix this. It is quite entangled. >>>>> This is not performance critical. Maybe the cleanest way out is to >>>>> move it to a .c file. >>>>> >>>>> Adding a >>>>> #if defined(CONFIG_IP_SCTP) || defined(CONFIG_IP_SCTP_MODULE) >>>>> in there doesn't seem good. >>>>> >>>>>> In file included from include/net/sctp/checksum.h:27, >>>>>> from net/netfilter/nf_nat_proto.c:16: >>>>>> include/net/sctp/sctp.h: In function 'sctp_mtu_payload': >>>>>>>> include/net/sctp/sctp.h:583:31: error: 'struct net' has no member named 'sctp'; did you mean 'ct'? >>>>>> 583 | if (sock_net(&sp->inet.sk)->sctp.udp_port) >>>>>> | ^~~~ >>>>>> | ct >>>>>> >>>> Here is actually another problem, I'm still thinking how to fix it. >>>> >>>> Now sctp_mtu_payload() returns different value depending on >>>> net->sctp.udp_port. but net->sctp.udp_port can be changed by >>>> "sysctl -w" anytime. so: > > Good point. > >>>> >>>> In sctp_packet_config() it gets overhead/headroom by calling >>>> sctp_mtu_payload(). When 'udp_port' is 0, it's IP+MAC header >>>> size. Then if 'udp_port' is changed to 9899 by 'sysctl -w', >>>> udphdr will also be added to the packet in sctp_v4_xmit(), >>>> and later the headroom may not be enough for IP+MAC headers. >>>> >>>> I'm thinking to add sctp_sock->udp_port, and it'll be set when >>>> the sock is created with net->udp_port. but not sure if we should >>>> update sctp_sock->udp_port with net->udp_port when sending packets? > > I don't think so, > >>> something like: > ... >> diff --git a/net/sctp/output.c b/net/sctp/output.c >> index 6614c9fdc51e..c96b13ec72f4 100644 >> --- a/net/sctp/output.c >> +++ b/net/sctp/output.c >> @@ -91,6 +91,14 @@ void sctp_packet_config(struct sctp_packet *packet, >> __u32 vtag, >> if (asoc) { >> sk = asoc->base.sk; >> sp = sctp_sk(sk); >> + >> + if (unlikely(sp->udp_port != sock_net(sk)->sctp.udp_port)) { > > RFC6951 has: > > 6.1. Get or Set the Remote UDP Encapsulation Port Number > (SCTP_REMOTE_UDP_ENCAPS_PORT) > ... > sue_assoc_id: This parameter is ignored for one-to-one style > sockets. For one-to-many style sockets, the application may fill > in an association identifier or SCTP_FUTURE_ASSOC for this query. > It is an error to use SCTP_{CURRENT|ALL}_ASSOC in sue_assoc_id. > > sue_address: This specifies which address is of interest. If a > wildcard address is provided, it applies only to future paths. > > So I'm not seeing a reason to have a system wide knob that takes > effect in run time like this. > Enable, start apps, and they keep behaving as initially configured. > Need to disable? Restart the apps/sockets. > > Thoughts? Just note about how things are implemented in FreeBSD. This is not about how it has to be implemented, but how it can be implemented. The local UDP encaps port is controlled by a system wide sysctl. sudo sysctl net.inet.sctp.udp_tunneling_port=9899 will use from that point on port 9899 the local encaps port. The local encaps port can't be controlled by the application. sudo sysctl net.inet.sctp.udp_tunneling_port=9900 will change this port number instantly to 9900. I don't see a use case for this, but it is possible. sudo sysctl net.inet.sctp.udp_tunneling_port=0 disables the sending and receiving of UDP encapsulated packets. The application can only control the remote encapsulation port on a per remote address base. This is mostly relevant for the client side wanting to use UDP encapsulation. Best regards Michael > >> + __u16 port = sock_net(sk)->sctp.udp_port; >> + >> + if (!sp->udp_port || !port) >> + sctp_assoc_update_frag_point(asoc); >> + sp->udp_port = port; >> + } >> } [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 5257 bytes --]
next prev parent reply other threads:[~2020-10-05 20:08 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-29 13:48 [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 01/15] udp: check udp sock encap_type in __udp_lib_err Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 02/15] udp6: move the mss check after udp gso tunnel processing Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 03/15] udp: do checksum properly in skb_udp_tunnel_segment Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 04/15] udp: support sctp over udp " Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 05/15] sctp: create udp4 sock and add its encap_rcv Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 06/15] sctp: create udp6 sock and set " Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:48 ` [PATCH net-next 07/15] sctp: add encap_err_lookup for udp encap socks Xin Long 2020-09-29 13:48 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 08/15] sctp: add encap_port for netns sock asoc and transport Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 09/15] sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 10/15] sctp: allow changing transport encap_port by peer packets Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 12/15] sctp: call sk_setup_caps in sctp_packet_transmit instead Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 13/15] sctp: support for sending packet over udp4 sock Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 14/15] sctp: support for sending packet over udp6 sock Xin Long 2020-09-29 13:49 ` Xin Long 2020-09-29 13:49 ` [PATCH net-next 15/15] sctp: enable udp tunneling socks Xin Long 2020-09-29 13:49 ` Xin Long 2020-10-03 4:12 ` Marcelo Ricardo Leitner 2020-10-03 4:12 ` Marcelo Ricardo Leitner 2020-10-03 8:20 ` Xin Long 2020-10-03 8:20 ` Xin Long 2020-09-29 16:25 ` [PATCH net-next 13/15] sctp: support for sending packet over udp4 sock kernel test robot 2020-09-29 16:25 ` kernel test robot 2020-09-30 6:26 ` Xin Long 2020-09-30 6:26 ` Xin Long 2020-09-29 19:19 ` kernel test robot 2020-09-29 19:19 ` kernel test robot 2020-10-03 4:09 ` [PATCH net-next 12/15] sctp: call sk_setup_caps in sctp_packet_transmit instead Marcelo Ricardo Leitner 2020-10-03 4:09 ` Marcelo Ricardo Leitner 2020-10-03 7:45 ` Xin Long 2020-10-03 7:45 ` Xin Long 2020-09-29 19:00 ` [PATCH net-next 11/15] sctp: add udphdr to overhead when udp_port is set kernel test robot 2020-09-29 19:00 ` kernel test robot 2020-10-03 4:08 ` Marcelo Ricardo Leitner 2020-10-03 4:08 ` Marcelo Ricardo Leitner 2020-10-03 7:57 ` Xin Long 2020-10-03 8:12 ` Xin Long 2020-10-03 11:23 ` Xin Long 2020-10-03 11:23 ` Xin Long 2020-10-03 12:24 ` Xin Long 2020-10-03 12:24 ` Xin Long 2020-10-05 19:01 ` Marcelo Ricardo Leitner 2020-10-05 19:01 ` Marcelo Ricardo Leitner 2020-10-05 20:08 ` Michael Tuexen [this message] 2020-10-05 20:08 ` Michael Tuexen 2020-10-08 9:37 ` Xin Long 2020-10-08 9:37 ` Xin Long 2020-10-03 4:07 ` Marcelo Ricardo Leitner 2020-10-03 4:07 ` Marcelo Ricardo Leitner 2020-10-03 7:54 ` Xin Long 2020-10-03 7:54 ` Xin Long 2020-10-03 4:06 ` [PATCH net-next 10/15] sctp: allow changing transport encap_port by peer packets Marcelo Ricardo Leitner 2020-10-03 4:06 ` Marcelo Ricardo Leitner 2020-10-03 4:05 ` [PATCH net-next 09/15] sctp: add SCTP_REMOTE_UDP_ENCAPS_PORT sockopt Marcelo Ricardo Leitner 2020-10-03 4:05 ` Marcelo Ricardo Leitner 2020-10-03 7:41 ` Xin Long 2020-10-03 7:41 ` Xin Long 2020-10-03 4:04 ` [PATCH net-next 03/15] udp: do checksum properly in skb_udp_tunnel_segment Marcelo Ricardo Leitner 2020-10-03 4:04 ` Marcelo Ricardo Leitner 2020-10-03 7:40 ` Xin Long 2020-10-03 7:40 ` Xin Long 2020-09-29 16:39 ` [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP Michael Tuexen 2020-09-29 16:39 ` Michael Tuexen 2020-09-29 17:49 ` Xin Long 2020-09-29 18:04 ` Xin Long 2020-10-01 12:41 ` Marcelo Ricardo Leitner 2020-10-01 12:41 ` Marcelo Ricardo Leitner
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=029F42A9-31CF-45B6-944D-912A005EE864@fh-muenster.de \ --to=tuexen@fh-muenster.de \ --cc=davem@davemloft.net \ --cc=kbuild-all@lists.01.org \ --cc=linux-sctp@vger.kernel.org \ --cc=lkp@intel.com \ --cc=lucien.xin@gmail.com \ --cc=marcelo.leitner@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=nhorman@tuxdriver.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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).