Re: [PATCH v2 net-next 0/7] selftests: net: Switch pmtu.sh to use the internal ovs script.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aaron Conole <aconole@xxxxxxxxxx> writes:

> Jakub Kicinski <kuba@xxxxxxxxxx> 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?





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux