On Tue, Jun 16, 2020 at 08:44:37PM +0300, Gal Pressman wrote: > On 16/06/2020 12:38, Leon Romanovsky wrote: > > On Tue, Jun 16, 2020 at 11:53:11AM +0300, Gal Pressman wrote: > >> On 16/06/2020 9:30, Leon Romanovsky wrote: > >>> On Mon, Jun 15, 2020 at 10:59:20AM +0300, Gal Pressman wrote: > >>>> Provider specific attributes which are necessary for the userspace > >>>> functionality should be part of the alloc ucontext response, not query > >>>> device. This way a userspace provider could work without issuing a query > >>>> device verb call. However, the fields will remain in the query device > >>>> ABI in order to maintain backwards compatibility. > >>> > >>> I don't really understand why "should be ..."? Device properties exposed > >>> here are per-device and will be equal to all ucontexts, so instead of > >>> doing one very fast system call, you are "punishing" every ucontext > >>> call. > >> > >> I talked about it with Jason in the past, the query device verb is intended to > >> follow the IBA verb, alloc ucontext should return driver specific data that's > >> required to operate the user space provider. > >> A query device call should not be mandatory to load the provider. > > > > Why? query_device is declared as mandatory verb for any provider, so > > anyway all in-the-tree RDMA drivers will have such verb. > > I don't think the concern here is if the verb exists or not, my understanding is > that query device should be used for IBA query device attributes, not other > provider specific stuff. > Jason, want to chime in with your thoughts? I would like to hear it too. Almost all (if not all) extended verbs support providing vendor specific data in a response. Why should query_device() be different here? > > >> Whether it's done through query device/ucontext response, both happen for each > >> new context call. With this patch, we gather all needed data in one system call > >> instead of two. > > > > Is it important in control path to have one call? > > Not a huge difference, better one than two though. My problem here is duplication of functionality and data. > > >>> What is wrong with calling one query_device before allocating any > >>> ucontext? What are you trying to achieve and what will it give? > >> > >> How can you call query device without allocating a context? > > > > Forget about my comment above, it was my over-thinking. > > > > I had in mind some scheme that first ucontext will cache the all device > > related data and share it with other ucontexts. > > > > Thanks > >
