lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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