> On Aug 4, 2016, at 2:47 PM, Jim Murphy <jmurphy at arista.com> wrote: > > Hi, > > We are looking at using our existing test environment for our DPDK > applications that will run on our build servers. Hughpages therefore is an > issue. What is involved in running DPDK without huge pages?
Command line option ?no-huge should work. Note two dashs in front. > > Thanks, > > Jim > > > On Wed, Aug 3, 2016 at 1:46 PM, Ming Zhao(??) <mzhao at luminatewireless.com> > wrote: > >> googletest is a very nice test framework and we use it very >> extensively in our company(Luminate Wireless), together with gmock. >> >> I understand the resistance from the maintainers that are concerned >> about introducing a C++ dependency to a pure C code base. The approach >> we take doesn't require any change to the dpdk core, instead we just >> use things like a mock PMD(through gmock framework) to allow mocking >> the RX/TX code path, disabling huge page usage in test so that the >> test can be easily launched without worrying about huge page >> collision, etc. >> >> Personally I highly recommend using googletest plus some basic test >> cases, which removes a lot of boilerplate and let the developers focus >> the test itself. >> >> On Wed, Aug 3, 2016 at 2:57 AM, Doherty, Declan >> <declan.doherty at intel.com> wrote: >>> >>> >>>> -----Original Message----- >>> ... >>>> You are not advocating but the unit test must be written in C++. >>>> I don't think it is a good idea to force people to write and maintain >> the tests >>>> in a different language than the code it tests. >>> >>> I know where you are coming from on this point, and I general would >> agree if >>> it were not for the advantages you get from C++ test framework. Having >> worked with >>> multiple C and C++ frameworks, I've found that one of the biggest >> advantages of the >>> C++ frameworks is the amount of boilerplate code they can save you from >> writing. Also >>> nearly all of C frameworks I've used make use macros to the point that >> they look more like >>> objective C than C. In general I feel that even if the test code is >> written in C++ the code itself >>> should be simple enough that someone with even a passing knowledge of >> C++ could easily >>> understand the intent of the test code. >>> >>>>> Some of the major advantages of google test that I see over >> continuing to use >>>> the >>>>> current test include giving a consist feel to all tests, a powerful >> test >>>>> execution framework which allow individual test suites or tests to be >> specified >>>>> from the command line, support for a standard xunit output which can >> be >>>> integrated >>>>> into a continuous build systems, and a very powerful mocking library >>>>> which allows much more control over testing failure conditions. >>>> >>>> It would be interesting to better describe in details what is missing >> currently >>>> and what such a framework can bring. >>>> (I agree there is a huge room for improvements on unit tests) >>> >>> Some of the things I've come across include: >>> No standard output format to integrated with continuous regression >> systems >>> No ability to specify specific unit tests or groups of tests to run from >> the command line >>> No standard set of test assertions used across the test suites. >>> No standard setup and teardown functions across test suites, state from >> previous test >>> suite can break current >>> Requirement to use a python script to orchestrate test runs. >>> No support for mocking functionality. >>> >>> I know that none of the above couldn't be fixed in our current test >> application, but I would >>> question if it is effort worthwhile when we take an off the shelf >> framework, which does all >>> those things and a whole lot more, which has been test and used in a >> huge variety of >>> projects. >>> >>> I certainly willing to look at other frameworks both C and C++ but I yet >> to find a C framework >>> which come close to the usability and flexibility of the popular C++ >> ones. >>> >>> >>> >>