Skip to content

Adding PinnedPoolProperties cython bindings#904

Open
nirandaperera wants to merge 3 commits intorapidsai:mainfrom
nirandaperera:pool_props_cython
Open

Adding PinnedPoolProperties cython bindings#904
nirandaperera wants to merge 3 commits intorapidsai:mainfrom
nirandaperera:pool_props_cython

Conversation

@nirandaperera
Copy link
Contributor

Minor PR that adds cython bindings for PinnedPoolProperties

Signed-off-by: niranda perera <niranda.perera@gmail.com>
Signed-off-by: niranda perera <niranda.perera@gmail.com>
@nirandaperera nirandaperera requested a review from a team as a code owner March 6, 2026 02:12
@nirandaperera nirandaperera added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels Mar 6, 2026
@wence-
Copy link
Contributor

wence- commented Mar 6, 2026

As per #851 (comment) I thought we were going to rework this pinned pool stuff to just use the cccl types directly. In which case, does this change not go in the wrong direction in the sense of being something that we immediately have to remove/rework?

@nirandaperera
Copy link
Contributor Author

As per #851 (comment) I thought we were going to rework this pinned pool stuff to just use the cccl types directly. In which case, does this change not go in the wrong direction in the sense of being something that we immediately have to remove/rework?

@wence- I only realized now that cccl does not expose memory pool API in cython. So, we might anyway have to manage a shim in our code. Is there a way around this?

Co-authored-by: Mads R. B. Kristensen <madsbk@gmail.com>
@madsbk
Copy link
Member

madsbk commented Mar 8, 2026

I don’t have a strong opinion, but I’m fine with us keeping both PinnedMemoryResource and HostMemoryResource until we’re sure CCCL provides everything we need.

@wence-
Copy link
Contributor

wence- commented Mar 9, 2026

As per #851 (comment) I thought we were going to rework this pinned pool stuff to just use the cccl types directly. In which case, does this change not go in the wrong direction in the sense of being something that we immediately have to remove/rework?

@wence- I only realized now that cccl does not expose memory pool API in cython. So, we might anyway have to manage a shim in our code. Is there a way around this?

CCCL doesn't provide any cython (or python) bindings for anything, and is not going to do so any time soon (if at all).

But. If we just store the pinned pool directly as a cuda::mr::any_resource and (in C++) use a cuda::pinned_memory_pool directly, then all of this polyfill will need to be changed again.

Given that our C++ PinnedMemoryPool was a temporary shim will cuda::pinned_memory_pool was in the experimental namespace in CCCL, and we've now all-but removed it anyway, it seems like it would make more sense to finish that migration on the C++ side and then figure out how to expose it in python. Rather than more polyfill that we will have to adapt.

What am I missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

improvement Improves an existing functionality non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants