Re: [PATCH 6/9] ib_uverbs: Avoid vendor specific masking of attributes in query_qp

[Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

On Fri, 2016-09-02 at 11:10 -0600, Jason Gunthorpe wrote:
> On Fri, Sep 02, 2016 at 06:45:52AM +0200, Knut Omang wrote:
> > On Thu, 2016-09-01 at 20:13 -0600, Jason Gunthorpe wrote:
> > > On Fri, Sep 02, 2016 at 02:09:26AM +0200, Knut Omang wrote:
> > > > This commit removes the implementation and use of the modify_qp_mask
> > > > helper function from the generic OFED implementation and into individual
> > > > device drivers.
> > > > 
> > > > Like with use of the ib_modify_qp_is_ok function it should be up to
> > > > each device driver how to handle bits set in the attribute masks.
> > > > 
> > > > With the modify_qp_mask function applied in the generic code,
> > > > drivers would not see the bits that the user process actually sets.
> > > > 
> > > > The restrictions imposed by the filter are also beyond what
> > > > is imposed by the Infiniband standard, and would also limit
> > > > future drivers or hardware from checking for unsupported or
> > > > invalid settings.
> > > 
> > > I'm not excited about this direction. It is not OK for different
> > > drivers to use different mask algorithms, they must all behave the
> > > same.
> > 
> > The problem I am solving here is that SIF expects (and requires) some of 
> > the bits that the user correctly sets, but that Mellanox either ignore or need to
> > be 0. So when that mask is applied to the user input, the value that reaches
> > the SIF driver is not correct from SIFs perspective. 
> > If the values goes through as the ULP sets them, then all is fine.
> 
> I guess I still don't understand. SIF and mlx cannot have different
> behavior here. 

Rest assure, being the new kid on the block here, of course we need to 
work with existing applications. We try to test with whatever we can get our 
hands on, and make sure we behave sensibly..

> How is the application writer to know what to do?

This masking applies to XRC only.
The application does not need to do anything, it treats the XRC QP as any other
RC QP and attempt similar modify_qp operations.
Mlx chooses to ignore some of the bits provided. 

> Can you give a concrete example of the problem?

Maybe someone from Mellanox can explain the reason 
for having the filtering there in the first place,
and only from user mode XRC QPs?

Knut

> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html