From: Minxi Hou <houminxi@gmail.com>
To: netdev@vger.kernel.org
Cc: Donald Hunter <donald.hunter@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>
Subject: [PATCH net-next v5 0/2] netlink: specs: fill in the missing ovs operations
Date: Tue, 3 Nov 2026 13:33:17 -0500 [thread overview]
Message-ID: <20261103183319.2730567-1-houminxi@gmail.com> (raw)
The ovs specs describe get and new but not the set and del commands the
kernel has registered since the families were added. This series adds
them and names the attributes each handler reads. Nothing here changes
how the kernel behaves.
v5:
https://lore.kernel.org/netdev/20261025103409.3519874-1-houminxi@gmail.com/
- ovs_flow dump gets a request list of its own with ufid-flags. It
shared the get list, which offered a key and a ufid the kernel
ignores on a dump. The reply is unchanged.
- The key, actions and ufid docs no longer claim those attributes are
always present, and say what the exceptions are: a ufid-identified
flow sends no key or actions when the request asked for them to be
left out, a dump leaves the actions out when they do not fit, and a
dump ignores the ufid. The same sentences in
include/uapi/linux/openvswitch.h are updated to match, since the
spec text was copied from there.
- The key doc now says a get and a set need a key or a ufid, that a
new request needs a key, and that a del carrying neither flushes the
data path.
- The ovs_datapath new and set docs say per-cpu-pids takes effect only
when the same request sets OVS_DP_F_DISPATCH_UPCALL_PER_CPU in
user-features.
- The ovs_vport set doc says the vport is picked by name or by port
number, names the rejections in the order the kernel checks them,
and says upcall-pid is the only attribute that changes state.
- Rebased onto current net-next after the merge window.
v4:
https://lore.kernel.org/netdev/20261015024132.698658-1-houminxi@gmail.com/
- ovs_vport set lists port-no and ifindex. lookup_vport() finds a
vport by name or by port number, and returns -EOPNOTSUPP as soon as
it sees an ifindex, before the type or the options are looked at.
- ovs_datapath new lists masks-cache-size, per-cpu-pids and ifindex.
new calls ovs_dp_change(), which reads the first two, and reads
ifindex itself.
- ovs_flow get lists probe. ovs_flow_cmd_get() reads it to decide
whether to log.
- The key attribute doc now says a new request needs a key even when
it finds an existing flow and replaces its actions, and that a dump
reads neither the key nor the ufid. A del with neither flushes the
data path, and the del operation doc says so too.
v3:
https://lore.kernel.org/netdev/20261012065552.2426415-1-houminxi@gmail.com/
- no change since v2.
v2:
https://lore.kernel.org/netdev/20261006130533.1620706-1-houminxi@gmail.com/
- ovs_flow new lists ufid-flags and probe, which ovs_flow_cmd_new()
reads.
- The commit message now says probe changes from binary to flag, and
that new needs CAP_NET_ADMIN.
- The key attribute doc no longer says a key is required for every
request except a dump. get, set and del accept a ufid with no key,
and only a new flow needs a key. A set that replaces the actions
still needs a key.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Minxi Hou (2):
netlink: specs: add ovs_flow del and set operations
netlink: specs: add ovs datapath and vport set operations
Documentation/netlink/specs/ovs_datapath.yaml | 27 ++++++-
Documentation/netlink/specs/ovs_flow.yaml | 76 +++++++++++++++----
Documentation/netlink/specs/ovs_vport.yaml | 22 ++++++
include/uapi/linux/openvswitch.h | 17 +++--
4 files changed, 123 insertions(+), 19 deletions(-)
base-commit: 7b6ab4dbc156e2f96419715130b3d5738a306c93
--
2.56.0
next reply other threads:[~2026-11-03 18:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 18:33 Minxi Hou [this message]
2026-11-03 18:33 ` [PATCH net-next v5 1/2] netlink: specs: add ovs_flow del and set operations Minxi Hou
2026-11-03 18:33 ` [PATCH net-next v5 2/2] netlink: specs: add ovs datapath and vport " Minxi Hou
2026-11-04 17:26 ` [PATCH net-next v5 0/2] netlink: specs: fill in the missing ovs operations Minxi Hou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261103183319.2730567-1-houminxi@gmail.com \
--to=houminxi@gmail.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox