dpacc:meeting_minutes_0730
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
dpacc:meeting_minutes_0730 [2015/08/07 06:39] Lingli Deng [DPDK updated proposal] |
dpacc:meeting_minutes_0730 [2015/08/07 06:51] (current) Lingli Deng [DPDK updated proposal] |
||
|---|---|---|---|
| Line 94: | Line 94: | ||
| "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." | "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. | * 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. | + | * 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 stressed that 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. | + | * 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 seems 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. 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. | + | * 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. | 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. | It was agreed that data plane applications are generally RTC fundamentally. | ||
| - | * Bob 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. | + | * 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 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.1438929568.txt.gz · Last modified: 2015/08/07 06:39 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
