Hi Thomas,
On 26-07-2018 22:27, Thomas Monjalon wrote:
External Email
Anoob Joseph (12):
examples/l2fwd: move macro definitions to common header
examples/l2fwd: move structure definitions to common header
examples/l2fwd: move globally accessed vars to common header
examples/l2fwd: move dataplane code to new file
examples/l2fwd: remove unused header includes
examples/l2fwd: move drain buffers to new function
examples/l2fwd: optimize check for master core
examples/l2fwd: move periodic tasks to new function
examples/l2fwd: skip timer updates for non master cores
examples/l2fwd: move pkt send code to a new function
examples/l2fwd: use fprint instead of printf for usage print
examples/l2fwd: improvements to the usage print
Maintainers of this app look to be against adding complexity.
In order to get this series accepted, we need more discussions
with more people involved.
So it will miss 18.08.
It can be discussed in a more global discussion about examples maintenance.
If discussion does not happen, you can request it to the technical board.
Event dev framework and various adapters enable multiple packet handling
schemes, as opposed to the traditional polling on queues. But these
features are not integrated into any established example application.
There are specific example applications for event dev etc, which can be
used to analyze an event device or a particular eventdev adapter, but
there is no standard application which can be used to compare the real
world performance for a system when it's using event device for packet
handling and when it's done via polling on queues.
The following patch submitted by Sunil was looking to address this issue
with l3fwd,
https://mails.dpdk.org/archives/dev/2018-March/093131.html
Bruce & Jerin reviewed the patch and suggested the addition of helper
functions to abstract the event mode additions in applications,
https://mails.dpdk.org/archives/dev/2018-April/096879.html
This effort of adding helper functions for eventmode was taken up
following the above suggestion. The idea is to add eventmode without
touching the existing code path. All the eventmode specific additions
would go into library so that these need not be repeated for every
application. And since there is no change in the existing code path,
performance for any vendor should not have any impact with the additions.
The scope of this effort has increased since the submission, as now we
have Tx adapter as well. Sunil & Konstantin had clarified their
concerns, and gave green flag to this approach.
https://mails.dpdk.org/archives/dev/2018-June/105730.html
https://mails.dpdk.org/archives/dev/2018-July/106453.html
I guess Bruce was opening this question to the community. For compute
intense applications like ipsec-secgw, eventmode might be the right
approach in the first place. Such complex applications would need a
scheduler to perform dynamic load balancing. Addition of eventmode in
l2fwd was to float around the idea which can then be scaled for more
complex applications.
If maintainers doesn't have any objection to this, I'm fine with adding
this in the next release.
Thanks,
Anoob
