On Mon, Jun 17, 2019 at 1:57 PM Bruce Richardson <bruce.richard...@intel.com> wrote:
> On Mon, Jun 17, 2019 at 01:41:21PM +0200, David Marchand wrote: > > On Mon, Jun 17, 2019 at 1:18 PM Bruce Richardson > > <[1]bruce.richard...@intel.com> wrote: > > > > On Mon, Jun 17, 2019 at 12:46:03PM +0200, David Marchand wrote: > > > On Mon, Jun 17, 2019 at 12:02 PM Bruce Richardson > > > <[1][2]bruce.richard...@intel.com> wrote: > > > > > > On Sat, Jun 15, 2019 at 08:42:15AM +0200, David Marchand > > wrote: > > > > This is a joint effort to make the unit tests ready for CI. > > > > The first patches are fixes that I had accumulated. > > > > Then the second part of the series focuses on skipping > > tests when > > > some > > > > requirements are not fulfilled so that we can start them in > > a > > > restrained > > > > environment like Travis virtual machines that gives us two > > cores > > > and does > > > > not have specific hw devices. > > > > > > > > We are still not ready for enabling those tests in Travis. > > > > At least, the following issues remain: > > > > - some fixes on librte_acl have not been merged yet [1], > > > > - the tests on --file-prefix are still ko, and have been > > isolated > > > in a > > > > test that we could disable while waiting for the fixes, > > > > - rwlock_autotest and hash_readwrite_lf_autotest are taking > > a > > > little more > > > > than 10s, > > > > - librte_table unit test crashes on ipv6 [2], > > > > - the "perf" tests are taking way too long for my taste, > > > > - the shared build unit tests all fail when depending on > > mempool > > > since > > > > the mempool drivers are not loaded, > > > > > > > For the autotest app shared builds, it is probably worthwhile > > > linking in > > > all drivers explicitly to avoid issues like this. > > > > > > Yes, I'll look into this. > > > While at it, do you know why the i40e and ixgbe drivers are > > linked to > > > app/test in meson? > > > -- > > There are unit tests for the device-specific functions in those > > drivers, so > > they need to be given at link time. > > > > For testpmd, I can understand. > > But I can't see code for driver specific apis in app/test. > > It looks like a copy/paste error when adding meson support. > > -- > Ok, could be. Simple question is does it still build ok if you remove them? > It would have been strange if it did not build, since on Makefile side we do nothing. Yes, it builds fine with meson without this. I managed to get the same test results than with static builds by linking the skeleton eventdev driver and the mempool sw drivers. Should be enough. -- David Marchand
