RE: DPDK Summit Montreal - Schedule

[Konstantin Ananyev <konstantin.ananyev@huawei.com>]

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