Re: DPDK Summit Montreal - Schedule

[Ferruh Yigit <ferruh.yigit@amd.com>]

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.