Hi Ilya, thanks for the response. I agree, I implemented per your suggestion, submitted in a different thread.
Best regards, Reuven On 10/06/2026 19:21, Ilya Maximets wrote:
External email: Use caution opening links or attachments On 5/27/26 4:45 PM, Reuven Plevinsky via dev wrote:The kernel datapath cannot hold ports whose names are IFNAMSIZ bytes or longer, so dpif_netlink_port_query_by_name() can never find them. During restart the ofproto construct path calls dpif_port_exists() for every configured interface. For ports with long names (for example patch ports) this reached the kernel, which returned an error that was logged as a spurious "failed to query port <long_port_name>: Invalid argument" warning. Return ENODEV early when the name is too long, avoiding the round-trip and the misleading log message. Fixes: c19e653509de ("datapath: Change userspace vport interface to use Netlink attributes.") Signed-off-by: Reuven Plevinsky <[email protected]> --- lib/dpif-netlink.c | 4 ++++ tests/system-interface.at | 24 ++++++++++++++++++++++++ 2 files changed, 28 insertions(+) diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index 2bf7e7cf27c1..5aa99dbe0efa 100644 --- a/lib/dpif-netlink.c +++ b/lib/dpif-netlink.c @@ -1130,6 +1130,10 @@ dpif_netlink_port_query_by_name(const struct dpif *dpif_, const char *devname, { struct dpif_netlink *dpif = dpif_netlink_cast(dpif_); + if (strlen(devname) >= IFNAMSIZ) { + return ENODEV; + } +Hi, Reuven. Thanks for the update. The test looks fine now. I was thinking more abut the issue and the problem is not actually in dpif-netlink. The problem is that patch port is being looked up in dpif-netlink in the first place. dpif-netlink doesn't actually have a limit for the interface name. The limit is in the netdev-linux and the Linux kernel. dpif-netlink is not tied to Linux kernel or a particular implementation of the openvswitch kernel module. For example, until very recently we had Windows datapath handled though the same dpif-netlink interface, and Windows driver had 255 as a limit. Also, if the name is shorter but happens to collide with a name of some existing interface in the kernel, the ofproto layer may be confused. So, we need a fix there. One option might be to store the port type in the iface_hints and skip dpif query for ports that ofproto-dpif implements on its own, i.e. patch ports. With tunnel ports it's a bit more complicated as dpif may implement them directly or through the shared tunnel device, so we'd need to keep querying those for now. Best regards, Ilya Maximets.
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
