On Tue, Mar 23, 2010 at 10:55:08PM -0700, Roland Dreier wrote: > > I would prefer to do this by adding a new verbs call that returns a fd > > directly. Ie use ib_uverbs_alloc_event_file and act like > > ibv_create_comp_channel. > > > > The main reason for the new FD is so it can be polled on.. > > Agree, we don't want a new device node I don't think -- too hard to > associate an fd you get from a separate open() with a uverbs context.
Right, that would suck.. > > You can also avoid the mmap scheme by doing what perf events does, > > pass in a pointer from userspace and have the kernel pin that page it > > is on. > > I wonder, is that a win? I guess you don't even have to pin it, just do > copy_to_user() to update the counter, but mmap doesn't seem so bad. Not sure you can call copy_to_user from a mmu_notifier callback? What if it faults? I think the idea would be that by letting user space select the counter location it could place it in a sensible cachline/etc and probably avoid a pointer indirection. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
