Hi Aaron, Thank you for the review!
On 16/07/2026 22:00, Aaron Conole wrote: > Aaron Conole <[email protected]> writes: >> "Matthieu Baerts (NGI0)" <[email protected]> writes: >> >>> The kselftests doc mentions that a config file should be present "if a >>> test needs specific kernel config options enabled". This selftest >>> requires some kernel config, but no config file was provided. >>> >>> We could say that a sub-target could use the parent's config file, but >>> the kselftests doc doesn't mention anything about that. Plus the >>> net/openvswitch target is the only net target without a config file. >> >> We've been operating on that assumption from the openvswitch side, but >> it's true that isn't explicitly documented anywhere, and I guess it >> isn't officially supported in the kselftest framework. I guess we'll >> need to keep updating this config as we add tests for things like SCTP, >> and others, and maybe that's a good thing like we can add a comment >> describing which tests take which configs. >> >> The downside is for most of the OVS testing we use the NIPA scripts >> and those 'inherit' the parent config, so it would be a change on our >> side from the development standpoint (but probably something we should >> have been doing from the beginning). >> >> That said, would it be worth also exploring the 'cascading >> configuration' support? It seems like a useful feature, but maybe it >> should be a separate discussion. I ask because of how OVS interacts >> with the networking stack as an 'alternative bridge' so-to-speak, I do >> worry about having to duplicate lots of configurations between the two >> as we expand the test coverage on OVS side. It is not clear to me what you are using on your side, but I guess it should be doable to modify some scripts to merge this new config file and the net one in your case. >>> Here is a new config file, which is a trimmed version of the net one, >>> with hopefully the minimal required kconfig on top of 'make defconfig'. >> >> Should this also remove the OVS configs from the upper level since there >> shouldn't be OVS tests executing there (ie: CONFIG_OPENVSWITCH*)? > > Actually, forget this part. The P-MTU tests in pmtu.sh use ovs to > create a datapath through OVS. So these configurations need to stay at > the top level as well. Indeed. I don't know these tests well, but maybe this P-MTU selftest should move to the net/openvswitch target? Cheers, Matt
