[dpdk-dev] DPDK User Space: Session onUseability and Ease of Use

[Mcnamara, John]

> -----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.
--