[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4066cc6a-24a8-4d05-b180-99222fe792fa@ovn.org>
Date: Mon, 25 Mar 2024 13:37:41 +0100
From: Ilya Maximets <i.maximets@....org>
To: Aaron Conole <aconole@...hat.com>, Eelco Chaudron <echaudro@...hat.com>
Cc: dev@...nvswitch.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"David S. Miller" <davem@...emloft.net>, i.maximets@....org
Subject: Re: [ovs-dev] [PATCH net] openvswitch: Set the skbuff pkt_type for
proper pmtud support.
On 3/25/24 13:22, Aaron Conole wrote:
> Eelco Chaudron <echaudro@...hat.com> writes:
>
>> On 22 Mar 2024, at 20:06, 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.
>>
>> Is this not a problem when the packet comes from the bridge port in the 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.
Unless I misunderstood which ports we're talking about here.
Best regards, Ilya Maximets.
Powered by blists - more mailing lists