Re: [PATCH v1 ib-next 2/3] IB/core: IB/core: Allow legacy verbs through extended interfaces
On Tue, Nov 10, 2015 at 08:00:09PM +0200, Eli Cohen wrote: > When an extended verbs is an extension to a legacy verb, the original > functionality is preserved. Hence we do not require each hardware driver > to set the extended capability. This will allow to use the extended verb > in its simple form with drivers that do not support the extended > capability. Can we please get rid of uverbs_cmd_mask and uverbs_ex_cmd_mask ? The driver should set the function pointers it does not support to NULL. We don't need the bitmask because we already know the answer. For performance, I recommend having the core replace the NULL op pointers from the driver with a stub that returns ENOTSUP, and then drop all the checking in the fast path. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 ib-next 2/3] IB/core: IB/core: Allow legacy verbs through extended interfaces
On Tue, Nov 10, 2015 at 09:57:13PM +0200, Eli Cohen wrote: > Yes, we can do this but I think this should be the subject for another > patch, agree? Sure > Regarding using stabs, it may be nice but I don't think performance is > the issue here. Most verbs implementations involve relatively long i/o > operations anyway so the gain will not be noticable. Intel keeps optimizing this common path since they use it for post.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 ib-next 2/3] IB/core: IB/core: Allow legacy verbs through extended interfaces
On Tue, Nov 10, 2015 at 11:21:07AM -0700, Jason Gunthorpe wrote: > On Tue, Nov 10, 2015 at 08:00:09PM +0200, Eli Cohen wrote: > > When an extended verbs is an extension to a legacy verb, the original > > functionality is preserved. Hence we do not require each hardware driver > > to set the extended capability. This will allow to use the extended verb > > in its simple form with drivers that do not support the extended > > capability. > > Can we please get rid of uverbs_cmd_mask and uverbs_ex_cmd_mask ? > > The driver should set the function pointers it does not support to > NULL. We don't need the bitmask because we already know the answer. > > For performance, I recommend having the core replace the NULL op > pointers from the driver with a stub that returns ENOTSUP, and then > drop all the checking in the fast path. > Yes, we can do this but I think this should be the subject for another patch, agree? Regarding using stabs, it may be nice but I don't think performance is the issue here. Most verbs implementations involve relatively long i/o operations anyway so the gain will not be noticable. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
