Hi everyone, > > > > > > > > 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 > > > > It is important that DPDK has good examples of how to use existing > > frameworks and libraries. These applications are what most customers > > build their applications from and they provide basis for testing. > > > > The DPDK needs to continue to support multiple usage models. This > > is one of its strong points. I would rather leave existing l2fwd > > and l3fwd alone and instead make new examples that use the frameworks. > > If nothing else haveing l2fwd and l2fwd-eventdev would allow for > > performance comparisons. > > Unlike other applications example, there wont be any change in packet > processing functions in eventdev vs poll mode case. Only worker > schematics will change and that can be moved to separated files. > something like worker_poll.c and worker_event.c and both of them > use common packet processing functions using mbuf. > > The only disadvantage of having separate application would be packet > processing code duplication. Which is non trivial for l3fwd, IPSec > application IMO.
Personally I am ok with original design suggestion: keep packet processing code common, that would be used by both poll and event modes. We could just have a command-line parameter in which mode the app will run. Another alternative - generate two binaries l2fwd-poll, l2fwd-event (or so). Konstantin > > # Are we fine with code duplication in example application like l3fwd and > IPSec? > # if yes, Are we fine with keeping l2fwd _as is_ to reduce the > complexity and l2fwd-eventdev supports both modes wherever possible? > > > > > As the number of examples increases, probably also need to have > > a roadmap or decision chart to explain the advangage/disadvantage > > of each architecture. > >
