On Fri 18 May 2018 at 12:33, Jamal Hadi Salim <j...@mojatatu.com> wrote: > On 17/05/18 09:35 AM, Vlad Buslov wrote: >> >> On Wed 16 May 2018 at 21:51, Jiri Pirko <j...@resnulli.us> wrote: >>> Wed, May 16, 2018 at 11:23:41PM CEST, vla...@mellanox.com wrote: >>>> > >>>>> Please make sure you have these in your kernel config: >>>>> >>>>> CONFIG_NET_ACT_IFE=y >>>>> CONFIG_NET_IFE_SKBMARK=m >>>>> CONFIG_NET_IFE_SKBPRIO=m >>>>> CONFIG_NET_IFE_SKBTCINDEX=m >>> >>> Roman, could you please add this to some file? Something similar to: >>> tools/testing/selftests/net/forwarding/config >>> > > How would putting the file there help? > >>> Thanks! >>> >>>>> >>>>> For tdc to run all the tests, it is assumed that all the supported tc >>>>> actions/filters are enabled and compiled. >>>> >>>> Enabling these options allowed all ife tests to pass. Thanks! >>>> >>>> Error in u32 test still appears however: >>>> >>>> Test e9a3: Add u32 with source match >>>> >>>> -----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 >>>> ingress" >>>> >>>> -----> prepare stage *** Error message: "Cannot find device "v0p1" >> >> I investigated and was able to fix u32 problems. >> >> First of all, u32 test requires having veth interfaces that are not >> created by test infrastructure by default. Following command fixes the >> issue: >> >> sudo ip link add v0p0 type veth peer name v0p1 >> > > That is documented on the README i believe - however, we should > be able to detect that a test needs the device and create it via > a plugin. Lucas?
Description from README: * The kernel must have veth support available, as a veth pair is created prior to running the tests. For me it looked like test suite will create veth pair by itself and I only need to enable veth support in kernel config. > >> After executing this command test passes, however looking at test >> definition itself it seems meaningless. It creates filter with match >> source IP 127.0.0.1, then tests if filter with source IP 127.0.0.2 >> exists, but passes successfully because it actually expects to match >> zero filters with such IP :) >> >> I fixed it and it passed properly matching single filter with source IP >> 127.0.0.2. >> > > Please send a patch. Done. > >> After this flower test failed. The flower test expects that user >> explicitly provide "-d" option with interface to use. With -d it failed >> again. This time because it expects action to have 1m references, but >> actual value was 1000001. I investigated it and found out that test >> passed, if executed without running other tests first. So it seemed that >> some other test was leaking reference to gact action. It turned out that >> culprit was mirred test 6fb4, which created pipe action but didn't flush >> it afterward. >> > > Hopefully the last patch from Roman fixes that? Otherwise send something > on top. Done. > >> With all tests passing on that particular version of net-next, I will >> now rebase my changes on top of it and run them again. >> > > Thank you Vlad! > > cheers, > jamal
