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 5FD5C12F5A2 for ; Wed, 27 Mar 2024 17:17:53 +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=1711559875; cv=none; b=MRuUanf7Fxkh2gKVpITjVgEmT+fF4cNteb5zgKfKphhD4hAYGVtwUeNgjGFOq7JMfJ2L4wBPhPwQfjEHzHoGxEISdcTZDY/RFZjYYI3y0x3C3mE+NlPzF/M4zKWS1w+Piw63g/gfTjtc/TdMCuSwEKkSwoP9JlMVJeryhoXbn4o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711559875; c=relaxed/simple; bh=UA3aAZ6OJD/YBTezWMH3e5Ei1wRNk1JwfdDlSOWXRl0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=eoqdAI1PAksRfojXOVF7b3u4JLgtS2CjB5qccfIDhEMRdNcSdVdMs4YC/Gm76XTXbkzuW8CDdV5RgoQi0jYiyk7hScVaVcTm112d6QwrqCt9LOfOW6+ROH2BAQYqwB3j77UE6YxpktnBIBxmr/KI+aHf5y2cbVl+7xggeaLZ3Fw= 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=frpurN/E; 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="frpurN/E" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711559872; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=brnN/NCeTstfV3DWN+AFy3XAX/hGuMmV9sRUj5MIAgg=; b=frpurN/E/4fA3QsjaEO6ghGXJKvmEbLvQC8+mUSXiU+fajktYJJeHCP2Vtyl5qbqDTO9Wq cilVr2crdwjLwDoPfAaHOxBJi+xr8+IDyWDhzu47FV7NGhrVVEXaT02rT04IPpI7VI1LQq ++mFge8ONv1Fppzrl7EimJTof4Gr8xk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-450-ANzFHTBkPCSIIzq1MCJC4g-1; Wed, 27 Mar 2024 13:17:47 -0400 X-MC-Unique: ANzFHTBkPCSIIzq1MCJC4g-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E894D1E441C1; Wed, 27 Mar 2024 17:17:46 +0000 (UTC) Received: from RHTPC1VM0NT (dhcp-17-72.bos.redhat.com [10.18.17.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54EF51121306; Wed, 27 Mar 2024 17:17:46 +0000 (UTC) From: Aaron Conole To: Eelco Chaudron Cc: Ilya Maximets , dev@openvswitch.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Dumazet , Jakub Kicinski , Paolo Abeni , "David S. Miller" Subject: Re: [ovs-dev] [PATCH net] openvswitch: Set the skbuff pkt_type for proper pmtud support. References: <20240322190603.251831-1-aconole@redhat.com> <7AFF5D6D-568C-449B-83CF-9436DE97CA91@redhat.com> <4066cc6a-24a8-4d05-b180-99222fe792fa@ovn.org> <4C04D4FF-0ADF-45DC-B253-2CD5C997DA1B@redhat.com> Date: Wed, 27 Mar 2024 13:17:46 -0400 In-Reply-To: <4C04D4FF-0ADF-45DC-B253-2CD5C997DA1B@redhat.com> (Eelco Chaudron's message of "Mon, 25 Mar 2024 13:57:22 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 Eelco Chaudron writes: > On 25 Mar 2024, at 13:37, Ilya Maximets wrote: > >> On 3/25/24 13:22, Aaron Conole wrote: >>> Eelco Chaudron writes: >>> >>>> On 22 Mar 2024, at 20:06, Aaron Conole wrote: >>>> >>>>> Open vSwitch is originally intended to switch at layer 2, only dealin= g with >>>>> Ethernet frames. With the introduction of l3 tunnels support, it cro= ssed >>>>> into the realm of needing to care a bit about some routing details wh= en >>>>> 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 t= he >>>>> 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. >>>> >>>> Is this not a problem when the packet comes from the bridge port in th= e kernel? >>> >>> It very well may be an issue there as well, but the recommendation is to >>> operate with the bridge port down as far as I know, so I don't know if >>> this issue has been observed happening from the bridge port. >> >> FWIW, bridge ports are typically used as an entry point for tunneled >> traffic so it can egress from a physical port attached to OVS. It means >> they are pretty much always UP in most common setups like OpenStack or >> ovn-kubernetes and handle a decent amount of traffic. They are also used >> to direct some other types of traffic to the host kernel. > > +1 here, I=E2=80=99m talking about the same port. I think we only advise > having this down for userspace bridges, but not in the case the bridge > is the tunnel endpoint. Okay, I'll confirm about up/down, but it seems like it shouldn't matter and we should be setting the outgoing type. >> Unless I misunderstood which ports we're talking about here. >> >> Best regards, Ilya Maximets.