Message ID | 20221122140307.705112-2-aconole@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2219636wrr; Tue, 22 Nov 2022 06:10:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf7Lk1/2OgsByI22/jqQXCWS9Tpft7hhE1g+2IF2hh60UikjJINDp5gCDqwEKinsFQTPLW2g X-Received: by 2002:aa7:9af5:0:b0:56c:b5fc:9167 with SMTP id y21-20020aa79af5000000b0056cb5fc9167mr5674151pfp.40.1669126213892; Tue, 22 Nov 2022 06:10:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669126213; cv=none; d=google.com; s=arc-20160816; b=HTWeFGyfMRxUnT8fpmgvxziTY0coBojLnMIA+spXNXap20Z88mUGnzvkoq6J8RFLTv fqXfBZrl8ctQOuv2We6f1GWefdStQ2zp5hxOKsCC2ZxhImq4wSi56QmKIWfBIZxbXSXW biryIDWsWxgBUHRw8IDZ3uQ+LokGB0+x1QncGpjE76G8k0uo6/mhT8alaCTbtJbtFFTF /J2lZqWqKiHqavDzvRcs3r5VhTmzJDrX0nNODFufr63QJtXYKr3r2BOIsx6lH1uMUFbe GZ6XsyIYdLXQ1bIwiYHphbbLoj2VCY8HlUp1hEANgZrqFYmT6/gFEv7n8M0EmttdlDT9 yC+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Dwl7SbsKJoZEUQcBj1alw3gjGL8Zf4MEaXU4djfJOx0=; b=guMTNCKR4MEgR+fMRpGegBKlp1qZya8JhBnSIdplMmMYxxGq6kV4eInip9UEV3cPRQ aXcG0BnP0EbDmr01QPZvMVHx9ojKZiOVDgaj9IJSRwTxnakuPNa5jCsxggegPYY331ny YXS6ZDXoF+VZHHR7NPCdyUEE7l8LUNFDluUCxt6vAPulOLR/EIF2FFzweituDHfseaCK s3UNMLcexShdOp6AJueUCaC2N9ZD3tX2qr/ZNcoqxo8p9AN1MxaR3NJ4DyC0jfF9Uhql uoQflgO3lLR+zaqWDZ9mH56AEdg1fIwfcl/m0Nxhg+Splk1rkKrULRgNTqO5bKDsyY7c fTJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Vqamq8Di; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 4-20020a17090a1a4400b00218c0f831bbsi3735398pjl.111.2022.11.22.06.09.52; Tue, 22 Nov 2022 06:10:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Vqamq8Di; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233960AbiKVOEW (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Tue, 22 Nov 2022 09:04:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233008AbiKVOEM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 22 Nov 2022 09:04:12 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E3A81D65D for <linux-kernel@vger.kernel.org>; Tue, 22 Nov 2022 06:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669125793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dwl7SbsKJoZEUQcBj1alw3gjGL8Zf4MEaXU4djfJOx0=; b=Vqamq8DiIVFobKw9hz46nUstpRCZu7uI+d778HL9fhI6xMAakieFvtRGu7Bn8qXWt/jgTg PbtmLsTjW93ra9kTNOX7a97EwnuQ7lFu1873rtn+IeZagME4BsxxsHrJy3wpU8ZZAocrW+ wQ7rdMzMiDXowKIupmlSz5tM/BcY1qY= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-265-Pe1qYOMCPw-rHDPPfBq8NA-1; Tue, 22 Nov 2022 09:03:11 -0500 X-MC-Unique: Pe1qYOMCPw-rHDPPfBq8NA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A8A38811E75; Tue, 22 Nov 2022 14:03:10 +0000 (UTC) Received: from RHTPC1VM0NT.redhat.com (unknown [10.22.16.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 33BDC40C6EC6; Tue, 22 Nov 2022 14:03:10 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: netdev@vger.kernel.org Cc: Pravin B Shelar <pshelar@ovn.org>, Jakub Kicinski <kuba@kernel.org>, "David S. Miller" <davem@davemloft.net>, Paolo Abeni <pabeni@redhat.com>, Eric Dumazet <edumazet@google.com>, Thomas Graf <tgraf@suug.ch>, dev@openvswitch.org, Eelco Chaudron <echaudro@redhat.com>, Ilya Maximets <i.maximets@ovn.org>, Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [RFC net-next 1/6] openvswitch: exclude kernel flow key from upcalls Date: Tue, 22 Nov 2022 09:03:02 -0500 Message-Id: <20221122140307.705112-2-aconole@redhat.com> In-Reply-To: <20221122140307.705112-1-aconole@redhat.com> References: <20221122140307.705112-1-aconole@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750205688771162812?= X-GMAIL-MSGID: =?utf-8?q?1750205688771162812?= |
Series |
Allow excluding sw flow key from upcalls
|
|
Commit Message
Aaron Conole
Nov. 22, 2022, 2:03 p.m. UTC
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.
Introduce a new feature OVS_DP_F_EXCLUDE_UPCALL_FLOW_KEY which signals
that the userspace doesn't want upcalls included with specific class
of message (for example MISS messages). The associated attribute
OVS_DP_ATTR_EXCLUDE_CMDS tells which specific commands to omit via a
bitmask.
A test will be added to showcase using the feature.
Signed-off-by: Aaron Conole <aconole@redhat.com>
---
include/uapi/linux/openvswitch.h | 6 ++++++
net/openvswitch/datapath.c | 26 ++++++++++++++++++++++----
net/openvswitch/datapath.h | 2 ++
3 files changed, 30 insertions(+), 4 deletions(-)
Comments
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. 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.
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@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > Thanks
On 11/25/22 16:29, Adrian Moreno wrote: > > > 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? It's not that simple, because supported fields in a packet depend on previous fields in that same packet. For example, parsing TCP header is generally supported, but it won't be parsed for IPv6 fragments (even the first one), number of vlan headers will affect the parsing as we do not parse deeper than 2 vlan headers, etc. So, I'm afraid we have to have a per-packet information, unless we can somehow probe all the possible valid combinations of packet headers. > > >> 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@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > > Thanks
On 11/25/22 16:51, Ilya Maximets wrote: > On 11/25/22 16:29, Adrian Moreno wrote: >> >> >> 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? > > It's not that simple, because supported fields in a packet depend > on previous fields in that same packet. For example, parsing TCP > header is generally supported, but it won't be parsed for IPv6 > fragments (even the first one), number of vlan headers will affect > the parsing as we do not parse deeper than 2 vlan headers, etc. > So, I'm afraid we have to have a per-packet information, unless we > can somehow probe all the possible valid combinations of packet > headers. > Surely. I understand that we'd need more than just a bit per field. Things like L4 on IPv6 frags would need another bit and the number of VLAN headers would need some more. But, are these a handful of exceptions or do we really need all the possible combinations of headers? If it's a matter of naming a handful of corner cases I think we could consider expressing them at initialization time and safe some buffer space plus computation time both in kernel and userspace.
Adrian Moreno <amorenoz@redhat.com> writes: > On 11/25/22 16:51, Ilya Maximets wrote: >> On 11/25/22 16:29, Adrian Moreno wrote: >>> >>> >>> 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? >> It's not that simple, because supported fields in a packet depend >> on previous fields in that same packet. For example, parsing TCP >> header is generally supported, but it won't be parsed for IPv6 >> fragments (even the first one), number of vlan headers will affect >> the parsing as we do not parse deeper than 2 vlan headers, etc. >> So, I'm afraid we have to have a per-packet information, unless we >> can somehow probe all the possible valid combinations of packet >> headers. >> > > Surely. I understand that we'd need more than just a bit per > field. Things like L4 on IPv6 frags would need another bit and the > number of VLAN headers would need some more. But, are these a handful > of exceptions or do we really need all the possible combinations of > headers? If it's a matter of naming a handful of corner cases I think > we could consider expressing them at initialization time and safe some > buffer space plus computation time both in kernel and userspace. I will take a bit more of a look here - there must surely be a way to express this when pulling information via DP_GET command so that we don't need to wait for a packet to come in to figure out whether we can parse it.
Ilya Maximets <i.maximets@ovn.org> writes: > 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. > > 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? Maybe that can work. I will try testing. If so, then I would change this semantic to send just the bitmap rather than omitting everything. > The rest of the patch set seems useful even without patch #1 though. I agree - but I didn't know if it made sense to submit the series without adding something impactful (like a test). I will work a bit more on the flow area - maybe I can add enough actions and matches to implement basic flow tests to submit while we think more about the feature. > 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. Okay - I can restructure them this way. > Best regards, Ilya Maximets.
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h index 94066f87e9ee..238e62ecba46 100644 --- a/include/uapi/linux/openvswitch.h +++ b/include/uapi/linux/openvswitch.h @@ -95,6 +95,9 @@ enum ovs_datapath_attr { * per-cpu dispatch mode */ OVS_DP_ATTR_IFINDEX, + OVS_DP_ATTR_EXCLUDE_CMDS, /* u32 mask of OVS_PACKET_CMDs for + * omitting FLOW_KEY attribute + */ __OVS_DP_ATTR_MAX }; @@ -138,6 +141,9 @@ struct ovs_vport_stats { /* Allow per-cpu dispatch of upcalls */ #define OVS_DP_F_DISPATCH_UPCALL_PER_CPU (1 << 3) +/* Drop Flow key data from upcall packet cmds */ +#define OVS_DP_F_EXCLUDE_UPCALL_FLOW_KEY (1 << 4) + /* Fixed logical ports. */ #define OVSP_LOCAL ((__u32)0) diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c index 861dfb8daf4a..6afde7de492c 100644 --- a/net/openvswitch/datapath.c +++ b/net/openvswitch/datapath.c @@ -470,9 +470,13 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb, } upcall->dp_ifindex = dp_ifindex; - err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false, user_skb); - if (err) - goto out; + if (!(dp->user_features & OVS_DP_F_EXCLUDE_UPCALL_FLOW_KEY) || + !(dp->upcall_exclude_cmds & (1U << upcall_info->cmd))) { + err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false, + user_skb); + if (err) + goto out; + } if (upcall_info->userdata) __nla_put(user_skb, OVS_PACKET_ATTR_USERDATA, @@ -1526,6 +1530,7 @@ static size_t ovs_dp_cmd_msg_size(void) msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_USER_FEATURES */ msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_MASKS_CACHE_SIZE */ msgsize += nla_total_size(sizeof(u32) * nr_cpu_ids); /* OVS_DP_ATTR_PER_CPU_PIDS */ + msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_EXCLUDE_CMDS */ return msgsize; } @@ -1574,6 +1579,10 @@ static int ovs_dp_cmd_fill_info(struct datapath *dp, struct sk_buff *skb, goto nla_put_failure; } + if (nla_put_u32(skb, OVS_DP_ATTR_EXCLUDE_CMDS, + dp->upcall_exclude_cmds)) + goto nla_put_failure; + genlmsg_end(skb, ovs_header); return 0; @@ -1684,7 +1693,8 @@ static int ovs_dp_change(struct datapath *dp, struct nlattr *a[]) if (user_features & ~(OVS_DP_F_VPORT_PIDS | OVS_DP_F_UNALIGNED | OVS_DP_F_TC_RECIRC_SHARING | - OVS_DP_F_DISPATCH_UPCALL_PER_CPU)) + OVS_DP_F_DISPATCH_UPCALL_PER_CPU | + OVS_DP_F_EXCLUDE_UPCALL_FLOW_KEY)) return -EOPNOTSUPP; #if !IS_ENABLED(CONFIG_NET_TC_SKB_EXT) @@ -1705,6 +1715,14 @@ static int ovs_dp_change(struct datapath *dp, struct nlattr *a[]) dp->user_features = user_features; + if (dp->user_features & OVS_DP_F_EXCLUDE_UPCALL_FLOW_KEY) { + if (!a[OVS_DP_ATTR_EXCLUDE_CMDS]) + return -EINVAL; + + dp->upcall_exclude_cmds = + nla_get_u32(a[OVS_DP_ATTR_EXCLUDE_CMDS]); + } + if (dp->user_features & OVS_DP_F_DISPATCH_UPCALL_PER_CPU && a[OVS_DP_ATTR_PER_CPU_PIDS]) { /* Upcall Netlink Port IDs have been updated */ diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h index 0cd29971a907..3c951e25509e 100644 --- a/net/openvswitch/datapath.h +++ b/net/openvswitch/datapath.h @@ -101,6 +101,8 @@ struct datapath { u32 max_headroom; + u32 upcall_exclude_cmds; + /* Switch meters. */ struct dp_meter_table meter_tbl;