2016-03-18 10:16, Stephen Hemminger: > As I look at how the ethernet device interface in DPDK has exploded in > complexity;
Yes I would like to start addressing this complexity in 16.07. > it makes life very hard for end users. The goal has been to enable all the > cool hardware > features, but it has put blinders on the driver devlopers; they are ignoring > the fact > that real applications can't just work on one kind of hardware. +1 > The DPDK is doing a terrible job at providing abstractions. There needs to > be a > real generic set of operations, and every hardware offload feature must: > * have a clear well defined API +1 > * if feature is not available in software, then the DPDK must provide > a software equivalent feature. I'm not against this idea. Looking for more opinions. > * any difference in API must be hidden from application. > * no compile config options about offload. > * tests and documentation must work for both hw and sw version > > Right now, all those offload features are pretty much unusable in a real > product > without lots and lots of extra codes and huge bug surface. It bothers me > enough > that I would recommend removing much of the filter/offload/ptype stuff from > DPDK! One of the biggest challenge is to think about a good filtering API. The offloading has some interaction with the mbuf struct. I would like to suggest rewriting ethdev API by keeping it as is for some time for compatibility while creating a new one. What about the prefix dpdk_netdev_ to progressively replace rte_eth_dev?
