[dpdk-dev] Application framework vs. library

Wiles, Keith keith.wiles at intel.com
Mon Aug 1 17:27:53 CEST 2016


> On Aug 1, 2016, at 5:04 AM, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 
> Hi,
> 
> Thanks for explaining your context.
> Your concerns are known under the term "usability enhancements".
> As they require some API changes, we won't make them in the release 16.11.
> But we must work on it now to be able to announce the API changes for 17.02
> before the 16.11 release.
> 
> 2016-08-01 10:18, Steffen.Bauch at rohde-schwarz.com:
>> Concerning the integration we try to cope with the circumstance that
>> DPDK is more comparable to an application framework and less to a
>> library.
> 
> I think DPDK should be easier to use and considered as a normal library.
> 
> 
> [...]
>> Logging behavior
>> 
>> Opening a connection to the system logger for our program is within the
>> responsibility of our specific logging module that is also used in the
>> proprietary parts of the application. For this reason openlog() should
>> not be called in our use case. In addition, using rte_openlog_stream()
>> is not usable before rte_eal_init() as logging init will overwrite the
>> used log stream. For this reason a large part of the init logs can not
>> be handled by a custom log stream. Btw, after removal of the log caching,
>> is there a fundamental difference between early log and normal logging?
> 
> You're right. Now that the log history is removed, we can rework the log
> initialization and reconsider early logging.
> 
>> A possible approach for the future could be to initialize rte_logs.file
>> to NULL (in fact it is, as it is static) and only set it during
>> initialization if it is NULL with the goal to be able to use
>> rte_openlog_stream() before rte_eal_init(). As the openlog() call is
>> only relevant when the default log stream is used (and architecture
>> dependent!) I introduced a specific entry point for calling openlog. The
>> main complexity to this changeset is added due to two reasons. First
>> reason is the circumstance that rte_eal_common_log_init() is used several
>> times during early logging and real logging initialization. Second
>> aspect is that a user might revert to the use of the default_log_stream
>> after a custom log stream has be used straight from the beginning (even
>> before rte_eal_init()). A dedicated changeset towards v16.07 for this
>> improvement is attached for review, feedback and possible inclusion.
> 
> Before entering in the proposed design for a custom log handler, we should
> discuss the desired features in DPDK logging.
> Is there some developer who would like to see the logs improved to be
> dynamically tuned in run-time live?
> Or should we just allow a custom log handler and provide only a default
> minimal handler?

I would suggest we have a custom log handler for applications that have their own logging system. I believe we still need a logging system in DPDK as a complete ‘none’ library type system. DPDK was designed as a complete system (or appears that way), but I understand moving toward a library design is reasonable. I just do not want to lose the complete system design as we should be able to have both.

The only down side to a library design is testing becomes more complex IMO as we do not have a standard configuration(s) and “complete” applications. DPDK is a complex designed system and it can become difficult to test the library interactions if we do not have a clean way to test the complete set of libraries.

> 
> 
>> Process termination behavior
>> 
>> As the DPDK functionality is only a small part of the whole application
>> ownership of the running process is not with DPDK and it is not allowed
>> to cancel the running process as a result of an error. For this reason,
>> the current changeset instead of calling rte_panic or rte_exit returns
>> an error code and handles it in the calling function. Unfortunately this
>> change was only implemented in rte_eal_init() and not in other places
>> (drivers, libs ...), so there is currently no safety that an unknown
>> code part terminates the whole application on the spot. Future changes
>> and patches could change the error handling in a more thorough approach,
>> but I would like to have some feedback and opinions before I start the
>> heavy-lifting work in over 700 code locations. Even some interfaces
>> might be affected, as lots of functions return void now,
> 
> Yes, please let's remove every panic/exit calls from DPDK.
> The only reason it is still there is that nobody took the time to remove
> these traces from the early support of bare metal environment (now dropped).

Removing the panic calls is find, but the patch just replaces them with return -1 and will not do as you need to know why the calls failed. Replacing them with returning an error code and calling a log output would be much more reasonable.

> 
> 
>> Thread creation
>> 
>> In our application thread creation and setting the affinity is already
>> handled in a proprietary module. Frames are polled and processed
>> in non-EAL pthreads. For this reason the lcore thread creation in
>> rte_eal_init() is completely removed as we do not want additional threads
>> to be assigned to processing CPUs. Unfortunately setting the coremask
>> to 0 is not feasible directly. For the non-EAL threads a custom function
>> within the application sets the per_thread _lcore variable to the right
>> value to try to enable mbuf cacheing. The changeset also disables the
>> interrupt handling thread as in our application it currently seems not
>> necessary (maybe make this optional?)
>> 
>> In an experiment I removed the error check for the non-zero number of
>> lcores and quick-fixed certain locations where rte_lcore_count() is used
>> for memory size computations and at least got a running application.
>> 
>> A possible approach could be to enhance enum rte_lcore_role_t with an
>> auxiliary thread type and introduce additional eal arguments to assign
>> lcores with these auxiliary role.
> 
> My personal opinion is that DPDK (as a library) should not create some
> threads at all.
> The loops and workload strategy is the responsibility of the application.

Removing the threading support in DPDK is reasonable, but we also need to keep the support for applications that are using DPDK as is. We should not toss out the ‘none’ library design just to make it harder for everyone that does not view DPDK as just a library to use.

We need to support both is a seamless way and be able to test DPDK without having to write a bunch of ‘application’ code to support the new library only design.

Regards,
Keith



More information about the dev mailing list