> > 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 > > > > 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, 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.
