Re: [dpdk-dev] specific driver API - was bypass code cleanup

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-07-11 09:56, Ananyev, Konstantin:
> 
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API
> > > > for bypass is a good idea at all.
> > > > I was thinking to totally remove it.
> > >
> > > Why to remove it?
> > > As I know there are people who use that functionality.
> > >
> > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in
> > > > the application.
> > >
> > > Hmm, isn't that what we were trying to get rid of in last few years?
> > > HW specific stuff?
> > 
> > Yes exactly.
> > I have the feeling the bypass API is specific to ixgbe. Isn't it?
> 
> As far as I know, yes.
> 
> > As we will probably see other features specific to only one device.
> > Instead of adding a function in the generic API, I think it may be
> > saner to include a driver header.
> 
> But that means use has to make decision based on HW id/type of the device,
> the thing we were trying to get rid of in last few releases, no?

Not really. If an application requires the bypass feature, we can assume
it will be used only on ixgbe NICs.
Having some generic APIs helps to deploy DPDK applications on heterogeous
machines. But if an application rely on something hardware specific, there
is no benefit of using a "fake generic layer" I guess.

> > Then if it appears to be used
> > in more devices, it can be generalized.
> > What do you think of this approach?
> 
> We talked few times about introducing sort of ioctl() call, to communicate
> about HW specific features.
> Might be a bypass I a good candidate to be moved into this ioctl() thing...

I don't see how making an ioctl-like would be better than directly including
a specific header.

> But I suppose it's too late for 16.07 to start such big changes.

Of course yes.

> If you don't like bypass API to be a generic one, my suggestion would be
> to leave it as it is for 16.07, and start a discussion what it should look like
> for 16.11.

That's what we are doing here.
I've changed the title to give a better visibility to the thread.