dpacc:meeting_minutes_0730
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dpacc:meeting_minutes_0730 [2015/08/07 06:25] Lingli Deng [ODP overview] |
dpacc:meeting_minutes_0730 [2015/08/07 06:51] (current) Lingli Deng [DPDK updated proposal] |
||
|---|---|---|---|
| Line 67: | Line 67: | ||
| * Keith is concerned that this proposal would suffer a performance hit and break compatiblity for all of the current DPDK customers, as would be required to rewrite their VNF applications to address the portability issues. “I would expect most would continue down the current DPDK path and then we have a fragmented world. Having ODP/SoC SDK at the driver layer only makes sense as this is the correct location for these types of drivers plus not effecting the performance of DPDK applications. If the ODP layer is truly not effecting performance then running ODP as a PMD would not effect the SoC performance as well.” * | * Keith is concerned that this proposal would suffer a performance hit and break compatiblity for all of the current DPDK customers, as would be required to rewrite their VNF applications to address the portability issues. “I would expect most would continue down the current DPDK path and then we have a fragmented world. Having ODP/SoC SDK at the driver layer only makes sense as this is the correct location for these types of drivers plus not effecting the performance of DPDK applications. If the ODP layer is truly not effecting performance then running ODP as a PMD would not effect the SoC performance as well.” * | ||
| ===== DPDK updated proposal ===== | ===== DPDK updated proposal ===== | ||
| + | |||
| + | The first slide was a rework of the earlier agreed VNF | ||
| + | Application in Guest from OPNFV mini summit at NFV WC。 | ||
| + | * Mention of ODP was removed and Abdel Rabi of Altera expressed confusion by this. | ||
| + | * Keith clarified that this is just a DPDK perspective and does not imply that ODP or other Acceleration Core were not supported. "Later in the slides I would show where ODP/SoC SDK’s would be addressed." | ||
| + | * Bob commented that the optics of this positioning creates controversy however and it would be better to show project drawings like this as they were agreed to not exclude candidate ACs. | ||
| + | |||
| + | Keith showed a new slide emphasizing their desire to preserve DPDK investment | ||
| + | by those who had created integrations with DPDK. | ||
| + | * Clarification from Huawei was asked regarding statement that DPDK supports hardware acceleration with software acceleration option. | ||
| + | * Keith responded that "with high performing cores today, it would be easier to use software as the setup time involved in handing the data off to hardware would/could be to high compared to software just doing the work. On lesser performing cores then hardware would be required as the operations in software would be to slow otherwise." | ||
| + | * There was not necessarily agreement on this. Note: This would seem to be counter to NFV PoC #19 where the Intel CPU + Axxia SoC IPSec and DPI acceleration showed 10x performance gains in workflow with 90%+ reduction in jitter. | ||
| + | * Keith suggested that this be left for further clarification from Magnus later. "Maybe Magnus can address this one as he was the designer of the software for the Axxia product." | ||
| + | |||
| + | There was new concrete proposal for folding certain ODP support into DPDK. "Extending DPDK with ODP features gives us the best of both worlds!" | ||
| + | - Configuration: Combine the two configuration models | ||
| + | - DPDK supports only PCI configuration model | ||
| + | - ODP supports only SoC configuration model | ||
| + | - Memory manager: Combine the two memory manager models | ||
| + | - ODP supports a external memory manager for SoC controlled memory | ||
| + | - DPDK support a high performance memory manager for devices without memory managers | ||
| + | - Run-to-Completion and Event based model: Combine the two run models | ||
| + | - DPDK uses Run-to-Completion for high performance | ||
| + | - ODP uses Event-based model for programming model | ||
| + | |||
| + | "The phase one design would be to have ODP as a set of PMDs to allow Intel, MIPS, PowerPC and ARM systems to use any configuration they so desire to meet their system goals." | ||
| + | * Bob commented that the proposed SoC model in DPDK, whereby SoCs are implemented as PMD drivers (including using ODP APIs is desired) seems to relegate SoC to plug-in NIC cards with Intel x86 Host CPUs. | ||
| + | * Keith clarified that for VNF applications running on IA systems it does mean these SoC’s would be plugin cards, but in systems like ARM platforms with the SoC integrated on the board then NO it does not need to be a plugin card to that system. "The goal is to be able to run DPDK on any platform and unify the world by addressing the above issues in DPDK." | ||
| + | * Bob feared there was a fundamental lack of understanding the ODP is not a driver abstraction interface alone. "It is an application interface that is its full mode significantly contributes to a scalable many-core application scheduling model. ODP as a PMD does not really make sense and SoCs as PMD are viewed as perhaps applicable in only one use case, not all. This is a point of contention that would need further study, but the ODP team is convinced this would add unnecessary overhead. But ODP could and probably should add a NIC interface concept that is compatible with PMD, for external NICs at least." | ||
| + | * Keith responded that it seemed his proposal would apply to a number of cases. And DPDK is already able to run multiple devices at the same time, plus SoC device if needed. "I understand the ODP is not a driver here and I agree it will never be a driver. What ODP is today is an abstraction layer for any given SoC vendor SDK. By utilizing ODP as a abstraction layer for a number of SoC’s it allows DPDK to support any SoC using a PMD that understands the ODP API and abstraction." | ||
| + | |||
| + | DPDK and ODP teams can assess the viability of supporting both memory manager models in their respective projects. | ||
| + | |||
| + | It was agreed that data plane applications are generally RTC fundamentally. | ||
| + | * Bob commented on RTC model v Event-based Model. He clarified that ODP supported a simple polled mode operation, without queue/event structure to be close to DPDK model if desired _and_ an event-based advanced model. | ||
| + | * Keith stated that DPDK currently uses the RTC model only, because "DPDK started with IA systems where a single core is sufficient for a single task, and it does not make sense to use many cores to handle a single task with an event model reduces the performance. If DPDK were to be run on a different system with lower performance cores then it would be reasonable to have an event based system and the desire to add this support to DPDK." | ||
| + | |||
| + | Keith wrapped up proposed concrete next steps of adding support in DPDK for the above features and requested help with a standard DPDK implementation for ARM. | ||
| ===== Summary and next step discussion ===== | ===== Summary and next step discussion ===== | ||
dpacc/meeting_minutes_0730.1438928750.txt.gz · Last modified: 2015/08/07 06:25 by Lingli Deng
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
