> > My Soap box comment: > > I think we are limiting DPDK’s growth by only focusing on a few new PMDs > and reworking the existing code. We need to look forward and grow DPDK as > a community to get more people involved in adding more applications and > new designs. I believe DPDK.org needs to be a bigger community and not > just a I/O library called DPDK. We need to actively move the organization to > include more then just a high speed I/O library. Some will focus on DPDK and > others will focus on providing a higher level applications, libraries and > features. > > Sorry, I completly disagree with that vision. I think the scope of dpdk > should be more focused. > > Today, when someone adds a feature, (s)he sometimes updates eal, or > mbuf, > or any core layer required for its need. It can be just a hack, no matter > if the feature works. I have many examples like this. > > This makes any rework/enhancement of core libs painful. > Having separated core libs would encourage people to submit proper > generic enhancements, to have stable APIs. >
Hi Olivier, I think I understand your problem (reduce the effort of updating the "core" libs), but I also think your proposed solution (ignore all the other libs and apps that are being broken by the change) is wrong. When faced with a change that has ripple effect everywhere, why not post an RFC and ask for help from the other maintainers to share the burden? Regards, Cristian
