DPDK Summit Montreal - Schedule

DPDK Summit Montreal - Schedule

[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

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.


There will be also a session led by boards members
allowing every attendees to ask questions about how our community works.


This new event will enhance even more our project & community.
See you there

Re: DPDK Summit Montreal - Schedule

[Ferruh Yigit]

On 8/13/2024 7:13 PM, Thomas Monjalon wrote:
> 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
> 
> 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

RE: DPDK Summit Montreal - Schedule

[Konstantin Ananyev]

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

Re: DPDK Summit Montreal - Schedule

[Ferruh Yigit]

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.