From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E6E94F88A for ; Tue, 21 May 2024 10:09:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716286188; cv=none; b=hP6xOdGX/A6F+r8XMlKCH7Tdvz+jkBqeLA0mUynXvejIs/nO4GZwV/g7Vm7m+jmMXDwgu3ZEb7GOjHNU9TGzocIOWUn2D7lN4mtcBo8HB2dkK6xkaGQ43VoFM2L2tQsKlmhL37JkYkbQE2SjY1XFGlu+F/JHeqSJOlixXo9rlR4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716286188; c=relaxed/simple; bh=LY84E1RWWk3jAofPEJLObQHNu/Ia/tP48sDzh7KJUqo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fXt1aJHh8saRK1WooL1WzoiYk0qpo3ukO9RJyVfACZPRoswuEZWNM7IAdMrqQZ0v3Fyzw8mxjGiu6HkhdkxEL1N7WWlr35nX5ui6y40u7ZntVufnFRt7Jqze1RYD0HPUbULezzJhstGzfFo1lDUPXojIgec3Nis6w0bhQ4+fqVo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UzhUU4iQ; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UzhUU4iQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716286185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nIc2pXGjQ+me7ZvTYeZx+G3dW7IZswOqXUWkt6vgNEc=; b=UzhUU4iQspAGZogVP8iIm3SY29UXhsjMJaZ5omLad4CVsIsMemWzALSn/IwoUdICbULDsa qC3sM1JtCEFNPePfq4e3ddZsRDnC1K/px0d5k6snCMcKgGNEbkv+J/HRFdoM9EjZDOzYYk 1yJXNuc337JQecqqNvtuhXc7N29nFcQ= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-z7dxmzcjO6eWSBrF0wuZmQ-1; Tue, 21 May 2024 06:09:44 -0400 X-MC-Unique: z7dxmzcjO6eWSBrF0wuZmQ-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a59eea00cafso829701566b.1 for ; Tue, 21 May 2024 03:09:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716286183; x=1716890983; h=mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nIc2pXGjQ+me7ZvTYeZx+G3dW7IZswOqXUWkt6vgNEc=; b=WtWT0L77aN+MZ5OIHc32gOrX7FjqyJ8bvQ9usphJAsQykEH6bMlUsQGWpl+3Nw9pxn Ccim+aUOqn3dowFiQRubF481xaa/KXa+6RerZgVXtrC40U5aNmz3JIq3MXd7sO+uSlV9 xH6oz5/4sKQIA85smEqzMLrhTYKo9DXhEEV8veo3yO3ywLM8pjb5eSQ3hn8g0bmPJjpc CWyqECkp+ndQxq8eVbEuZyhW+Z3t0bUsnp5CJvVvNl06tKXznif546wHucOyhfAHq9jq k4aO2z/VVsnY4n8vXTH7tF8MQvZs/ZqEY4OyVAEd1+ApOwmgdhCeCAVuyLahocL57rac i31g== X-Forwarded-Encrypted: i=1; AJvYcCUirWMWSlE5IK7kPiZywqi82A8AJqxCwAN77zvK6RRHLU0NiX3kYMQqUUxq9dMSNouz4eAD7JvDqSwZJQUknXTmk1rIVYxIXa1hXBPi X-Gm-Message-State: AOJu0YxoaVmUD/5dxK8C1xvzQvDuLEJdFfMynh9uzntAGA+gW5ic3akH acWFs+u6WAPnU9VDZucmqEyd7dB/utu7PJt4UcdlaTV6/uTG+iJKrcQnkXY6Y8IUl6HgT5L/bxR btAu7HIV0gOhZEuOJQh+yeSW98nZT6hfIlKH4gGoPR673uJN7Yk2QDAzS8S9VjBEW8lqchg== X-Received: by 2002:a17:906:fe07:b0:a5a:81b0:a6a9 with SMTP id a640c23a62f3a-a5a81b0a73cmr2446484666b.53.1716286182722; Tue, 21 May 2024 03:09:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFRdhoc2N3wtE730xVnMpA89nBQtXnC9LJWRX7m/mx+FTIPUDLCEt36je34xFicbR7eTgGF6A== X-Received: by 2002:a17:906:fe07:b0:a5a:81b0:a6a9 with SMTP id a640c23a62f3a-a5a81b0a73cmr2446481266b.53.1716286182230; Tue, 21 May 2024 03:09:42 -0700 (PDT) Received: from [172.16.2.75] (5920ab7b.static.cust.trined.nl. [89.32.171.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a5a17b01dfcsm1589898066b.187.2024.05.21.03.09.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 May 2024 03:09:40 -0700 (PDT) From: Eelco Chaudron To: Aaron Conole Cc: netdev@vger.kernel.org, dev@openvswitch.org, linux-kernel@vger.kernel.org, Pravin B Shelar , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jesse Gross , Ilya Maximets , Simon Horman , Jaime Caamano Subject: Re: [PATCH v2 net] openvswitch: Set the skbuff pkt_type for proper pmtud support. Date: Tue, 21 May 2024 12:09:39 +0200 X-Mailer: MailMate (1.14r6030) Message-ID: <701FCF52-7D25-4094-9B0E-8F7AE8A68107@redhat.com> In-Reply-To: <20240516200941.16152-1-aconole@redhat.com> References: <20240516200941.16152-1-aconole@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 16 May 2024, at 22:09, Aaron Conole wrote: > Open vSwitch is originally intended to switch at layer 2, only dealing with > Ethernet frames. With the introduction of l3 tunnels support, it crossed > into the realm of needing to care a bit about some routing details when > making forwarding decisions. If an oversized packet would need to be > fragmented during this forwarding decision, there is a chance for pmtu > to get involved and generate a routing exception. This is gated by the > skbuff->pkt_type field. > > When a flow is already loaded into the openvswitch module this field is > set up and transitioned properly as a packet moves from one port to > another. In the case that a packet execute is invoked after a flow is > newly installed this field is not properly initialized. This causes the > pmtud mechanism to omit sending the required exception messages across > the tunnel boundary and a second attempt needs to be made to make sure > that the routing exception is properly setup. To fix this, we set the > outgoing packet's pkt_type to PACKET_OUTGOING, since it can only get > to the openvswitch module via a port device or packet command. > > Even for bridge ports as users, the pkt_type needs to be reset when > doing the transmit as the packet is truly outgoing and routing needs > to get involved post packet transformations, in the case of > VXLAN/GENEVE/udp-tunnel packets. In general, the pkt_type on output > gets ignored, since we go straight to the driver, but in the case of > tunnel ports they go through IP routing layer. > > This issue is periodically encountered in complex setups, such as large > openshift deployments, where multiple sets of tunnel traversal occurs. > A way to recreate this is with the ovn-heater project that can setup > a networking environment which mimics such large deployments. We need > larger environments for this because we need to ensure that flow > misses occur. In these environment, without this patch, we can see: > > ./ovn_cluster.sh start > podman exec ovn-chassis-1 ip r a 170.168.0.5/32 dev eth1 mtu 1200 > podman exec ovn-chassis-1 ip netns exec sw01p1 ip r flush cache > podman exec ovn-chassis-1 ip netns exec sw01p1 \ > ping 21.0.0.3 -M do -s 1300 -c2 > PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data. > From 21.0.0.3 icmp_seq=2 Frag needed and DF set (mtu = 1142) > > --- 21.0.0.3 ping statistics --- > ... > > Using tcpdump, we can also see the expected ICMP FRAG_NEEDED message is not > sent into the server. > > With this patch, setting the pkt_type, we see the following: > > podman exec ovn-chassis-1 ip netns exec sw01p1 \ > ping 21.0.0.3 -M do -s 1300 -c2 > PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data. > From 21.0.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1222) > ping: local error: message too long, mtu=1222 > > --- 21.0.0.3 ping statistics --- > ... > > In this case, the first ping request receives the FRAG_NEEDED message and > a local routing exception is created. > > Tested-by: Jaime Caamano > Reported-at: https://issues.redhat.com/browse/FDP-164 > Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.") > Signed-off-by: Aaron Conole Thanks for the additional comments and detailed commit message. The change looks good to me. Acked-by: Eelco Chaudron