That leaves a problem when the same memory region is registered with different vendors. Verbs A marks the area, Verbs B sees that is already marked, Verbs A unmarks the area when it is done not knowing that B is relying on the memory staying pinned.
I do not believe there is a solution to this problem when working at arms length from Linux other than documenting the problem and informing applications of workarounds required when using multiple vendors concurrently with the same memory (i.e, destroy the most recently created memory region first, or pin the memory yourself before creating the first memory region). The only other alternative is to make the pinning some sort of shared service that would apply across multiple vendors. That is doable, but might not be worthwhile given that a single process using multiple vendor devices concurrently is decidely the exception. But those users deserve at least a warning. On 4/25/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > Caitlin> Who is responsible for counting within a process, and > Caitlin> then between processes (in case shared memory is being > Caitlin> registered)? The application? Middleware? Driver? > > The verbs code doing the registration should do it as part of the > registration. Shared memory does not cause any additional issues > because it is mapped into the virtual memory map of each process and > must be marked VM_DONTCOPY in each process separately. > > - R. > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
