On 9/6/2024 3:09 PM, Konstantin Ananyev wrote: > > >>> 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. >
+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.
