[dpdk-dev] Clarification for eth_driver changes

Shreyansh Jain shreyansh.jain at nxp.com
Wed Nov 16 06:09:15 CET 2016

On Monday 14 November 2016 11:08 PM, Ferruh Yigit wrote:
> What I was thinking is:
> rte_device/driver are not abstract classes.
> rte_bus device/driver is an abstract class and any bus inherited from
> this class.
> rte_func device/driver is and abstract class and eth/crypto inherited
> from this class.
> eal layer only deal with rte_bus
> pmd's only deal with functional device/driver
> but still, it is required to know device <-> driver, and functional <->
> bus, relations. rte_dev/rte_driver are to provide this links.
> But yes this add extra layer and with second thought I am not sure if it
> is really possible to separate bus and functionality, this was just an
> idea ..

I understand your point. It would really nice if we can achieve that 
level pluggable-ness where drivers would be able to choose a 'profile' - 
where 'profiles' are like net/crypto etc. In your text, 

Maybe once the basic model is in place, we can revisit this idea.


More information about the dev mailing list