Patch "openvswitch: Set the skbuff pkt_type for proper pmtud support." has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    openvswitch: Set the skbuff pkt_type for proper pmtud support.

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     openvswitch-set-the-skbuff-pkt_type-for-proper-pmtud.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 82d0ec83d283cd08d5f8d7868f2b7e23343c6e1d
Author: Aaron Conole <aconole@xxxxxxxxxx>
Date:   Thu May 16 16:09:41 2024 -0400

    openvswitch: Set the skbuff pkt_type for proper pmtud support.
    
    [ Upstream commit 30a92c9e3d6b073932762bef2ac66f4ee784c657 ]
    
    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 <jcaamano@xxxxxxxxxx>
    Reported-at: https://issues.redhat.com/browse/FDP-164
    Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.")
    Signed-off-by: Aaron Conole <aconole@xxxxxxxxxx>
    Acked-by: Eelco Chaudron <echaudro@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20240516200941.16152-1-aconole@xxxxxxxxxx
    Signed-off-by: Paolo Abeni <pabeni@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index fd66014d8a76a..4f5cbcaa38386 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -929,6 +929,12 @@ static void do_output(struct datapath *dp, struct sk_buff *skb, int out_port,
 				pskb_trim(skb, ovs_mac_header_len(key));
 		}
 
+		/* Need to set the pkt_type to involve the routing layer.  The
+		 * packet movement through the OVS datapath doesn't generally
+		 * use routing, but this is needed for tunnel cases.
+		 */
+		skb->pkt_type = PACKET_OUTGOING;
+
 		if (likely(!mru ||
 		           (skb->len <= mru + vport->dev->hard_header_len))) {
 			ovs_vport_send(vport, skb, ovs_key_mac_proto(key));




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux