DPDK Summit Montreal - Schedule
Quoted 23 lines · Thomas Monjalon
The next DPDK Summit will be hosted in Montreal, Canada on September 24-25.
We will talk about the future of DPDK, the best userland networking libraries having an incredible hardware support from our large community. It will be an opportunity to connect, learn and collaborate with developers from around the world who contribute to and utilize DPDK.
Talks will cover CPU optimizations, GPU processing, machine learning, hashing, packet offload, cryptography, testing and more.
The schedule can be found here, almost complete:
https://events.linuxfoundation.org/dpdk-summit/program/schedule/A workshop session is planned to allow debating and making progress in smaller group discussions about specific topics to be determined. Examples of such topics could be:
- debuggability
- power management techniques & efficiency
- config restore bypass in ethdev port start
- secondary process usage and limitations
Quoted 4 lines
Feel free to propose your ideas in advance so we can come prepared. Then we will organize ourselves in discussion groups
in order to progress and hopefully reach some new conclusions.
What do you think about 'rte_flow', it is a powerful tool but complex and not adopted in same level by all vendors. As it hard to test, we are having difficulty to provide consistency between vendor implementations. We can discuss how to spread understanding among various vendors and users, how to increase adoption, and future targets/plans.
Another one can be 'tooling', as a result of kernel bypass, some known Linux networking tools does not work with DPDK solutions, and this creates confusing and entry barrier for some people, this problem mentioned a few times before.
Perhaps we should address this problem in a more structured way, to design and later implement gradually some solutions. We can discuss methods and plans to improve our tooling support.
Thanks,
ferruh
Quoted 34 lines
Quoted 22 lines
We will talk about the future of DPDK, the best userland networking libraries having an incredible hardware support from our large community. It will be an opportunity to connect, learn and collaborate with developers from around the world who contribute to and utilize DPDK.
Talks will cover CPU optimizations, GPU processing, machine learning, hashing, packet offload, cryptography, testing and more.
The schedule can be found here, almost complete:
https://events.linuxfoundation.org/dpdk-summit/program/schedule/A workshop session is planned to allow debating and making progress in smaller group discussions about specific topics to be determined. Examples of such topics could be:
- debuggability
- power management techniques & efficiency
- config restore bypass in ethdev port start
- secondary process usage and limitationsQuoted 4 lines
Feel free to propose your ideas in advance so we can come prepared. Then we will organize ourselves in discussion groups
in order to progress and hopefully reach some new conclusions.What do you think about '
rte_flow', it is a powerful tool but complex and not adopted in same level by all vendors. As it hard to test, we are having difficulty to provide consistency between vendor implementations. We can discuss how to spread understanding among various vendors and users, how to increase adoption, and future targets/plans.
Quoted 8 lines
Another one can be 'tooling', as a result of kernel bypass, some known Linux networking tools does not work with DPDK solutions, and this creates confusing and entry barrier for some people, this problem mentioned a few times before.
Perhaps we should address this problem in a more structured way, to design and later implement gradually some solutions. We can discuss methods and plans to improve our tooling support.
Thanks Ferruh, sound like an interesting ones to me, specially the second one.
As another possible subject: we talk about how to make core DPDK data-structures (mempool, hash-table, ring, etc.) less static: i.e. add ability to grow/shrink on demand? Another long-hanging thing - RTE_MAX_LCORE... - can it be runtime parameter, instead of build-time parameter?
All these things I think would help overall by reducing memory footprint, improving usability, etc.
Quoted 43 lines · Konstantin Ananyev
Quoted 34 lines
Quoted 22 lines
We will talk about the future of DPDK, the best userland networking libraries having an incredible hardware support from our large community. It will be an opportunity to connect, learn and collaborate with developers from around the world who contribute to and utilize DPDK.
Talks will cover CPU optimizations, GPU processing, machine learning, hashing, packet offload, cryptography, testing and more.
The schedule can be found here, almost complete:
https://events.linuxfoundation.org/dpdk-summit/program/schedule/A workshop session is planned to allow debating and making progress in smaller group discussions about specific topics to be determined. Examples of such topics could be:
- debuggability
- power management techniques & efficiency
- config restore bypass in ethdev port start
- secondary process usage and limitationsQuoted 4 lines
Feel free to propose your ideas in advance so we can come prepared. Then we will organize ourselves in discussion groups
in order to progress and hopefully reach some new conclusions.What do you think about '
rte_flow', it is a powerful tool but complex and not adopted in same level by all vendors. As it hard to test, we are having difficulty to provide consistency between vendor implementations. We can discuss how to spread understanding among various vendors and users, how to increase adoption, and future targets/plans.Quoted 8 lines
Another one can be 'tooling', as a result of kernel bypass, some known Linux networking tools does not work with DPDK solutions, and this creates confusing and entry barrier for some people, this problem mentioned a few times before.
Perhaps we should address this problem in a more structured way, to design and later implement gradually some solutions. We can discuss methods and plans to improve our tooling support.
Quoted 7 lines
Thanks Ferruh, sound like an interesting ones to me, specially the second one.
As another possible subject: we talk about how to make core DPDK data-structures (mempool, hash-table, ring, etc.) less static: i.e. add ability to grow/shrink on demand? Another long-hanging thing -RTE_MAX_LCORE... - can it be runtime parameter, instead of build-time parameter?
All these things I think would help overall by reducing memory footprint, improving usability, etc.
+1 to converting static data structures to dynamic ones discussion, RTE_MAX_ETHPORTS is the one in my focus that I would like to see it gone, (and a few friends of it, like RTE_MAX_QUEUES_PER_PORT, RTE_ETHDEV_RXTX_CALLBACKS, etc..)
I wonder if we can introduce a generic, C++ vector like dynamic resizing data structure first, and apply it to various cases we have at hand gradually.