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

Ananyev, Konstantin konstantin.ananyev at intel.com
Mon Jul 11 12:39:26 CEST 2016



> > > > > 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.

Bypass HW doesn't present on all ixgbe devices.
Only few specific models have that functionality.
So we still to provide and API for user to query is that functionality is supported or not,
user still has to make a decision based on HW id. 

> 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.

Ok, what is your definition of 'heterogeous machines' then?
Let say today, as I know, only i40e and ixgbe can do HW mirroring of the traffic.
Is that  generic enough, or not?
I suppose we can find huge number of examples, when functionality differes
between different HW models.
As I remember that was discussed a while ago, and generic conclusion was:
avoid device specific API exposed to the application layer. 

> 
> > > 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.

User and application writer don't have to guess on what device his code will work.
He can just query what ioctl IDs that device support, and then use the supported ones.

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

Ok, then I misunderstood you here.

> 
> > 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.

Ok, thanks.
Konstantin



More information about the dev mailing list