From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net] sctp: use the pmtu from the icmp packet to update transport pathmtu Date: Mon, 15 Oct 2018 22:55:43 -0700 (PDT) Message-ID: <20181015.225543.331760686954565853.davem@davemloft.net> References: Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, linux-sctp@vger.kernel.org, marcelo.leitner@gmail.com, nhorman@tuxdriver.com To: lucien.xin@gmail.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:44160 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727014AbeJPNoa (ORCPT ); Tue, 16 Oct 2018 09:44:30 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: Xin Long Date: Mon, 15 Oct 2018 19:58:29 +0800 > Other than asoc pmtu sync from all transports, sctp_assoc_sync_pmtu > is also processing transport pmtu_pending by icmp packets. But it's > meaningless to use sctp_dst_mtu(t->dst) as new pmtu for a transport. > > The right pmtu value should come from the icmp packet, and it would > be saved into transport->mtu_info in this patch and used later when > the pmtu sync happens in sctp_sendmsg_to_asoc or sctp_packet_config. > > Besides, without this patch, as pmtu can only be updated correctly > when receiving a icmp packet and no place is holding sock lock, it > will take long time if the sock is busy with sending packets. > > Note that it doesn't process transport->mtu_info in .release_cb(), > as there is no enough information for pmtu update, like for which > asoc or transport. It is not worth traversing all asocs to check > pmtu_pending. So unlike tcp, sctp does this in tx path, for which > mtu_info needs to be atomic_t. > > Signed-off-by: Xin Long Applied.