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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2016-09-02 at 19:35 +0200, Knut Omang wrote:
> 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?

Getting some help from git blame here: 

The modify_qp_mask function was introduced by this commit: 
9977f4f64bfeb5d907a793a6880aab2d43b0bed2 by Sean Hefty.

Can I ask why this function was introduced, and if it is still needed?

Thanks,
Knut

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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux