[v3,0/4] no-huge unit test

  For environments (such as containers) where hugetlbfs are not available,
some unit tests can be run with 'no-huge' option.

fast-tests suites is generated dynamically according to hugetlbfs
availability in building environment. This allows unit test to run
in different environments using the same suite name.

Several test cases are fixed to be able to run in no-huge mode.

v3:
Use a single suite instead of create additional one for no-huge. (Aaron)
Fix several test cases in no-huge mode.

v2:
Add a patch to enable running multiple suites in a job. (David)


Ruifeng Wang (4):
  test: enable tests to run in no-huge mode
  ci: generate fast-tests suite base on hugepage availability
  ci: proceed with verification without hugepage
  ci: enable unit test for aarch64

 .ci/linux-setup.sh             |  11 +-
 .travis.yml                    |   5 +-
 app/test/meson.build           | 216 ++++++++++++++++++---------------
 app/test/test_acl.c            |  22 ++--
 app/test/test_hash.c           |   7 +-
 app/test/test_table_pipeline.c |  12 +-
 6 files changed, 152 insertions(+), 121 deletions(-)
  

Ruifeng Wang <ruifeng.wang@arm.com> writes:

> For environments (such as containers) where hugetlbfs are not available,
> some unit tests can be run with 'no-huge' option.
>
> fast-tests suites is generated dynamically according to hugetlbfs
> availability in building environment. This allows unit test to run
> in different environments using the same suite name.
>
> Several test cases are fixed to be able to run in no-huge mode.

This looks great!  Thanks, Ruifeng.

I'm going to ack it once I see it run under the robot :)

> v3:
> Use a single suite instead of create additional one for no-huge. (Aaron)
> Fix several test cases in no-huge mode.
>
> v2:
> Add a patch to enable running multiple suites in a job. (David)
>
>
> Ruifeng Wang (4):
>   test: enable tests to run in no-huge mode
>   ci: generate fast-tests suite base on hugepage availability
>   ci: proceed with verification without hugepage
>   ci: enable unit test for aarch64
>
>  .ci/linux-setup.sh             |  11 +-
>  .travis.yml                    |   5 +-
>  app/test/meson.build           | 216 ++++++++++++++++++---------------
>  app/test/test_acl.c            |  22 ++--
>  app/test/test_hash.c           |   7 +-
>  app/test/test_table_pipeline.c |  12 +-
>  6 files changed, 152 insertions(+), 121 deletions(-)
  

Aaron Conole <aconole@redhat.com> writes:

> Ruifeng Wang <ruifeng.wang@arm.com> writes:
>
>> For environments (such as containers) where hugetlbfs are not available,
>> some unit tests can be run with 'no-huge' option.
>>
>> fast-tests suites is generated dynamically according to hugetlbfs
>> availability in building environment. This allows unit test to run
>> in different environments using the same suite name.
>>
>> Several test cases are fixed to be able to run in no-huge mode.
>
> This looks great!  Thanks, Ruifeng.
>
> I'm going to ack it once I see it run under the robot :)

Just looking through the robot's run, it seems that on the statically
linked Arm64 build, the disk quota is getting exceeded.  Do we need to
request some more disk quota for this somehow?  Is the build getting too
large?

>> v3:
>> Use a single suite instead of create additional one for no-huge. (Aaron)
>> Fix several test cases in no-huge mode.
>>
>> v2:
>> Add a patch to enable running multiple suites in a job. (David)
>>
>>
>> Ruifeng Wang (4):
>>   test: enable tests to run in no-huge mode
>>   ci: generate fast-tests suite base on hugepage availability
>>   ci: proceed with verification without hugepage
>>   ci: enable unit test for aarch64
>>
>>  .ci/linux-setup.sh             |  11 +-
>>  .travis.yml                    |   5 +-
>>  app/test/meson.build           | 216 ++++++++++++++++++---------------
>>  app/test/test_acl.c            |  22 ++--
>>  app/test/test_hash.c           |   7 +-
>>  app/test/test_table_pipeline.c |  12 +-
>>  6 files changed, 152 insertions(+), 121 deletions(-)
  

On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole@redhat.com> wrote:
>
> Aaron Conole <aconole@redhat.com> writes:
>
> > Ruifeng Wang <ruifeng.wang@arm.com> writes:
> >
> >> For environments (such as containers) where hugetlbfs are not available,
> >> some unit tests can be run with 'no-huge' option.
> >>
> >> fast-tests suites is generated dynamically according to hugetlbfs
> >> availability in building environment. This allows unit test to run
> >> in different environments using the same suite name.
> >>
> >> Several test cases are fixed to be able to run in no-huge mode.
> >
> > This looks great!  Thanks, Ruifeng.
> >
> > I'm going to ack it once I see it run under the robot :)
>
> Just looking through the robot's run, it seems that on the statically
> linked Arm64 build, the disk quota is getting exceeded.  Do we need to
> request some more disk quota for this somehow?  Is the build getting too
> large?

It seems to repeat.
https://travis-ci.com/github/ovsrobot/dpdk/jobs/297840285#L2975

Do you know how much space we have in travis?
Is the (c?)cache getting too big?
You can find out the per job cache size via the travis cli.
  

> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, March 13, 2020 23:54
> To: Aaron Conole <aconole@redhat.com>
> Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Michael Santana
> <maicolgabriel@hotmail.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Cristian Dumitrescu
> <cristian.dumitrescu@intel.com>; Wang, Yipeng1
> <yipeng1.wang@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>;
> dev <dev@dpdk.org>; Burakov, Anatoly <anatoly.burakov@intel.com>;
> Gavin Hu <Gavin.Hu@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; juraj.linkes@pantheon.tech; nd
> <nd@arm.com>
> Subject: Re: [PATCH v3 0/4] no-huge unit test
> 
> On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole@redhat.com> wrote:
> >
> > Aaron Conole <aconole@redhat.com> writes:
> >
> > > Ruifeng Wang <ruifeng.wang@arm.com> writes:
> > >
> > >> For environments (such as containers) where hugetlbfs are not
> > >> available, some unit tests can be run with 'no-huge' option.
> > >>
> > >> fast-tests suites is generated dynamically according to hugetlbfs
> > >> availability in building environment. This allows unit test to run
> > >> in different environments using the same suite name.
> > >>
> > >> Several test cases are fixed to be able to run in no-huge mode.
> > >
> > > This looks great!  Thanks, Ruifeng.
> > >
> > > I'm going to ack it once I see it run under the robot :)
> >
> > Just looking through the robot's run, it seems that on the statically
> > linked Arm64 build, the disk quota is getting exceeded.  Do we need to
> > request some more disk quota for this somehow?  Is the build getting
> > too large?
> 
> It seems to repeat.
> https://travis-ci.com/github/ovsrobot/dpdk/jobs/297840285#L2975
> 
> Do you know how much space we have in travis?
> Is the (c?)cache getting too big?

Yes, it is probably caused by cache.
I hit the disk quota issue as well when running Travis against the latest Master code.
After deleting caches, the issue was gone. Then Travis run with this series of patches also got a pass.

Hi Aaron,
Is is OK to clear cache of robot and re-run the build?

Thanks.
/Ruifeng

> You can find out the per job cache size via the travis cli.
> 
> 
> --
> David Marchand
  

Ruifeng Wang <Ruifeng.Wang@arm.com> writes:

>> -----Original Message-----
>> From: David Marchand <david.marchand@redhat.com>
>> Sent: Friday, March 13, 2020 23:54
>> To: Aaron Conole <aconole@redhat.com>
>> Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>; Michael Santana
>> <maicolgabriel@hotmail.com>; Bruce Richardson
>> <bruce.richardson@intel.com>; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; Cristian Dumitrescu
>> <cristian.dumitrescu@intel.com>; Wang, Yipeng1
>> <yipeng1.wang@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>;
>> dev <dev@dpdk.org>; Burakov, Anatoly <anatoly.burakov@intel.com>;
>> Gavin Hu <Gavin.Hu@arm.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; juraj.linkes@pantheon.tech; nd
>> <nd@arm.com>
>> Subject: Re: [PATCH v3 0/4] no-huge unit test
>> 
>> On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole@redhat.com> wrote:
>> >
>> > Aaron Conole <aconole@redhat.com> writes:
>> >
>> > > Ruifeng Wang <ruifeng.wang@arm.com> writes:
>> > >
>> > >> For environments (such as containers) where hugetlbfs are not
>> > >> available, some unit tests can be run with 'no-huge' option.
>> > >>
>> > >> fast-tests suites is generated dynamically according to hugetlbfs
>> > >> availability in building environment. This allows unit test to run
>> > >> in different environments using the same suite name.
>> > >>
>> > >> Several test cases are fixed to be able to run in no-huge mode.
>> > >
>> > > This looks great!  Thanks, Ruifeng.
>> > >
>> > > I'm going to ack it once I see it run under the robot :)
>> >
>> > Just looking through the robot's run, it seems that on the statically
>> > linked Arm64 build, the disk quota is getting exceeded.  Do we need to
>> > request some more disk quota for this somehow?  Is the build getting
>> > too large?
>> 
>> It seems to repeat.
>> https://travis-ci.com/github/ovsrobot/dpdk/jobs/297840285#L2975
>> 
>> Do you know how much space we have in travis?
>> Is the (c?)cache getting too big?
>
> Yes, it is probably caused by cache.
> I hit the disk quota issue as well when running Travis against the latest Master code.
> After deleting caches, the issue was gone. Then Travis run with this
> series of patches also got a pass.
>
> Hi Aaron,
> Is is OK to clear cache of robot and re-run the build?

I can do this, but I am concerned that we will need to disable the cache
to avoid this error on a consistent basis.

> Thanks.
> /Ruifeng
>
>> You can find out the per job cache size via the travis cli.
>> 
>> 
>> --
>> David Marchand
  

David Marchand <david.marchand@redhat.com> writes:

> On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole@redhat.com> wrote:
>>
>> Aaron Conole <aconole@redhat.com> writes:
>>
>> > Ruifeng Wang <ruifeng.wang@arm.com> writes:
>> >
>> >> For environments (such as containers) where hugetlbfs are not available,
>> >> some unit tests can be run with 'no-huge' option.
>> >>
>> >> fast-tests suites is generated dynamically according to hugetlbfs
>> >> availability in building environment. This allows unit test to run
>> >> in different environments using the same suite name.
>> >>
>> >> Several test cases are fixed to be able to run in no-huge mode.
>> >
>> > This looks great!  Thanks, Ruifeng.
>> >
>> > I'm going to ack it once I see it run under the robot :)
>>
>> Just looking through the robot's run, it seems that on the statically
>> linked Arm64 build, the disk quota is getting exceeded.  Do we need to
>> request some more disk quota for this somehow?  Is the build getting too
>> large?
>
> It seems to repeat.
> https://travis-ci.com/github/ovsrobot/dpdk/jobs/297840285#L2975

Yes.

> Do you know how much space we have in travis?

Suppposedly we have 18G on that container... :-/

> Is the (c?)cache getting too big?
> You can find out the per job cache size via the travis cli.

When using the travis CLI:

  $ travis cache
  no caches found

I know this must be untrue, but it seems to not want to send me details
on my system.

I tried going through the API, but the largest cache file I see is 200M,
so I must be misunderstanding something.
  

On Mon, Mar 16, 2020 at 10:13:23AM -0400, Aaron Conole wrote:
> David Marchand <david.marchand@redhat.com> writes:
> 
> > On Fri, Mar 13, 2020 at 2:04 PM Aaron Conole <aconole@redhat.com> wrote:
> >>
> >> Aaron Conole <aconole@redhat.com> writes:
> >>
> >> > Ruifeng Wang <ruifeng.wang@arm.com> writes:
> >> >
> >> >> For environments (such as containers) where hugetlbfs are not available,
> >> >> some unit tests can be run with 'no-huge' option.
> >> >>
> >> >> fast-tests suites is generated dynamically according to hugetlbfs
> >> >> availability in building environment. This allows unit test to run
> >> >> in different environments using the same suite name.
> >> >>
> >> >> Several test cases are fixed to be able to run in no-huge mode.
> >> >
> >> > This looks great!  Thanks, Ruifeng.
> >> >
> >> > I'm going to ack it once I see it run under the robot :)
> >>
> >> Just looking through the robot's run, it seems that on the statically
> >> linked Arm64 build, the disk quota is getting exceeded.  Do we need to
> >> request some more disk quota for this somehow?  Is the build getting too
> >> large?
> >
I think as a general rule we need to limit the number of static builds we
do, and possibly skip building all the examples for the static builds.
Given we have almost 50 examples, that's a lot of linking of libraries into
binaries. For meson builds, perhaps we only pass -Dexamples=all for the
shared builds, and maybe do -Dexamples=l3fwd or similar for the static
ones. One or two examplse to check that the linking works with examples
should be enough if we test the build of the examples themselves in the
shared build jobs.

Thoughts?

/Bruce
  

On 2020-03-13 01:16, Ruifeng Wang wrote:
> For environments (such as containers) where hugetlbfs are not 
> available,
> some unit tests can be run with 'no-huge' option.
> 
> fast-tests suites is generated dynamically according to hugetlbfs
> availability in building environment. This allows unit test to run
> in different environments using the same suite name.
> 
> Several test cases are fixed to be able to run in no-huge mode.
> 
> v3:
> Use a single suite instead of create additional one for no-huge. 
> (Aaron)
> Fix several test cases in no-huge mode.
> 
> v2:
> Add a patch to enable running multiple suites in a job. (David)
> 
> 
> Ruifeng Wang (4):
>   test: enable tests to run in no-huge mode
>   ci: generate fast-tests suite base on hugepage availability
>   ci: proceed with verification without hugepage
>   ci: enable unit test for aarch64
> 
>  .ci/linux-setup.sh             |  11 +-
>  .travis.yml                    |   5 +-
>  app/test/meson.build           | 216 ++++++++++++++++++---------------
>  app/test/test_acl.c            |  22 ++--
>  app/test/test_hash.c           |   7 +-
>  app/test/test_table_pipeline.c |  12 +-
>  6 files changed, 152 insertions(+), 121 deletions(-)


I added Ruifeng's patches on top of my ppc64le ci patches and updated 
the matrix.
Ci ran fine on ppc64le.  
https://travis-ci.org/github/djlwilder/dpdk/jobs/663573687

Tested-by: David Wilder <dwilder@us.ibm.com>