[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83a0b3e4-1327-c1c4-4eb4-9a25ff533d1d@redhat.com>
Date: Fri, 25 Nov 2022 16:29:29 +0100
From: Adrian Moreno <amorenoz@...hat.com>
To: Ilya Maximets <i.maximets@....org>,
Aaron Conole <aconole@...hat.com>, netdev@...r.kernel.org
Cc: dev@...nvswitch.org, linux-kernel@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>,
linux-kselftest@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [ovs-dev] [RFC net-next 1/6] openvswitch: exclude kernel flow key
from upcalls
On 11/23/22 22:22, Ilya Maximets wrote:
> On 11/22/22 15:03, Aaron Conole wrote:
>> When processing upcall commands, two groups of data are available to
>> userspace for processing: the actual packet data and the kernel
>> sw flow key data. The inclusion of the flow key allows the userspace
>> avoid running through the dissection again.
>>
>> However, the userspace can choose to ignore the flow key data, as is
>> the case in some ovs-vswitchd upcall processing. For these messages,
>> having the flow key data merely adds additional data to the upcall
>> pipeline without any actual gain. Userspace simply throws the data
>> away anyway.
>
> Hi, Aaron. While it's true that OVS in userpsace is re-parsing the
> packet from scratch and using the newly parsed key for the OpenFlow
> translation, the kernel-porvided key is still used in a few important
> places. Mainly for the compatibility checking. The use is described
> here in more details:
> https://docs.kernel.org/networking/openvswitch.html#flow-key-compatibility
>
> We need to compare the key generated in userspace with the key
> generated by the kernel to know if it's safe to install the new flow
> to the kernel, i.e. if the kernel and OVS userpsace are parsing the
> packet in the same way.
>
Hi Ilya,
Do we need to do that for every packet?
Could we send a bitmask of supported fields to userspace at feature negotiation
and let OVS slowpath flows that it knows the kernel won't be able to handle
properly?
> On the other hand, OVS today doesn't check the data, it only checks
> which fields are present. So, if we can generate and pass the bitmap
> of fields present in the key or something similar without sending the
> full key, that might still save some CPU cycles and memory in the
> socket buffer while preserving the ability to check for forward and
> backward compatibility. What do you think?
>
>
> The rest of the patch set seems useful even without patch #1 though.
>
> Nit: This patch #1 should probably be merged with the patch #6 and be
> at the end of a patch set, so the selftest and the main code are updated
> at the same time.
>
> Best regards, Ilya Maximets.
> _______________________________________________
> dev mailing list
> dev@...nvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
Thanks
--
Adrián Moreno
Powered by blists - more mailing lists