Currently, if a user wants to run pmtu.sh and cover all the provided test cases, they need to install the Open vSwitch userspace utilities. This dependency is difficult for users as well as CI environments, because the userspace build and setup may require lots of support and devel packages to be installed, system setup to be correct, and things like permissions and selinux policies to be properly configured.
The kernel selftest suite includes an ovs-dpctl.py utility which can interact with the openvswitch module directly. This lets developers and CI environments run without needing too many extra dependencies - just the pyroute2 python package.
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Aaron Conole (7): selftests: openvswitch: Support explicit tunnel port creation. selftests: openvswitch: Refactor actions parsing. selftests: openvswitch: Add set() and set_masked() support. selftests: openvswitch: Add support for tunnel() key. selftests: openvswitch: Support implicit ipv6 arguments. selftests: net: Use the provided dpctl rather than the vswitchd for tests. selftests: net: add config for openvswitch
tools/testing/selftests/net/config | 5 + .../selftests/net/openvswitch/ovs-dpctl.py | 366 +++++++++++++++--- tools/testing/selftests/net/pmtu.sh | 145 +++++-- 3 files changed, 450 insertions(+), 66 deletions(-)
The OVS module can operate in conjunction with various types of tunnel ports. These are created as either explicit tunnel vport types, OR by creating a tunnel interface which acts as an anchor for the lightweight tunnel support.
This patch adds the ability to add tunnel ports to an OVS datapath for testing various scenarios with tunnel ports. With this addition, the vswitch "plumbing" will at least be able to push packets around using the tunnel vports. Future patches will add support for setting required tunnel metadata for lwts in the datapath. The end goal will be to push packets via these tunnels, and will be used in an upcoming commit for testing the path MTU.
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org Signed-off-by: Aaron Conole aconole@redhat.com --- .../selftests/net/openvswitch/ovs-dpctl.py | 81 +++++++++++++++++-- 1 file changed, 75 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py index 1dd057afd3fb..8f92215303a3 100644 --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -10,6 +10,7 @@ import ipaddress import logging import multiprocessing import re +import socket import struct import sys import time @@ -29,6 +30,7 @@ try: from pyroute2.netlink.exceptions import NetlinkError from pyroute2.netlink.generic import GenericNetlinkSocket import pyroute2 + import pyroute2.iproute
except ModuleNotFoundError: print("Need to install the python pyroute2 package >= 0.6.") @@ -1617,7 +1619,7 @@ class OvsVport(GenericNetlinkSocket): ("OVS_VPORT_ATTR_PORT_NO", "uint32"), ("OVS_VPORT_ATTR_TYPE", "uint32"), ("OVS_VPORT_ATTR_NAME", "asciiz"), - ("OVS_VPORT_ATTR_OPTIONS", "none"), + ("OVS_VPORT_ATTR_OPTIONS", "vportopts"), ("OVS_VPORT_ATTR_UPCALL_PID", "array(uint32)"), ("OVS_VPORT_ATTR_STATS", "vportstats"), ("OVS_VPORT_ATTR_PAD", "none"), @@ -1625,6 +1627,13 @@ class OvsVport(GenericNetlinkSocket): ("OVS_VPORT_ATTR_NETNSID", "uint32"), )
+ class vportopts(nla): + nla_map = ( + ("OVS_TUNNEL_ATTR_UNSPEC", "none"), + ("OVS_TUNNEL_ATTR_DST_PORT", "uint16"), + ("OVS_TUNNEL_ATTR_EXTENSION", "none"), + ) + class vportstats(nla): fields = ( ("rx_packets", "=Q"), @@ -1693,7 +1702,7 @@ class OvsVport(GenericNetlinkSocket): raise ne return reply
- def attach(self, dpindex, vport_ifname, ptype): + def attach(self, dpindex, vport_ifname, ptype, dport, lwt): msg = OvsVport.ovs_vport_msg()
msg["cmd"] = OVS_VPORT_CMD_NEW @@ -1702,12 +1711,43 @@ class OvsVport(GenericNetlinkSocket): msg["dpifindex"] = dpindex port_type = OvsVport.str_to_type(ptype)
- msg["attrs"].append(["OVS_VPORT_ATTR_TYPE", port_type]) msg["attrs"].append(["OVS_VPORT_ATTR_NAME", vport_ifname]) msg["attrs"].append( ["OVS_VPORT_ATTR_UPCALL_PID", [self.upcall_packet.epid]] )
+ TUNNEL_DEFAULTS = [("geneve", 6081), + ("vxlan", 4789)] + + for tnl in TUNNEL_DEFAULTS: + if ptype == tnl[0]: + if not dport: + dport = tnl[1] + + if not lwt: + vportopt = OvsVport.ovs_vport_msg.vportopts() + vportopt["attrs"].append( + ["OVS_TUNNEL_ATTR_DST_PORT", socket.htons(dport)] + ) + msg["attrs"].append( + ["OVS_VPORT_ATTR_OPTIONS", vportopt] + ) + else: + port_type = OvsVport.OVS_VPORT_TYPE_NETDEV + ipr = pyroute2.iproute.IPRoute() + + if tnl[0] == "geneve": + ipr.link("add", ifname=vport_ifname, kind=tnl[0], + geneve_port=dport, + geneve_collect_metadata=True, + geneve_udp_zero_csum6_rx=1) + elif tnl[0] == "vxlan": + ipr.link("add", ifname=vport_ifname, kind=tnl[0], + vxlan_learning=0, vxlan_collect_metadata=1, + vxlan_udp_zero_csum6_rx=1, vxlan_port=dport) + break + msg["attrs"].append(["OVS_VPORT_ATTR_TYPE", port_type]) + try: reply = self.nlm_request( msg, msg_type=self.prid, msg_flags=NLM_F_REQUEST | NLM_F_ACK @@ -2053,12 +2093,19 @@ def print_ovsdp_full(dp_lookup_rep, ifindex, ndb=NDB(), vpl=OvsVport()): for iface in ndb.interfaces: rep = vpl.info(iface.ifname, ifindex) if rep is not None: + opts = "" + vpo = rep.get_attr("OVS_VPORT_ATTR_OPTIONS") + if vpo: + dpo = vpo.get_attr("OVS_TUNNEL_ATTR_DST_PORT") + if dpo: + opts += " tnl-dport:%s" % socket.ntohs(dpo) print( - " port %d: %s (%s)" + " port %d: %s (%s%s)" % ( rep.get_attr("OVS_VPORT_ATTR_PORT_NO"), rep.get_attr("OVS_VPORT_ATTR_NAME"), OvsVport.type_to_str(rep.get_attr("OVS_VPORT_ATTR_TYPE")), + opts, ) )
@@ -2120,12 +2167,30 @@ def main(argv): "--ptype", type=str, default="netdev", - choices=["netdev", "internal"], + choices=["netdev", "internal", "geneve", "vxlan"], help="Interface type (default netdev)", ) + addifcmd.add_argument( + "-p", + "--dport", + type=int, + default=0, + help="Destination port (0 for default)" + ) + addifcmd.add_argument( + "-l", + "--lwt", + type=bool, + default=True, + help="Use LWT infrastructure instead of vport (default true)." + ) delifcmd = subparsers.add_parser("del-if") delifcmd.add_argument("dpname", help="Datapath Name") delifcmd.add_argument("delif", help="Interface name for adding") + delifcmd.add_argument("-d", + "--dellink", + type=bool, default=False, + help="Delete the link as well.")
dumpflcmd = subparsers.add_parser("dump-flows") dumpflcmd.add_argument("dumpdp", help="Datapath Name") @@ -2186,7 +2251,8 @@ def main(argv): print("DP '%s' not found." % args.dpname) return 1 dpindex = rep["dpifindex"] - rep = ovsvp.attach(rep["dpifindex"], args.addif, args.ptype) + rep = ovsvp.attach(rep["dpifindex"], args.addif, args.ptype, + args.dport, args.lwt) msg = "vport '%s'" % args.addif if rep and rep["header"]["error"] is None: msg += " added." @@ -2207,6 +2273,9 @@ def main(argv): msg += " removed." else: msg += " failed to remove." + if args.dellink: + ipr = pyroute2.iproute.IPRoute() + ipr.link("del", index=ipr.link_lookup(ifname=args.delif)[0]) elif hasattr(args, "dumpdp"): rep = ovsdp.info(args.dumpdp, 0) if rep is None:
Until recently, the ovs-dpctl utility was used with a limited actions set and didn't need to have support for multiple similar actions. However, when adding support for tunnels, it will be important to support multiple set() actions in a single flow. When printing these actions, the existing code will be unable to print all of the sets - it will only print the first.
Refactor this code to be easier to read and support multiple actions of the same type in an action list.
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org Signed-off-by: Aaron Conole aconole@redhat.com --- .../selftests/net/openvswitch/ovs-dpctl.py | 45 ++++++++++--------- 1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py index 8f92215303a3..4db20b38b481 100644 --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -439,32 +439,30 @@ class ovsactions(nla): def dpstr(self, more=False): print_str = ""
- for field in self.nla_map: + for field in self["attrs"]: if field[1] == "none" or self.get_attr(field[0]) is None: continue if print_str != "": print_str += ","
- if field[1] == "uint32": - if field[0] == "OVS_ACTION_ATTR_OUTPUT": - print_str += "%d" % int(self.get_attr(field[0])) - elif field[0] == "OVS_ACTION_ATTR_RECIRC": - print_str += "recirc(0x%x)" % int(self.get_attr(field[0])) - elif field[0] == "OVS_ACTION_ATTR_TRUNC": - print_str += "trunc(%d)" % int(self.get_attr(field[0])) - elif field[0] == "OVS_ACTION_ATTR_DROP": - print_str += "drop(%d)" % int(self.get_attr(field[0])) - elif field[1] == "flag": - if field[0] == "OVS_ACTION_ATTR_CT_CLEAR": - print_str += "ct_clear" - elif field[0] == "OVS_ACTION_ATTR_POP_VLAN": - print_str += "pop_vlan" - elif field[0] == "OVS_ACTION_ATTR_POP_ETH": - print_str += "pop_eth" - elif field[0] == "OVS_ACTION_ATTR_POP_NSH": - print_str += "pop_nsh" - elif field[0] == "OVS_ACTION_ATTR_POP_MPLS": - print_str += "pop_mpls" + if field[0] == "OVS_ACTION_ATTR_OUTPUT": + print_str += "%d" % int(self.get_attr(field[0])) + elif field[0] == "OVS_ACTION_ATTR_RECIRC": + print_str += "recirc(0x%x)" % int(self.get_attr(field[0])) + elif field[0] == "OVS_ACTION_ATTR_TRUNC": + print_str += "trunc(%d)" % int(self.get_attr(field[0])) + elif field[0] == "OVS_ACTION_ATTR_DROP": + print_str += "drop(%d)" % int(self.get_attr(field[0])) + elif field[0] == "OVS_ACTION_ATTR_CT_CLEAR": + print_str += "ct_clear" + elif field[0] == "OVS_ACTION_ATTR_POP_VLAN": + print_str += "pop_vlan" + elif field[0] == "OVS_ACTION_ATTR_POP_ETH": + print_str += "pop_eth" + elif field[0] == "OVS_ACTION_ATTR_POP_NSH": + print_str += "pop_nsh" + elif field[0] == "OVS_ACTION_ATTR_POP_MPLS": + print_str += "pop_mpls" else: datum = self.get_attr(field[0]) if field[0] == "OVS_ACTION_ATTR_CLONE": @@ -472,7 +470,10 @@ class ovsactions(nla): print_str += datum.dpstr(more) print_str += ")" else: - print_str += datum.dpstr(more) + try: + print_str += datum.dpstr(more) + except: + print_str += "{ATTR: %s not decoded}" % field[0]
return print_str
These will be used in upcoming commits to set specific attributes for interacting with tunnels. Since set() will use the key parsing routine, we also make sure to prepend it with an open paren, for the action parsing to properly understand it.
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org Signed-off-by: Aaron Conole aconole@redhat.com --- .../selftests/net/openvswitch/ovs-dpctl.py | 37 +++++++++++++++++-- 1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py index 4db20b38b481..4c235ff07aeb 100644 --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -284,7 +284,7 @@ class ovsactions(nla): ("OVS_ACTION_ATTR_UNSPEC", "none"), ("OVS_ACTION_ATTR_OUTPUT", "uint32"), ("OVS_ACTION_ATTR_USERSPACE", "userspace"), - ("OVS_ACTION_ATTR_SET", "none"), + ("OVS_ACTION_ATTR_SET", "ovskey"), ("OVS_ACTION_ATTR_PUSH_VLAN", "none"), ("OVS_ACTION_ATTR_POP_VLAN", "flag"), ("OVS_ACTION_ATTR_SAMPLE", "none"), @@ -292,7 +292,7 @@ class ovsactions(nla): ("OVS_ACTION_ATTR_HASH", "none"), ("OVS_ACTION_ATTR_PUSH_MPLS", "none"), ("OVS_ACTION_ATTR_POP_MPLS", "flag"), - ("OVS_ACTION_ATTR_SET_MASKED", "none"), + ("OVS_ACTION_ATTR_SET_MASKED", "ovskey"), ("OVS_ACTION_ATTR_CT", "ctact"), ("OVS_ACTION_ATTR_TRUNC", "uint32"), ("OVS_ACTION_ATTR_PUSH_ETH", "none"), @@ -469,6 +469,18 @@ class ovsactions(nla): print_str += "clone(" print_str += datum.dpstr(more) print_str += ")" + elif field[0] == "OVS_ACTION_ATTR_SET" or \ + field[0] == "OVS_ACTION_ATTR_SET_MASKED": + print_str += "set" + field = datum + mask = None + if field[0] == "OVS_ACTION_ATTR_SET_MASKED": + print_str += "_masked" + field = datum[0] + mask = datum[1] + print_str += "(" + print_str += field.dpstr(mask, more) + print_str += ")" else: try: print_str += datum.dpstr(more) @@ -547,6 +559,25 @@ class ovsactions(nla): self["attrs"].append(("OVS_ACTION_ATTR_CLONE", subacts)) actstr = actstr[parsedLen:] parsed = True + elif parse_starts_block(actstr, "set(", False): + parencount += 1 + k = ovskey() + actstr = actstr[len("set("):] + actstr = k.parse(actstr, None) + self["attrs"].append(("OVS_ACTION_ATTR_SET", k)) + if not actstr.startswith(")"): + actstr = ")" + actstr + parsed = True + elif parse_starts_block(actstr, "set_masked(", False): + parencount += 1 + k = ovskey() + m = ovskey() + actstr = actstr[len("set_masked("):] + actstr = k.parse(actstr, m) + self["attrs"].append(("OVS_ACTION_ATTR_SET_MASKED", [k, m])) + if not actstr.startswith(")"): + actstr = ")" + actstr + parsed = True elif parse_starts_block(actstr, "ct(", False): parencount += 1 actstr = actstr[len("ct(") :] @@ -1312,7 +1343,7 @@ class ovskey(nla): mask["attrs"].append([field[0], m]) self["attrs"].append([field[0], k])
- flowstr = flowstr[strspn(flowstr, "),") :] + flowstr = flowstr[strspn(flowstr, "), ") :]
return flowstr
This will be used when setting details about the tunnel to use as transport. There is a difference between the ODP format between tunnel(): the 'key' flag is not actually a flag field, so we don't support it in the same way that the vswitchd userspace supports displaying it.
Signed-off-by: Aaron Conole aconole@redhat.com --- .../selftests/net/openvswitch/ovs-dpctl.py | 167 +++++++++++++++++- 1 file changed, 166 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py index 4c235ff07aeb..2f16df2fb16b 100644 --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -709,7 +709,7 @@ class ovskey(nla): ("OVS_KEY_ATTR_ARP", "ovs_key_arp"), ("OVS_KEY_ATTR_ND", "ovs_key_nd"), ("OVS_KEY_ATTR_SKB_MARK", "uint32"), - ("OVS_KEY_ATTR_TUNNEL", "none"), + ("OVS_KEY_ATTR_TUNNEL", "ovs_key_tunnel"), ("OVS_KEY_ATTR_SCTP", "ovs_key_sctp"), ("OVS_KEY_ATTR_TCP_FLAGS", "be16"), ("OVS_KEY_ATTR_DP_HASH", "uint32"), @@ -1269,6 +1269,163 @@ class ovskey(nla): init=init, )
+ class ovs_key_tunnel(nla): + nla_flags = NLA_F_NESTED + + nla_map = ( + ("OVS_TUNNEL_KEY_ATTR_ID", "be64"), + ("OVS_TUNNEL_KEY_ATTR_IPV4_SRC", "ipaddr"), + ("OVS_TUNNEL_KEY_ATTR_IPV4_DST", "ipaddr"), + ("OVS_TUNNEL_KEY_ATTR_TOS", "uint8"), + ("OVS_TUNNEL_KEY_ATTR_TTL", "uint8"), + ("OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT", "flag"), + ("OVS_TUNNEL_KEY_ATTR_CSUM", "flag"), + ("OVS_TUNNEL_KEY_ATTR_OAM", "flag"), + ("OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS", "array(uint32)"), + ("OVS_TUNNEL_KEY_ATTR_TP_SRC", "be16"), + ("OVS_TUNNEL_KEY_ATTR_TP_DST", "be16"), + ("OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS", "none"), + ("OVS_TUNNEL_KEY_ATTR_IPV6_SRC", "ipaddr"), + ("OVS_TUNNEL_KEY_ATTR_IPV6_DST", "ipaddr"), + ("OVS_TUNNEL_KEY_ATTR_PAD", "none"), + ("OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS", "none"), + ("OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE", "flag"), + ) + + def parse(self, flowstr, mask=None): + if not flowstr.startswith("tunnel("): + return None, None + + k = ovskey.ovs_key_tunnel() + if mask is not None: + mask = ovskey.ovs_key_tunnel() + + flowstr = flowstr[len("tunnel("):] + + v6_address = None + + fields = [ + ("tun_id=", r"(\d+)", int, "OVS_TUNNEL_KEY_ATTR_ID", + 0xffffffffffffffff, None, None), + + ("src=", r"([0-9a-fA-F.]+)", str, + "OVS_TUNNEL_KEY_ATTR_IPV4_SRC", "255.255.255.255", "0.0.0.0", + False), + ("dst=", r"([0-9a-fA-F.]+)", str, + "OVS_TUNNEL_KEY_ATTR_IPV4_DST", "255.255.255.255", "0.0.0.0", + False), + + ("ipv6_src=", r"([0-9a-fA-F:]+)", str, + "OVS_TUNNEL_KEY_ATTR_IPV6_SRC", + "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "::", True), + ("ipv6_dst=", r"([0-9a-fA-F:]+)", str, + "OVS_TUNNEL_KEY_ATTR_IPV6_DST", + "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff", "::", True), + + ("tos=", r"(\d+)", int, "OVS_TUNNEL_KEY_ATTR_TOS", 255, 0, + None), + ("ttl=", r"(\d+)", int, "OVS_TUNNEL_KEY_ATTR_TTL", 255, 0, + None), + + ("tp_src=", r"(\d+)", int, "OVS_TUNNEL_KEY_ATTR_TP_SRC", + 65535, 0, None), + ("tp_dst=", r"(\d+)", int, "OVS_TUNNEL_KEY_ATTR_TP_DST", + 65535, 0, None), + ] + + forced_include = ["OVS_TUNNEL_KEY_ATTR_TTL"] + + for prefix, regex, typ, attr_name, mask_val, default_val, v46_flag in fields: + flowstr, value = parse_extract_field(flowstr, prefix, regex, typ, False) + if not attr_name: + raise Exception("Bad list value in tunnel fields") + + if value is None and attr_name in forced_include: + value = default_val + mask_val = default_val + + if value is not None: + if v46_flag is not None: + if v6_address is None: + v6_address = v46_flag + if v46_flag != v6_address: + raise ValueError("Cannot mix v6 and v4 addresses") + k["attrs"].append([attr_name, value]) + if mask is not None: + mask["attrs"].append([attr_name, mask_val]) + else: + if v46_flag is not None: + if v6_address is None or v46_flag != v6_address: + continue + if mask is not None: + mask["attrs"].append([attr_name, default_val]) + + if k["attrs"][0][0] != "OVS_TUNNEL_KEY_ATTR_ID": + raise ValueError("Needs a tunid set") + + if flowstr.startswith("flags("): + flowstr = flowstr[len("flags("):] + flagspos = flowstr.find(")") + flags = flowstr[:flagspos] + flowstr = flowstr[flagspos + 1:] + + flag_attrs = { + "df": "OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT", + "csum": "OVS_TUNNEL_KEY_ATTR_CSUM", + "oam": "OVS_TUNNEL_KEY_ATTR_OAM" + } + + for flag in flags.split("|"): + if flag in flag_attrs: + k["attrs"].append([flag_attrs[flag], True]) + if mask is not None: + mask["attrs"].append([flag_attrs[flag], True]) + + flowstr = flowstr[strspn(flowstr, ", ") :] + return flowstr, k, mask + + def dpstr(self, mask=None, more=False): + print_str = "tunnel(" + + flagsattrs = [] + for k in self["attrs"]: + noprint = False + if k[0] == "OVS_TUNNEL_KEY_ATTR_ID": + print_str += "tun_id=%d" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_IPV4_SRC": + print_str += "src=%s" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_IPV4_DST": + print_str += "dst=%s" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_IPV6_SRC": + print_str += "ipv6_src=%s" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_IPV6_DST": + print_str += "ipv6_dst=%s" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_TOS": + print_str += "tos=%d" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_TTL": + print_str += "ttl=%d" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_TP_SRC": + print_str += "tp_src=%d" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_TP_DST": + print_str += "tp_dst=%d" % k[1] + elif k[0] == "OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT": + noprint = True + flagsattrs.append("df") + elif k[0] == "OVS_TUNNEL_KEY_ATTR_CSUM": + noprint = True + flagsattrs.append("csum") + elif k[0] == "OVS_TUNNEL_KEY_ATTR_OAM": + noprint = True + flagsattrs.append("oam") + + if not noprint: + print_str += "," + + if len(flagsattrs): + print_str += "flags(" + "|".join(flagsattrs) + ")" + print_str += ")" + return print_str + class ovs_key_mpls(nla): fields = (("lse", ">I"),)
@@ -1277,6 +1434,7 @@ class ovskey(nla): ("OVS_KEY_ATTR_PRIORITY", "skb_priority", intparse), ("OVS_KEY_ATTR_SKB_MARK", "skb_mark", intparse), ("OVS_KEY_ATTR_RECIRC_ID", "recirc_id", intparse), + ("OVS_KEY_ATTR_TUNNEL", "tunnel", ovskey.ovs_key_tunnel), ("OVS_KEY_ATTR_DP_HASH", "dp_hash", intparse), ("OVS_KEY_ATTR_CT_STATE", "ct_state", parse_ct_state), ("OVS_KEY_ATTR_CT_ZONE", "ct_zone", intparse), @@ -1379,6 +1537,13 @@ class ovskey(nla): lambda x: False, True, ), + ( + "OVS_KEY_ATTR_TUNNEL", + "tunnel", + None, + False, + False, + ), ( "OVS_KEY_ATTR_CT_STATE", "ct_state",
The current iteration of IPv6 support requires explicit fields to be set in addition to not properly support the actual IPv6 addresses properly. With this change, make it so that the ipv6() bare option is usable to create wildcarded flows to match broad swaths of ipv6 traffic.
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org Signed-off-by: Aaron Conole aconole@redhat.com --- v2: Drop the change in the v6 key class that removed the str() conversion
.../selftests/net/openvswitch/ovs-dpctl.py | 36 ++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py index 2f16df2fb16b..0ea7286a491e 100644 --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -200,6 +200,18 @@ def convert_ipv4(data):
return int(ipaddress.IPv4Address(ip)), int(ipaddress.IPv4Address(mask))
+def convert_ipv6(data): + ip, _, mask = data.partition('/') + + if not ip: + ip = mask = 0 + elif not mask: + mask = 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff' + elif mask.isdigit(): + mask = ipaddress.IPv6Network("::/" + mask).hostmask + + return ipaddress.IPv6Address(ip).packed, ipaddress.IPv6Address(mask).packed + def convert_int(size): def convert_int_sized(data): value, _, mask = data.partition('/') @@ -941,21 +953,21 @@ class ovskey(nla): "src", "src", lambda x: str(ipaddress.IPv6Address(x)), - lambda x: int.from_bytes(x, "big"), - lambda x: ipaddress.IPv6Address(x), + lambda x: ipaddress.IPv6Address(x).packed if x else 0, + convert_ipv6, ), ( "dst", "dst", lambda x: str(ipaddress.IPv6Address(x)), - lambda x: int.from_bytes(x, "big"), - lambda x: ipaddress.IPv6Address(x), + lambda x: ipaddress.IPv6Address(x).packed if x else 0, + convert_ipv6, ), - ("label", "label", "%d", int), - ("proto", "proto", "%d", int), - ("tclass", "tclass", "%d", int), - ("hlimit", "hlimit", "%d", int), - ("frag", "frag", "%d", int), + ("label", "label", "%d", lambda x: int(x) if x else 0), + ("proto", "proto", "%d", lambda x: int(x) if x else 0), + ("tclass", "tclass", "%d", lambda x: int(x) if x else 0), + ("hlimit", "hlimit", "%d", lambda x: int(x) if x else 0), + ("frag", "frag", "%d", lambda x: int(x) if x else 0), )
def __init__( @@ -1153,7 +1165,7 @@ class ovskey(nla): "target", "target", lambda x: str(ipaddress.IPv6Address(x)), - lambda x: int.from_bytes(x, "big"), + convert_ipv6, ), ("sll", "sll", macstr, lambda x: int.from_bytes(x, "big")), ("tll", "tll", macstr, lambda x: int.from_bytes(x, "big")), @@ -1238,13 +1250,13 @@ class ovskey(nla): "src", "src", lambda x: str(ipaddress.IPv6Address(x)), - lambda x: int.from_bytes(x, "big", convertmac), + convert_ipv6, ), ( "dst", "dst", lambda x: str(ipaddress.IPv6Address(x)), - lambda x: int.from_bytes(x, "big"), + convert_ipv6, ), ("tp_src", "tp_src", "%d", int), ("tp_dst", "tp_dst", "%d", int),
The current pmtu test infrastucture requires an installed copy of the ovs-vswitchd userspace. This means that any automated or constrained environments may not have the requisite tools to run the tests. However, the pmtu tests don't require any special classifier processing. Indeed they are only using the vswitchd in the most basic mode - as a NORMAL switch.
However, the ovs-dpctl kernel utility can now program all the needed basic flows to allow traffic to traverse the tunnels and provide support for at least testing some basic pmtu scenarios. More complicated flow pipelines can be added to the internal ovs test infrastructure, but that is work for the future. For now, enable the most common cases - wide mega flows with no other prerequisites.
Enhance the pmtu testing to try testing using the internal utility, first. As a fallback, if the internal utility isn't running, then try with the ovs-vswitchd userspace tools.
Reviewed-by: Stefano Brivio sbrivio@redhat.com Signed-off-by: Aaron Conole aconole@redhat.com --- v2: Fix a nit in the whitespace
tools/testing/selftests/net/pmtu.sh | 145 +++++++++++++++++++++++----- 1 file changed, 123 insertions(+), 22 deletions(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh index cfc84958025a..5175c0c83a23 100755 --- a/tools/testing/selftests/net/pmtu.sh +++ b/tools/testing/selftests/net/pmtu.sh @@ -842,25 +842,97 @@ setup_bridge() { run_cmd ${ns_a} ip link set veth_A-C master br0 }
+setup_ovs_via_internal_utility() { + type="${1}" + a_addr="${2}" + b_addr="${3}" + dport="${4}" + + run_cmd python3 ./openvswitch/ovs-dpctl.py add-if ovs_br0 ${type}_a -t ${type} || return 1 + + ports=$(python3 ./openvswitch/ovs-dpctl.py show) + br0_port=$(echo "$ports" | grep -E "\sovs_br0" | sed -e 's@port @@' | cut -d: -f1 | xargs) + type_a_port=$(echo "$ports" | grep ${type}_a | sed -e 's@port @@' | cut -d: -f1 | xargs) + veth_a_port=$(echo "$ports" | grep veth_A | sed -e 's@port @@' | cut -d: -f1 | xargs) + + v4_a_tun="${prefix4}.${a_r1}.1" + v4_b_tun="${prefix4}.${b_r1}.1" + + v6_a_tun="${prefix6}:${a_r1}::1" + v6_b_tun="${prefix6}:${b_r1}::1" + + if [ "${v4_a_tun}" = "${a_addr}" ]; then + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x0800),ipv4()" \ + "set(tunnel(tun_id=1,dst=${v4_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x86dd),ipv6()" \ + "set(tunnel(tun_id=1,dst=${v4_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,src=${v4_b_tun},dst=${v4_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x0800),ipv4()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,src=${v4_b_tun},dst=${v4_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x86dd),ipv6()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,src=${v4_b_tun},dst=${v4_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x0806),arp()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x0806),arp(sip=${veth4_c_addr},tip=${tunnel4_b_addr})" \ + "set(tunnel(tun_id=1,dst=${v4_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + else + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x0800),ipv4()" \ + "set(tunnel(tun_id=1,ipv6_dst=${v6_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x86dd),ipv6()" \ + "set(tunnel(tun_id=1,ipv6_dst=${v6_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,ipv6_src=${v6_b_tun},ipv6_dst=${v6_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x0800),ipv4()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,ipv6_src=${v6_b_tun},ipv6_dst=${v6_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x86dd),ipv6()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),tunnel(tun_id=1,ipv6_src=${v6_b_tun},ipv6_dst=${v6_a_tun}),in_port(${type_a_port}),eth(),eth_type(0x0806),arp()" \ + "${veth_a_port}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-flow ovs_br0 \ + "recirc_id(0),in_port(${veth_a_port}),eth(),eth_type(0x0806),arp(sip=${veth4_c_addr},tip=${tunnel4_b_addr})" \ + "set(tunnel(tun_id=1,ipv6_dst=${v6_b_tun},ttl=64,tp_dst=${dport},flags(df|csum))),${type_a_port}" + fi +} + +setup_ovs_via_vswitchd() { + type="${1}" + b_addr="${2}" + + run_cmd ovs-vsctl add-port ovs_br0 ${type}_a -- \ + set interface ${type}_a type=${type} \ + options:remote_ip=${b_addr} options:key=1 options:csum=true || return 1 +} + setup_ovs_vxlan_or_geneve() { type="${1}" a_addr="${2}" b_addr="${3}" + dport="6081"
if [ "${type}" = "vxlan" ]; then + dport="4789" opts="${opts} ttl 64 dstport 4789" opts_b="local ${b_addr}" fi
- run_cmd ovs-vsctl add-port ovs_br0 ${type}_a -- \ - set interface ${type}_a type=${type} \ - options:remote_ip=${b_addr} options:key=1 options:csum=true || return 1 + setup_ovs_via_internal_utility "${type}" "${a_addr}" "${b_addr}" \ + "${dport}" || \ + setup_ovs_via_vswitchd "${type}" "${b_addr}" || return 1
run_cmd ${ns_b} ip link add ${type}_b type ${type} id 1 ${opts_b} remote ${a_addr} ${opts} || return 1
run_cmd ${ns_b} ip addr add ${tunnel4_b_addr}/${tunnel4_mask} dev ${type}_b run_cmd ${ns_b} ip addr add ${tunnel6_b_addr}/${tunnel6_mask} dev ${type}_b
+ run_cmd ip link set ${type}_a up run_cmd ${ns_b} ip link set ${type}_b up }
@@ -880,8 +952,24 @@ setup_ovs_vxlan6() { setup_ovs_vxlan_or_geneve vxlan ${prefix6}:${a_r1}::1 ${prefix6}:${b_r1}::1 }
+setup_ovs_br_internal() { + run_cmd python3 ./openvswitch/ovs-dpctl.py add-dp ovs_br0 || \ + return 1 +} + +setup_ovs_br_vswitchd() { + run_cmd ovs-vsctl add-br ovs_br0 || return 1 +} + +setup_ovs_add_if() { + ifname="${1}" + run_cmd python3 ./openvswitch/ovs-dpctl.py add-if ovs_br0 \ + "${ifname}" || \ + run_cmd ovs-vsctl add-port ovs_br0 "${ifname}" +} + setup_ovs_bridge() { - run_cmd ovs-vsctl add-br ovs_br0 || return $ksft_skip + setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip run_cmd ip link set ovs_br0 up
run_cmd ${ns_c} ip link add veth_C-A type veth peer name veth_A-C @@ -891,7 +979,7 @@ setup_ovs_bridge() { run_cmd ${ns_c} ip link set veth_C-A up run_cmd ${ns_c} ip addr add ${veth4_c_addr}/${veth4_mask} dev veth_C-A run_cmd ${ns_c} ip addr add ${veth6_c_addr}/${veth6_mask} dev veth_C-A - run_cmd ovs-vsctl add-port ovs_br0 veth_A-C + setup_ovs_add_if veth_A-C
# Move veth_A-R1 to init run_cmd ${ns_a} ip link set veth_A-R1 netns 1 @@ -922,6 +1010,18 @@ trace() { sleep 1 }
+cleanup_del_ovs_internal() { + # squelch the output of the del-if commands since it can be wordy + python3 ./openvswitch/ovs-dpctl.py del-if ovs_br0 -d true vxlan_a >/dev/null 2>&1 + python3 ./openvswitch/ovs-dpctl.py del-if ovs_br0 -d true geneve_a >/dev/null 2>&1 + python3 ./openvswitch/ovs-dpctl.py del-dp ovs_br0 >/dev/null 2>&1 +} + +cleanup_del_ovs_vswitchd() { + ovs-vsctl --if-exists del-port vxlan_a 2>/dev/null + ovs-vsctl --if-exists del-br ovs_br0 2>/dev/null +} + cleanup() { for pid in ${tcpdump_pids}; do kill ${pid} @@ -940,10 +1040,10 @@ cleanup() {
cleanup_all_ns
- ip link del veth_A-C 2>/dev/null - ip link del veth_A-R1 2>/dev/null - ovs-vsctl --if-exists del-port vxlan_a 2>/dev/null - ovs-vsctl --if-exists del-br ovs_br0 2>/dev/null + ip link del veth_A-C 2>/dev/null + ip link del veth_A-R1 2>/dev/null + cleanup_del_ovs_internal + cleanup_del_ovs_vswitchd rm -f "$tmpoutfile" }
@@ -1397,6 +1497,12 @@ test_pmtu_ipvX_over_ovs_vxlanY_or_geneveY_exception() { outer_family=${3} ll_mtu=4000
+ if [ "${type}" = "vxlan" ]; then + tun_a="vxlan_sys_4789" + elif [ "${type}" = "geneve" ]; then + tun_a="genev_sys_6081" + fi + if [ ${outer_family} -eq 4 ]; then setup namespaces routing ovs_bridge ovs_${type}4 || return $ksft_skip # IPv4 header UDP header VXLAN/GENEVE header Ethernet header @@ -1407,17 +1513,11 @@ test_pmtu_ipvX_over_ovs_vxlanY_or_geneveY_exception() { exp_mtu=$((${ll_mtu} - 40 - 8 - 8 - 14)) fi
- if [ "${type}" = "vxlan" ]; then - tun_a="vxlan_sys_4789" - elif [ "${type}" = "geneve" ]; then - tun_a="genev_sys_6081" - fi - - trace "" "${tun_a}" "${ns_b}" ${type}_b \ - "" veth_A-R1 "${ns_r1}" veth_R1-A \ - "${ns_b}" veth_B-R1 "${ns_r1}" veth_R1-B \ - "" ovs_br0 "" veth-A-C \ - "${ns_c}" veth_C-A + trace "" ${type}_a "${ns_b}" ${type}_b \ + "" veth_A-R1 "${ns_r1}" veth_R1-A \ + "${ns_b}" veth_B-R1 "${ns_r1}" veth_R1-B \ + "" ovs_br0 "" veth-A_C \ + "${ns_c}" veth_C-A "" "${tun_a}"
if [ ${family} -eq 4 ]; then ping=ping @@ -1436,8 +1536,9 @@ test_pmtu_ipvX_over_ovs_vxlanY_or_geneveY_exception() { mtu "${ns_b}" veth_B-R1 ${ll_mtu} mtu "${ns_r1}" veth_R1-B ${ll_mtu}
- mtu "" ${tun_a} $((${ll_mtu} + 1000)) - mtu "${ns_b}" ${type}_b $((${ll_mtu} + 1000)) + mtu "" ${tun_a} $((${ll_mtu} + 1000)) 2>/dev/null || \ + mtu "" ${type}_a $((${ll_mtu} + 1000)) 2>/dev/null + mtu "${ns_b}" ${type}_b $((${ll_mtu} + 1000))
run_cmd ${ns_c} ${ping} -q -M want -i 0.1 -c 20 -s $((${ll_mtu} + 500)) ${dst} || return 1
The pmtu testing will require that the OVS module is installed, so do that.
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org Signed-off-by: Aaron Conole aconole@redhat.com --- tools/testing/selftests/net/config | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config index 04de7a6ba6f3..d85fb2d1f132 100644 --- a/tools/testing/selftests/net/config +++ b/tools/testing/selftests/net/config @@ -101,3 +101,8 @@ CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_CRYPTO_ARIA=y CONFIG_XFRM_INTERFACE=m CONFIG_XFRM_USER=m +CONFIG_OPENVSWITCH=m +CONFIG_OPENVSWITCH_GRE=m +CONFIG_OPENVSWITCH_VXLAN=m +CONFIG_OPENVSWITCH_GENEVE=m +CONFIG_NF_CONNTRACK_OVS=y
On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Thanks for the work!
Looks like the series no longer applies because of other changes to the kernel config. Before it stopped applying we got some runs, here's what I see:
https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
# Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0"
Any idea why? Looks like kernel config did include OVS, perhaps we need explicit modprobe now? I don't see any more details in the logs.
Jakub Kicinski kuba@kernel.org writes:
On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Thanks for the work!
Looks like the series no longer applies because of other changes to the kernel config. Before it stopped applying we got some runs, here's what I see:
https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
# Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0"
Any idea why? Looks like kernel config did include OVS, perhaps we need explicit modprobe now? I don't see any more details in the logs.
Strange. I expected that the module should have automatically been loaded when attempting to communicate with the OVS genetlink family type. At least, that is how it had been working previously.
I'll spend some time looking into it and resubmit a rebased version. Thanks, Jakub!
Aaron Conole aconole@redhat.com writes:
Jakub Kicinski kuba@kernel.org writes:
On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Thanks for the work!
Looks like the series no longer applies because of other changes to the kernel config. Before it stopped applying we got some runs, here's what I see:
https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
# Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0"
Any idea why? Looks like kernel config did include OVS, perhaps we need explicit modprobe now? I don't see any more details in the logs.
Strange. I expected that the module should have automatically been loaded when attempting to communicate with the OVS genetlink family type. At least, that is how it had been working previously.
I'll spend some time looking into it and resubmit a rebased version. Thanks, Jakub!
If the ovs module isn't available, then I see:
# ovs_bridge not supported # TEST: IPv4, OVS vxlan4: PMTU exceptions [SKIP]
But if it is available, I haven't been able to reproduce such ovs_br0 setup failure - things work.
My branch is rebased on 568ebdaba6370c03360860f1524f646ddd5ca523
Additionally, the "Cannot find device ..." text comes from an iproute2 utility output. The only place we actually interact with that is via the call at pmtu.sh:973:
run_cmd ip link set ovs_br0 up
Maybe it is possible that the link isn't up (could some port memory allocation or message be delaying it?) yet in the virtual environment. To confirm, is it possible to run in the constrained environment, but put a 5s sleep or something? I will add the following either as a separate patch (ie 7/8), or I can fold it into 6/7 (and drop Stefano's ACK waiting for another review):
wait_for_if() { if ip link show "$2" >/dev/null 2>&1; then return 0; fi
for d in `seq 1 30`; do sleep 1 if ip link show "$2" >/dev/null 2>&1; then return 0; fi done return 1 }
.... setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip + wait_for_if "ovs_br0" run_cmd ip link set ovs_br0 up ....
Does it make sense or does it seem like I am way off base?
On Mon, 24 Jun 2024 12:53:45 -0400 Aaron Conole wrote:
Additionally, the "Cannot find device ..." text comes from an iproute2 utility output. The only place we actually interact with that is via the call at pmtu.sh:973:
run_cmd ip link set ovs_br0 up
Maybe it is possible that the link isn't up (could some port memory allocation or message be delaying it?) yet in the virtual environment.
Depends on how the creation is implemented, normally device creation over netlink is synchronous. Just to be sure have you tried to repro with vng:
https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-sty...
? It could be the base OS difference, too, but that's harder to confirm.
To confirm, is it possible to run in the constrained environment, but put a 5s sleep or something? I will add the following either as a separate patch (ie 7/8), or I can fold it into 6/7 (and drop Stefano's ACK waiting for another review):
wait_for_if() { if ip link show "$2" >/dev/null 2>&1; then return 0; fi
for d in `seq 1 30`; do sleep 1 if ip link show "$2" >/dev/null 2>&1; then return 0; fi done return 1 }
.... setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip
- wait_for_if "ovs_br0" run_cmd ip link set ovs_br0 up
....
Does it make sense or does it seem like I am way off base?
sleep 1 is a bit high (sleep does accept fractional numbers!) but otherwise worth trying, if you can't repro locally.
On Mon, 24 Jun 2024 15:30:23 -0700 Jakub Kicinski kuba@kernel.org wrote:
On Mon, 24 Jun 2024 12:53:45 -0400 Aaron Conole wrote:
Additionally, the "Cannot find device ..." text comes from an iproute2 utility output. The only place we actually interact with that is via the call at pmtu.sh:973:
run_cmd ip link set ovs_br0 up
Maybe it is possible that the link isn't up (could some port memory allocation or message be delaying it?) yet in the virtual environment.
Depends on how the creation is implemented, normally device creation over netlink is synchronous.
It also looks like pyroute2 would keep everything synchronous (unless you call NetlinkSocket.bind(async_cache=True))... weird.
Just to be sure have you tried to repro with vng:
https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-sty...
? It could be the base OS difference, too, but that's harder to confirm.
To confirm, is it possible to run in the constrained environment, but put a 5s sleep or something? I will add the following either as a separate patch (ie 7/8), or I can fold it into 6/7 (and drop Stefano's ACK waiting for another review):
wait_for_if() { if ip link show "$2" >/dev/null 2>&1; then return 0; fi
for d in `seq 1 30`; do sleep 1 if ip link show "$2" >/dev/null 2>&1; then return 0; fi done return 1 }
.... setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip
- wait_for_if "ovs_br0" run_cmd ip link set ovs_br0 up
....
Does it make sense or does it seem like I am way off base?
sleep 1 is a bit high (sleep does accept fractional numbers!)
This script was originally (and mostly is) all nice and POSIX (where sleep doesn't take fractional numbers), so, if you don't mind, I'd rather prefer "sleep 0.1 || sleep 1". :)
Jakub Kicinski kuba@kernel.org writes:
On Mon, 24 Jun 2024 12:53:45 -0400 Aaron Conole wrote:
Additionally, the "Cannot find device ..." text comes from an iproute2 utility output. The only place we actually interact with that is via the call at pmtu.sh:973:
run_cmd ip link set ovs_br0 up
Maybe it is possible that the link isn't up (could some port memory allocation or message be delaying it?) yet in the virtual environment.
Depends on how the creation is implemented, normally device creation over netlink is synchronous. Just to be sure have you tried to repro with vng:
https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-sty...
? It could be the base OS difference, too, but that's harder to confirm.
Yes - that's the way I run it. But I didn't try to use any of the stress inducing options. I'll work on it with that.
To confirm, is it possible to run in the constrained environment, but put a 5s sleep or something? I will add the following either as a separate patch (ie 7/8), or I can fold it into 6/7 (and drop Stefano's ACK waiting for another review):
wait_for_if() { if ip link show "$2" >/dev/null 2>&1; then return 0; fi
for d in `seq 1 30`; do sleep 1 if ip link show "$2" >/dev/null 2>&1; then return 0; fi done return 1 }
.... setup_ovs_br_internal || setup_ovs_br_vswitchd || return $ksft_skip
- wait_for_if "ovs_br0" run_cmd ip link set ovs_br0 up
....
Does it make sense or does it seem like I am way off base?
sleep 1 is a bit high (sleep does accept fractional numbers!) but otherwise worth trying, if you can't repro locally.
Ack.
On Mon, 2024-06-24 at 12:53 -0400, Aaron Conole wrote:
Aaron Conole aconole@redhat.com writes:
Jakub Kicinski kuba@kernel.org writes:
On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Thanks for the work!
Looks like the series no longer applies because of other changes to the kernel config. Before it stopped applying we got some runs, here's what I see:
https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
# Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0"
Any idea why? Looks like kernel config did include OVS, perhaps we need explicit modprobe now? I don't see any more details in the logs.
Strange. I expected that the module should have automatically been loaded when attempting to communicate with the OVS genetlink family type. At least, that is how it had been working previously.
I'll spend some time looking into it and resubmit a rebased version. Thanks, Jakub!
If the ovs module isn't available, then I see:
# ovs_bridge not supported # TEST: IPv4, OVS vxlan4: PMTU exceptions [SKIP]
But if it is available, I haven't been able to reproduce such ovs_br0 setup failure - things work.
I'm still wondering if the issue is Kconfig-related (plus possibly bad interaction with vng). I don't see the OVS knob enabled in the self- tests config. If it's implied by some other knob, and ends-up being selected as a module, vng could stumble upon loading the module at runtime, especially on incremental build (at least I experience that problem locally). I'm not even sure if the KCI is building incrementally or not, so all the above could is quite a wild guess.
In any case I think adding the explicit CONFIG_OPENVSWITCH=y the selftest config would make the scenario more well defined.
Cheers,
Paolo
Paolo Abeni pabeni@redhat.com writes:
On Mon, 2024-06-24 at 12:53 -0400, Aaron Conole wrote:
Aaron Conole aconole@redhat.com writes:
Jakub Kicinski kuba@kernel.org writes:
On Thu, 20 Jun 2024 08:55:54 -0400 Aaron Conole wrote:
This series enhances the ovs-dpctl utility to provide support for set() and tunnel() flow specifiers, better ipv6 handling support, and the ability to add tunnel vports, and LWT interfaces. Finally, it modifies the pmtu.sh script to call the ovs-dpctl.py utility rather than the typical OVS userspace utilities.
Thanks for the work!
Looks like the series no longer applies because of other changes to the kernel config. Before it stopped applying we got some runs, here's what I see:
https://netdev-3.bots.linux.dev/vmksft-net/results/648440/3-pmtu-sh/stdout
# Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS vxlan6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve4: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0" # TEST: IPv4, OVS geneve6: PMTU exceptions - nexthop objects [FAIL] # Cannot find device "ovs_br0" # TEST: IPv6, OVS geneve6: PMTU exceptions [FAIL] # Cannot find device "ovs_br0"
Any idea why? Looks like kernel config did include OVS, perhaps we need explicit modprobe now? I don't see any more details in the logs.
Strange. I expected that the module should have automatically been loaded when attempting to communicate with the OVS genetlink family type. At least, that is how it had been working previously.
I'll spend some time looking into it and resubmit a rebased version. Thanks, Jakub!
If the ovs module isn't available, then I see:
# ovs_bridge not supported # TEST: IPv4, OVS vxlan4: PMTU exceptions [SKIP]
But if it is available, I haven't been able to reproduce such ovs_br0 setup failure - things work.
I'm still wondering if the issue is Kconfig-related (plus possibly bad interaction with vng). I don't see the OVS knob enabled in the self- tests config. If it's implied by some other knob, and ends-up being selected as a module, vng could stumble upon loading the module at runtime, especially on incremental build (at least I experience that problem locally). I'm not even sure if the KCI is building incrementally or not, so all the above could is quite a wild guess.
In any case I think adding the explicit CONFIG_OPENVSWITCH=y the selftest config would make the scenario more well defined.
That is in 7/7 - but there was a collision with a netfilter knob getting turned on. I can repost it as-is (just after rebasing) if you think that is the only issue.
Cheers,
Paolo
On Tue, 25 Jun 2024 09:20:29 -0400 Aaron Conole wrote:
I'm still wondering if the issue is Kconfig-related (plus possibly bad interaction with vng). I don't see the OVS knob enabled in the self- tests config. If it's implied by some other knob, and ends-up being selected as a module, vng could stumble upon loading the module at runtime, especially on incremental build (at least I experience that problem locally). I'm not even sure if the KCI is building incrementally or not, so all the above could is quite a wild guess.
In any case I think adding the explicit CONFIG_OPENVSWITCH=y the selftest config would make the scenario more well defined.
That is in 7/7 - but there was a collision with a netfilter knob getting turned on. I can repost it as-is (just after rebasing) if you think that is the only issue.
Sorry for not checking it earlier, looks like the runner was missing pyroute:
# python3 ./tools/testing/selftests/net/openvswitch/ovs-dpctl.py Need to install the python pyroute2 package >= 0.6.
I guess run_cmd counter-productively eats the stderr output ? :(
Jakub Kicinski kuba@kernel.org writes:
On Tue, 25 Jun 2024 09:20:29 -0400 Aaron Conole wrote:
I'm still wondering if the issue is Kconfig-related (plus possibly bad interaction with vng). I don't see the OVS knob enabled in the self- tests config. If it's implied by some other knob, and ends-up being selected as a module, vng could stumble upon loading the module at runtime, especially on incremental build (at least I experience that problem locally). I'm not even sure if the KCI is building incrementally or not, so all the above could is quite a wild guess.
In any case I think adding the explicit CONFIG_OPENVSWITCH=y the selftest config would make the scenario more well defined.
That is in 7/7 - but there was a collision with a netfilter knob getting turned on. I can repost it as-is (just after rebasing) if you think that is the only issue.
Sorry for not checking it earlier, looks like the runner was missing pyroute:
# python3 ./tools/testing/selftests/net/openvswitch/ovs-dpctl.py Need to install the python pyroute2 package >= 0.6.
I guess run_cmd counter-productively eats the stderr output ? :(
Awesome :) I will add a patch to ovs-dpctl that will turn the sys.exit(0) into sys.exit(1) - that way it should do the skip.
When I previously tested, I put an error in the `try` without reading the except being specifically for a ModuleNotFound error.
I'll make sure pyroute2 isn't installed when I run it again.
Thanks for your help Jakub and Paolo!
On Tue, 25 Jun 2024 10:14:24 -0400 Aaron Conole wrote:
Sorry for not checking it earlier, looks like the runner was missing pyroute:
# python3 ./tools/testing/selftests/net/openvswitch/ovs-dpctl.py Need to install the python pyroute2 package >= 0.6.
I guess run_cmd counter-productively eats the stderr output ? :(
Awesome :) I will add a patch to ovs-dpctl that will turn the sys.exit(0) into sys.exit(1) - that way it should do the skip.
When I previously tested, I put an error in the `try` without reading the except being specifically for a ModuleNotFound error.
I'll make sure pyroute2 isn't installed when I run it again.
Thanks for your help Jakub and Paolo!
BTW I popped the v2 back into the queue, so the next run (in 20min) will tell us if that's the only thing we were missing 🤞️
Jakub Kicinski kuba@kernel.org writes:
On Tue, 25 Jun 2024 10:14:24 -0400 Aaron Conole wrote:
Sorry for not checking it earlier, looks like the runner was missing pyroute:
# python3 ./tools/testing/selftests/net/openvswitch/ovs-dpctl.py Need to install the python pyroute2 package >= 0.6.
I guess run_cmd counter-productively eats the stderr output ? :(
Awesome :) I will add a patch to ovs-dpctl that will turn the sys.exit(0) into sys.exit(1) - that way it should do the skip.
When I previously tested, I put an error in the `try` without reading the except being specifically for a ModuleNotFound error.
I'll make sure pyroute2 isn't installed when I run it again.
Thanks for your help Jakub and Paolo!
BTW I popped the v2 back into the queue, so the next run (in 20min) will tell us if that's the only thing we were missing 🤞️
:) I'll wait to post the v3 then. So far, the only change I have is:
--- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -34,7 +34,7 @@ try:
except ModuleNotFoundError: print("Need to install the python pyroute2 package >= 0.6.") - sys.exit(0) + sys.exit(1)
OVS_DATAPATH_FAMILY = "ovs_datapath" ---
On Tue, 25 Jun 2024 11:17:14 -0400 Aaron Conole wrote:
BTW I popped the v2 back into the queue, so the next run (in 20min) will tell us if that's the only thing we were missing 🤞️
:) I'll wait to post the v3 then. So far, the only change I have is:
--- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py @@ -34,7 +34,7 @@ try: except ModuleNotFoundError: print("Need to install the python pyroute2 package >= 0.6.")
- sys.exit(0)
- sys.exit(1)
Looks like it didn't get re-ingested :( please go ahead with the v3
On Tue, 25 Jun 2024 07:06:54 -0700 Jakub Kicinski kuba@kernel.org wrote:
On Tue, 25 Jun 2024 09:20:29 -0400 Aaron Conole wrote:
I'm still wondering if the issue is Kconfig-related (plus possibly bad interaction with vng). I don't see the OVS knob enabled in the self- tests config. If it's implied by some other knob, and ends-up being selected as a module, vng could stumble upon loading the module at runtime, especially on incremental build (at least I experience that problem locally). I'm not even sure if the KCI is building incrementally or not, so all the above could is quite a wild guess.
In any case I think adding the explicit CONFIG_OPENVSWITCH=y the selftest config would make the scenario more well defined.
That is in 7/7 - but there was a collision with a netfilter knob getting turned on. I can repost it as-is (just after rebasing) if you think that is the only issue.
Sorry for not checking it earlier, looks like the runner was missing pyroute:
# python3 ./tools/testing/selftests/net/openvswitch/ovs-dpctl.py Need to install the python pyroute2 package >= 0.6.
I guess run_cmd counter-productively eats the stderr output ? :(
Yes, otherwise it's rather noisy, but you can run the thing with VERBOSE=1, see also 56490b623aa0 ("selftests: Add debugging options to pmtu.sh").
Before that change, we didn't eat standard error, but in the general case I guess it's quite an improvement.
linux-kselftest-mirror@lists.linaro.org
-
Aaron Conole -
Jakub Kicinski -
Paolo Abeni -
Stefano Brivio