#####################################################################
Attendees
* Patrick Robb
* Jeremy Spewock
* Paul Szczepanek
* Luca Vizzarro
* Juraj Linkeš
#####################################################################
Minutes
=====================================================================
General Announcements
* AT UNH IOL, Nick installed some Broadcom 25G nics on our DTS dev
servers which the team will be able to use for testing their patches
going forward.
=====================================================================
Patch discussions
* Hugepages patch:
* Morten noted on the mailing list that 2mb pages may not be
supported on all arches, and suggested 32 bit x86 required >4mb
* Bruce noted that most distros use PAE mode to allow physical
addresses >4gb, and this also means that 32 bit hugepages can be 2mb.
Based on this information we are able to proceed without tracking
supported hugepage sizes per arch
* Juraj notes that PAE allows 32 bit systems to allow for use of
more than 4GB of memory.
* If we hit problems in the future with the current
implementation, it can be refactored at that point to allow for more
configurability.
* Morten also requested that “suggested” hugepages count which
conf.yaml ships with be kept at 256
* If we want to change it, we need to writeup the specific
reasons why. We were originally basing it on the 1024 hugepages
example given in DPDK docs system requirements, and then doubling it +
buffer since users may run on 2 socket systems in which hugepages are
split between numa nodes.
* This justification should be in the commit message
* Juraj is also going to test increasing his allocation from 256
pages and see if he can run smoke tests successfully (current failing
some unit tests)
* Various functions need to be renamed to clarify they are
hardcoded to set 2mb huge page sizes specifically
* Juraj recommends simply setting a class variable for the time
being which stores HUGEPAGE_SIZE
* We need to document some of the assumptions we are making, like:
* If you are setting hugepages from DTS, we assume you are
trying to set 2mb pages
* This can be set from /doc/guides/tools/dts.rst
* Improve output gathering patch:
* Current process for gathering output relies on finding expected
prompt within output buffer
* When the output itself contains the prompt, it is a false positive
* So, check for the prompt at the end of the output.
* There could still be this prompt at the end of normal
output, so it’s not 100% bulletproof, but watching for this should be
easy to maintain
* Jeremy will update this patch to make it consistent with other
error messages
* Testpmd statefullness / params class
* Juraj provided some feedback, and Luca will submit another patch
later in the month
* How do we handle timeouts? Old strategy is setting a timeout per
sent command.
* The only place where we change the timeout is when we build dpdk
* In almost all cases, we do not need to set some custom timeout
for sending a command for interactive or noninteractive shells.
* Assumption is that when we implement testsuites, new testpmd
shell is launched every time we start a new testcase. So, changing the
timeout on an instance of the testpmd shell will not affect another
testcase.
* If for any reason testpmd HAS to be reused for two checks,
those two checks need to be within the same testcase.
* Should testcases be self contained?
* Paul notes that his understanding based on his experience is
that testcases should be self contained, and run in any order.
* From here we can set a new rule, which is that we need to open
and close testpmd every time we start a new testcase
* This rule needs to be documented. Just mentioning it in the
testpmd class is fine.
* The isolation should be enforced by the system, not a
requirement placed on developers and requiring human validation
* This is essentially forced anyways by having developers use
the testpmd context manager
* This patch also adding some features which are not used in DTS
right now. Usually we don’t want to do this, but these are based on
previous discussions and we want to lay the groundwork for further
development in the future. The group agrees there is a high likelihood
that these features will be required, thus we are comfortable bringing
them in now.
* https://patchwork.dpdk.org/project/dpdk/list/?series=31622
* Skip test cases based on capabilities
* Jeremy has rebased his new scatter testcase off of this patch
* He will run this
* Jeremy is concerned that “show rxq info” is not giving correct
capability information for scatter on all NICs.
* We could compose a list of capabilities which we expect we will
need in the near future, and Juraj could add support for those.
* How to compose it? We have a rough idea of what testsuites we
want to port. We should go through for those testsuites, check for
needed capabilties,
* Patrick Robbshould make a bugzilla ticket for Nick or Prince
checking this
* Luca also has an RFC he can submit which adds some support for
checking port capability - will need to get on the mailing list and
review at a future meeting
* Replace XML-RPC server with scapy shell:
* Jeremy will submit this soon - needs to CC Juraj for a review
=====================================================================
Any other business
* None
