Re: [PATCH net-next 2/2] netlink: specs: add ovs datapath and vport set operations

[Minxi Hou <houminxi@gmail.com>]

On Thu, 8 Oct 2026, netdev-bot+sashiko@kernel.org wrote:
> [Medium] Should port-no be in the vport set request list as well?

No. lookup_vport() does accept OVS_VPORT_ATTR_PORT_NO plus the
datapath ifindex from the header, and the del op in this spec lists
port-no. But get lists only name, and new does not list port-no
either. Adding it to set alone would make the three lookup keys
disagree.

The lookup key is a property of the whole spec, not of the set op
this patch adds. I left it as the file already writes it.

> [Low] Is it useful to list options here? ovs_vport_cmd_set() returns
> -EOPNOTSUPP whenever it is present.

The list is the attributes the handler reads, not the ones it
accepts. type is in the same list and a changed type returns -EINVAL
(datapath.c, ovs_vport_cmd_set()). options returns -EOPNOTSUPP and the
policy marks it unused. Dropping one and keeping the other would need
a rule for which rejections to hide. The commit message already says
the handler rejects options.

> [Low] Should the datapath set doc also say how per-cpu-pids depends
> on user-features?

ovs_dp_change() applies per-cpu-pids only when the same request turns
on OVS_DP_F_DISPATCH_UPCALL_PER_CPU. That part of the reading is
right. The doc already says that a missing user-features attribute is
taken as zero and clears the features, which is the half that changes
state. The pids are ignored and the request still succeeds. I left
that out so the doc stays shorter than the handler.