On Wed, Mar 1, 2023 at 4:41 PM Simon Horman <simon.hor...@corigine.com> wrote:
> On Wed, Mar 01, 2023 at 09:04:40AM -0500, Mark Michelson wrote: > > On 3/1/23 01:49, Simon Horman wrote: > > > On Wed, Mar 01, 2023 at 07:31:04AM +0100, Ales Musil wrote: > > > > On Tue, Feb 28, 2023 at 8:03 PM Mark Michelson <mmich...@redhat.com> > wrote: > > > > > > > > > Hi Ales, > > > > > > > > > > > > > > May I suggest placing the tests that are failing with the userspace > > > > > datapath into the tests/system-ovn-kmod.at file? The current > structure > > > > > of the test files is: > > > > > > > > > > tests/system-ovn.at: Tests that can run with any datapath. > > > > > tests/system-ovn-kmod.at: Tests that can only be run with the > kernel > > > > > datapath. > > > > > > > > > > Presumably if there was ever a test that only passed with the > userspace > > > > > datapath, we'd add a file for that too. > > > > > > > > > > Note that you'll still want the new macro in this commit, since > there's > > > > > nothing in the build system that ensures that tests in > > > > > tests/system-ovn-kmod.at are only run with the kernel datapath. > The > > > > > separate files are strictly for organization. > > > > > > > > > > > > > > > > > Hi Mark, > > > > > > > > wouldn't that be a bit counter intuitive? The main goal is to have > > > > everything working with userspace datapath, so if there is a fix > > > > we would move the test back. > > > > Yes, if any of the kernel-only tests began to work with userspace as > well, > > we would move the test back. > > > > > > > > > > Anyway I don't have a strong preference so if there is an agreement > > > > I'll update this commit. > > > > I don't have a strong preference either, but I do prefer that we have > > consistency. So if we're going to put all system tests in the same file, > > then I think a separate follow-up commit (which I can do) to move the > > existing test that is in system-ovn-kmod.at back into system-ovn.at > would be > > good. The alternative would be to move these new tests to > system-ovn-kmod.at > > and no additional follow-up commits. > > > > > > > > FWIIW, > > > > > > I think the distinction is between: > > > > > > 1. Expected to work, but does not. F.e. bug somewhere; and > > > 2. Not expected to work. F.e. feature or behaviour exists > > > in one datapath but not the other (yet). > > > > The existing test in system-ovn-kmod.at probably falls into category 2. > The > > problem is that SCTP is not implemented in userspace conntrack. It's a > > missing feature. > > > > The LB affinity tests referred to by Ales sound more like category 1 to > me. > > > > For an OVN dev, the distinction doesn't mean much because we have to do > the > > same thing no matter what: skip the test if using userspace datapath. I > > think the expectation for both categories is that eventually, the tests > will > > pass with all datapaths. > > Yes, I think that they are good points. > > I was thinking that in theory there could be something permanently, in > category 2. But perhaps this is more a theoretical than a practical > consideration. > > > As I mentioned above, I don't have a strong preference one way or the > other, > > but I do want to ensure we're consistent. > > Yes, agreed. > > ... > > I've added an additional patch in v3 that moves those tests into system-ovn-kmod.at. Thanks, Ales -- Ales Musil Senior Software Engineer - OVN Core Red Hat EMEA <https://www.redhat.com> amu...@redhat.com IM: amusil <https://red.ht/sig> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
