RE: Upcoming libibverbs release

Liran Liss
2016-06-30T18:17:06Z

> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Jason Gunthorpe

> On Wed, Jun 29, 2016 at 08:19:56AM +0300, Leon Romanovsky wrote:
> > On Tue, Jun 28, 2016 at 09:26:38PM +0000, Hefty, Sean wrote:
> > > > The fundamental question is if it is acceptable for libibverbs to
> > > > ship a new core provider agnostic API (cq polling) that is
> > > > optional depending on provider.
> > > >
> > > > I say no, that is not acceptable.
> > >
> > > I agree - there's no compelling argument that the new calls can't work over
> all providers.
> >
> > I agree too, this is why code is provided and nothing stops from other provider
> to support it.
>
> That isn't what I said, and it isn't what everyone is agreeing with.
>
> I said an optinal API is not acceptable to ship.
>

What?
Almost every device interface has optional APIs.

The most immediate example is our beloved netdevice, in which almost everything is optional: fcoe support, flow steering, fdb settings, sriov controls...
All of these features are provider-agnostic, yet each netdev either implements them or not.

Especially in a performance-critical interface a polling API, I think that it actually makes more sense that each vendor provides the most optimized implementation that suits the HW.
--Liran