> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas F Herbert
> Sent: Thursday, October 8, 2015 7:30 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] DPDK User Space: Session onUseability and Ease of Use
>
> All:
>
> Captured white board notes from Jim McNamara's session on Useability and
> Ease of Use at DPDK User Space today are here:
>
> http://people.redhat.com/therbert/Useability_and_Ease_of_Use_DPDK_User_Space/
Hi Tom,
Thanks for that. Here is my summary of the "Usability and Ease of
Use" session from memory and notes. Correction and additions welcome.
* Latest version of the DPDK docs
- (From an earlier session). Add a doc/latest build of the docs
to dpdk.org.
* PMD lite
- Do we need a lighter PMD model? Perhaps based on the Mellanox
model.
- Vincent suggested be could remove 90% of the code. I'll leave
Vincent explain this one.
* OvS issues with Usability
- Discussion of the DPSK usability issues highlighted on the
OvS mailing list.
- http://openvswitch.org/pipermail/dev/2015-August/058814.html
* Distributed testing
- There should be some form of distributed testing so patches
can be tested on OSes and hardware that a dev doesn't have.
- Suggestion to have an Open Lab/Pod similar to the OPNFV model
that participants can use.
* Debuggability
- User expectation for tools like tcpdump, ip, ipconfig to work
with DPDK bound NICs.
- Easier in a pipeline application where debug is added as a
pipeline stage.
- Maybe add debug hooks via rx/tx callbacks.
- Add/extend a solution based on KNI.
- Use systemd naming algorithm for KNI.
* Create a User Mailing List
- An observation was made that the dev at dpdk.org list was very
developer orientated and patch heavy.
- Suggestion to add a user at dpdk.org mailing list for people
with issues or subjects that aren't development related.
- This seams easy to implement. It may not be well supported
however resulting in users cross posting into dev at dpdk.org.
- Probably worth trying anyway.
* Make the dpdk.org website patchable
- There are already plans to host the dpdk.org code in a git
repo.
* Add a Contributing Guide.
- We are at the stage where we need one.
- Suggestion to just use the Kernel guide.
- Tailor it for DPDK.
- Also explain the review process, acks, nacks, etc.
* Add a README .txt or .1st to the root dir.
- This could just include links to the getting started guides
and other docs. Either to the online docs or how to build the
local html versions.
* EAL annoyances
- Move the EAL to the kernel.
- Have more/better/all default options. EAL figures out its own
requirements.
- Have a default for -n.
* Hugepage consumption
- Do not allow DPDK applications to grab all available hugepages.
- Issues with running DPDK apps in tandem with other hugepage
hungry apps such as Java/Eclipse.
* rte_malloc()
- Don't use rte_malloc() for non critical objects where
malloc() would do.
- Suggestion to allow the type of required memory to be
specified by rte_malloc()-like function.
* The Build system
- Make install needs to be improved. Doesn't so what the user expects.
- Use autotools and configure. (There were some objections that
this may not be an improvement.)
- Use kconfig.
- Keep going with what we have now until it gets too unwieldy
and needs to be changed. Then use kconfig.
- Add better support for cross compilation. Useful for arm target.
* Should DPDK applications be running as root
- Clearly not a great option.
- Currently required due to kernel.
* Mempool debugging
- We need better tools to debug memory leaks in the mempools.
- Suggestion to do this via a valgrind plugin.
* Kernel management of drivers
* Too much duplicated code in the PMDs
- Duplicated code has crept in organically as PMDs have been
added.
- Should be moved up to moved up to the ethdev level
* Logging and debugging via a secondary process
- Not a well known technique but very useful/powerful
* Run DPDK as a daemon.
* Issues with config files
- Too many options turned off by default: code paths don't get
compiled/tested.
* More sample apps
- Some more examples of using secondary processes.
Of these we the following could be addressed in the near term:
* Latest version of the docs. - Needs support from 6Wind.
* Distributed testing. - Needs support from Intel initially.
Some of this is already being rolled out on the
test-report at dpdk.org list for Intel hardware:
http://dpdk.org/ml/archives/test-report/. Other hardware
vendors could use the same automated test framework to host
something similar.
* Debuggability. - Need some volunteers or workable suggestions.
* Create a User Mailing List. - Needs support from 6Wind.
* Make the dpdk.org website patchable. - Needs support from
6Wind.
* Add a Contributing Guide. - I will submit a doc patch.
* Add a README .txt or .1st to the root dir. - I will submit a
doc patch.
* The Build system. - There are some patches on the list for an
updated "make install". This could be a start point.
* Mempool debugging. - Any volunteers to add/improve valgrind
support for DPDK? See also this patch from Brocade:
https://bugs.kde.org/show_bug.cgi?id=350405
* Too much duplicated code in the PMDs. - Any volunteers to
refactor common PMD code up into the ethdev layer?
* Logging and debugging via a secondary process. Any volunteers
to add a sample app that demonstrates the technique?
John.
--
