DPDK patches and discussions
 help / color / mirror / Atom feed
From: Lincoln Lavoie <lylavoie@iol.unh.edu>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Tyler Retzlaff <roretzla@linux.microsoft.com>, dev@dpdk.org
Subject: Re: DPDK:fast-tests suite linux/vm
Date: Wed, 21 Dec 2022 15:47:52 -0500	[thread overview]
Message-ID: <CAOE1vsNJViezwQABLN9-0JSdM6RtyFYQNg0D7teF9mWkFurV2g@mail.gmail.com> (raw)
In-Reply-To: <20221221114941.63e3bd24@hermes.local>

[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]

16GB should be enough to run the unit tests.  You'll likely have better
luck with the system setup to provide pages.  Our lab runners provide 2560x
2MB pages (5 GB), out of their 16G of RAM.  We only run 1 unit test at a
time on each runner, because of noise neighbor issues between the
containers.

On Wed, Dec 21, 2022 at 2:49 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Wed, 21 Dec 2022 11:33:36 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>
> > On Wed, Dec 21, 2022 at 11:03:33AM -0800, Stephen Hemminger wrote:
> > > On Wed, 21 Dec 2022 10:13:49 -0800
> > > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> > >
> > > > hi folks,
> > > >
> > > > are there any additional requirements that may not be documented for
> > > > running the DPDK:fast-tests suite in a vm on linux?
> > > >
> > > > if i run the suite as follows i end up getting intermittent failures.
> > > > are there known issues running in a vm?
> > > >
> > > >   meson test -C u --test-args='--no-huge' --suite fast-tests
> > > >
> > > > RTE>>fbarray_autotest
> > > >  + ------------------------------------------------------- +
> > > >  + Test Suite : fbarray autotest
> > > >
> > > > Thread 1 "dpdk-test" received signal SIGBUS, Bus error.
> > > > __memset_evex_unaligned_erms () at
> > > > ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:250
> > > > 250     ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No
> such
> > > > file or directory.
> > > > (gdb) bt
> > > > #0  __memset_evex_unaligned_erms () at
> > > > ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:250
> > > > #1  0x0000555556022d5b in rte_fbarray_init (arr=0x55555e3566c0
> <param>,
> > > >     name=0x55555bebdb28 "fbarray_autotest", len=256, elt_sz=4) at
> ../lib/eal/common/eal_common_fbarray.c:802
> > > > #2  0x00005555557b24af in autotest_setup () at
> ../app/test/test_fbarray.c:31
> > > > #3  0x0000555555636f03 in unit_test_suite_runner
> (suite=0x55555c846140 <fbarray_test_suite>)
> > > >     at ../app/test/test.c:306
> > > > #4  0x00005555557b5ffc in test_fbarray () at
> ../app/test/test_fbarray.c:733
> > > > #5  0x00005555556292c4 in cmd_autotest_parsed
> (parsed_result=0x7fffffff8140, cl=0x55556a8b2fa0, data=0x0)
> > > >     at ../app/test/commands.c:68
> > > > #6  0x0000555555fb3294 in __cmdline_parse (cl=0x55556a8b2fa0,
> buf=0x55556a8b2fe8 "fbarray_autotest\n",
> > > >     call_fn=true) at ../lib/cmdline/cmdline_parse.c:294
> > > > #7  0x0000555555fb32dc in cmdline_parse (cl=0x55556a8b2fa0,
> buf=0x55556a8b2fe8 "fbarray_autotest\n")
> > > >     at ../lib/cmdline/cmdline_parse.c:302
> > > > #8  0x0000555555fb1577 in cmdline_valid_buffer (rdl=0x55556a8b2fb0,
> buf=0x55556a8b2fe8 "fbarray_autotest\n",
> > > >     size=18) at ../lib/cmdline/cmdline.c:24
> > > > #9  0x0000555555fb667d in rdline_char_in (rdl=0x55556a8b2fb0, c=10
> '\n') at ../lib/cmdline/cmdline_rdline.c:444
> > > > #10 0x0000555555fb19bd in cmdline_in (cl=0x55556a8b2fa0,
> buf=0x7fffffffe3f0 "fbarray_autotest\n", size=17)
> > > >     at ../lib/cmdline/cmdline.c:146
> > > > #11 0x0000555555636a34 in main (argc=2, argv=0x7fffffffe930) at
> ../app/test/test.c:208
> > > >
> > > > thanks!
> > >
> > > Were hugepages setup before running the test? Was there enough memory
> available?
> >
> > hugepages are not setup on the system, i explicitly pass --no-huge or
> > does that not do what i think it should?
> >
> > the vm has fixed 16GB memory, stepping through the code i do not see
> > internal allocation calls fail prior to the failure.
> >
> > thanks
>
> Could be that the allocation gives bogus memory?
>


-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylavoie@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)
<https://www.iol.unh.edu>

[-- Attachment #2: Type: text/html, Size: 5708 bytes --]

  reply	other threads:[~2022-12-21 20:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 18:13 Tyler Retzlaff
2022-12-21 19:03 ` Stephen Hemminger
2022-12-21 19:33   ` Tyler Retzlaff
2022-12-21 19:49     ` Stephen Hemminger
2022-12-21 20:47       ` Lincoln Lavoie [this message]
2022-12-21 20:59       ` Tyler Retzlaff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOE1vsNJViezwQABLN9-0JSdM6RtyFYQNg0D7teF9mWkFurV2g@mail.gmail.com \
    --to=lylavoie@iol.unh.edu \
    --cc=dev@dpdk.org \
    --cc=roretzla@linux.microsoft.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).