[ovs-dev] [v6 07/11] test/sytem-dpdk: Add unit test for mfex autovalidator
Eelco Chaudron
echaudro at redhat.com
Thu Jul 8 08:37:04 UTC 2021
On 7 Jul 2021, at 20:34, Amber, Kumar wrote:
> Hi Eelco,
>
> Replies are inline.
<snip>
>
> \ No newline at end of file
> diff --git a/tests/pcap/mfex_test b/tests/pcap/mfex_test
>
> I would give the pcap file the .pcap extension just to be clear!
>
>
>
> Actually cannot all the pcaps present in test prior to this commit
> also don't hold extension as the automake tries to compile them
> keeping them without extension prevents this compilation error.
Guess you did not modify the automake file, it worked when I did that:
$ git diff tests/automake.mk
diff --git a/tests/automake.mk b/tests/automake.mk
index e94ccd27c..2bcf054b0 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -145,7 +145,7 @@ $(srcdir)/tests/fuzz-regression-list.at:
tests/automake.mk
EXTRA_DIST += $(MFEX_AUTOVALIDATOR_TESTS)
MFEX_AUTOVALIDATOR_TESTS = \
- tests/pcap/mfex_test \
+ tests/pcap/mfex_test.pcap \
tests/mfex_fuzzy.py
>
> new file mode 100644
> index
> 0000000000000000000000000000000000000000..1aac67b8d643ecb016c758cba4cc32212a80f52a
> GIT binary patch
> literal 416
> zcmca|c+)~A1{MYw`2U}Qff2}Q<eHVR>K`M68ITRa|G at yFii5$Gfk6YL%z>@uY&}o|
> z2s4N<1VH2&7y^V87$)XGOtD~MV$cFgfG~zBGGJ2#YtF$<F=a4i;9x8Q*<ZrSM6Ufz
> xK>KST_NTIwYriok6N4Vm)gX-Q@<yO<!C`>c^{cp<7_5LgK^UuU{2>VS0RZ!RQ+EIW
>
> literal 0
> HcmV?d00001
>
> diff --git a/tests/system-dpdk.at b/tests/system-dpdk.at
> index 802895488..fcab92729 100644
> --- a/tests/system-dpdk.at
> +++ b/tests/system-dpdk.at
> @@ -232,3 +232,49 @@ OVS_VSWITCHD_STOP(["\@does not exist. The Open
> vSwitch kernel module is probably
> \@EAL: No free hugepages reported in hugepages-1048576kB at d"])
> AT_CLEANUP
> dnl
> --------------------------------------------------------------------------
> +
> +dnl
> --------------------------------------------------------------------------
> +dnl Add standard DPDK PHY port
>
> I think we should also skip these tests if we do not have a machine
> that has AVX512. Just to make sure we do not generate an OK where we
> are not even testing the AVX512 functions.
>
> Actually we should not what if someone wants to write a new mfex
> version without AVX but just SIMD or some other way than we are
> probably blocking the testing
Good catch! I think we should run the test if other implementations are
available, else skip (except for auto, scalar, and study as they are
always available).
<SNIP>
More information about the dev
mailing list