From patchwork Wed Dec 6 16:38:19 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexey Kodanev X-Patchwork-Id: 845251 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.b="Wx0gLWLk"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3ysPGg5RpSz9sBd for ; Thu, 7 Dec 2017 03:30:03 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751788AbdLFQaC (ORCPT ); Wed, 6 Dec 2017 11:30:02 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:51971 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751544AbdLFQaA (ORCPT ); Wed, 6 Dec 2017 11:30:00 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vB6GRP3O060168; Wed, 6 Dec 2017 16:29:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id; s=corp-2017-10-26; bh=3sld3ZihFESEpMHifV1HuRUCkS9zBN1eks2EtWTU7Mk=; b=Wx0gLWLkF1M99WIfwQXeBsht3eCCvRRYRN2/TknLSUSCXDudhcFfk5JsGOtJpSQISs3W LP+V50FTiidDm3FXglnLujbC6sim97XsqgCRYk5xHUbuDWDDqv+BlgSXrIWIVn9yfLrS 3zwoixIL7TZ7ss80QXvRZsFkew9kQIY2g8aJxjTFT4i7V5b+4X6zxtNn6F8rpPjMRVpN vLN7cW12uBwgegN0XfoC1a/H1umV/t+N9fjN4Dnbmd3IshXWzoT+qxNHPwF0kagQePQ3 +QSZCcZwDrsReeLTNezmixN92rstGJCdGGEqseqOGUeSih3uz29d9RPwq3Kwo3LMakTP gA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2epct99u5r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Dec 2017 16:29:47 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB6GTkS2022832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Dec 2017 16:29:46 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vB6GTkd6007638; Wed, 6 Dec 2017 16:29:46 GMT Received: from ak.ru.oracle.com (/10.162.80.29) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Dec 2017 08:29:45 -0800 From: Alexey Kodanev To: netdev@vger.kernel.org Cc: Steffen Klassert , David Miller , Petr Vorel , Alexey Kodanev Subject: [PATCH net-next] ip6_vti: adjust vti mtu according to mtu of output device Date: Wed, 6 Dec 2017 19:38:19 +0300 Message-Id: <1512578299-7573-1-git-send-email-alexey.kodanev@oracle.com> X-Mailer: git-send-email 1.7.1 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8736 signatures=668641 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060236 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams that require fragmentation and underlying device MTU <= 1500. This happens because ip6_vti sets mtu to ETH_DATA_LEN and not updating it depending on a destiantion address. Futhure attempts to send UDP packets may succeed because pmtu get updated on ICMPV6_PKT_TOOBIG in vti6_err(). Here is the example when output device MTU set to 9000: # ip a sh ltp_ns_veth2 ltp_ns_veth2@if7: mtu 9000 ... inet 10.0.0.2/24 scope global ltp_ns_veth2 inet6 fd00::2/64 scope global ... # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: mtu 1500 ... link/tunnel6 fd00::2 peer fd00::1 After the patch: # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: mtu 8832 ... link/tunnel6 fd00::2 peer fd00::1 Regarding ip_vti, it already tunes mtu with ip_tunnel_bind_dev(): # ip li add vti4 type vti local 10.0.0.2 remote 10.0.0.1 # ip li sh vti4 vti4@NONE: mtu 8832 ... link/ipip 10.0.0.2 peer 10.0.0.1 Reported-by: Petr Vorel Signed-off-by: Alexey Kodanev --- ip6_vti mtu offset is the same (168) as in ip_vti because ip_vti offset includes two sizes of struct iphdr: in dev->hard_header_len and in t_hlen in ip_tunnel_bind_dev(). I'm not sure if it's correct. net/ipv6/ip6_vti.c | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index dbb74f3..47e6464 100644 --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -638,6 +638,24 @@ static void vti6_link_config(struct ip6_tnl *t) dev->flags |= IFF_POINTOPOINT; else dev->flags &= ~IFF_POINTOPOINT; + + if (p->flags & IP6_TNL_F_CAP_XMIT) { + int strict = (ipv6_addr_type(&p->raddr) & + (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL)); + + struct rt6_info *rt = rt6_lookup(t->net, + &p->raddr, &p->laddr, + p->link, strict); + + if (!rt) + return; + + if (rt->dst.dev) { + dev->mtu = max(rt->dst.dev->mtu - dev->hard_header_len, + IPV6_MIN_MTU); + } + ip6_rt_put(rt); + } } /**