Re: Ummunotify: progress at last!

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Mar 23, 2010 at 04:01:21PM -0400, Jeff Squyres wrote:
> On Mar 23, 2010, at 3:52 PM, Jason Gunthorpe wrote:
> 
> > > > ibv_set_mmu_counter(verbs, &my_counter);
> > > > ibv_get_mmu_notifications(verbs, &my_list, sizeof(my_list));
> > 
> > These are not hiding mmap/read, they are new uverbs 'syscalls' that
> > get the kernel to perform that operation.
> 
> Oh -- so there's 2 mechanisms to get the counter info (for example):
> 
> 1. the above uverb
> 2. mmap
> 
> Right?

No, there is no mmap. Like this:

u64 my_counter = 0;

ibv_set_mmu_counter(verbs, &my_counter);
[..]
while (my_counter != last_my_counter) {
    last_my_counter = my_counter;
    ibv_get_mmu_notifications(verbs, ...);   // <- I am a memory barrier as well
}

The kernel 'syscall' ibv_set_mmu_counter would bind the given verbs to
the 8 byte counter you specified without having to the mmap thing. As
I understand it this is what perfevents does.

Integrating with the verbs api avoids the need for another device
file. That is good. Eliminating poll() from the API can remove the
dedicated fd entirely. Within verbs I guess we could replace poll()
with something like a completion channel (??) if anyone cares.

So the user space visible functionality boils down to 2 new 'syscalls'
and the new flag to ibv_reg_mr.

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