On Tue, 22 Mar 2016 07:19:01 -0500 Jay Rolette <rolette at infinite.io> wrote:
> On Tue, Mar 22, 2016 at 5:19 AM, Bruce Richardson < > bruce.richardson at intel.com> wrote: > > > On Tue, Mar 22, 2016 at 05:50:28AM +0000, Qiu, Michael wrote: > > > > > > Why not to implement one simple API with variable arguments, just like > > > syscall ioctl() does. And drivers implement it's specific hardware > > > features with a feature bit param, and other needed variable arguments. > > > > > > Thanks, > > > Michael > > > > A very much dislike that idea. > > * It makes the code much harder to read as you have to closely examine all > > the > > parameters to work out what a function call is actually meant to do. > > * It makes it much harder to see that you have an implicit dependency on a > > specific device. Having to include a driver specific header file e.g. > > i40e.h, > > and call a function named e.g. i40e_do_magic_stuff(), makes it pretty > > explicit > > that you have a dependency on i40e-based hardware > > * It prevents the compiler from doing type-checking on parameters and > > informing > > you of little inconsistencies. > > > > For all these reasons, I prefer the device-specific functions option. > > However, > > at the same time, we also need to ensure we have a reasonable set of > > generic > > APIs so that the cases where users are forced to drop down to the > > lower-level > > device-specific primitives are reduced. > > > > +1 I prefer the OO model where there is a generic network interface that provides a uniform set of features, and if a specific hw device provides a more efficient implementation of a feature, that is hidden (inheritance?) such that there is no difference API. The DPDK has been hardware vendor driven up until this point. But from a software point of view, it is more important to provide good API than use DPDK as a hardware POC environment.
