Keith Kraus

From my view I'm not viewing this as tacking this onto rmm because it's convenient, in fact it's a little bit inconvenient if anything. I view this as managing memory...

The `cudf._cuda` module has been moved to rmm so transferring issue.

Yes but low priority.

> The use of `byte_offset` for opaque data pointers is interesting. Do you suggest to also use it for non-opaque data pointers to enforce/allow a bigger allocation alignment guarantee then...

> I am still not sure if you would want to expect the importer to calculate both base and non-base pointer alignment? I would assume that allocations are aligned, which...

> Ah, so `padding` means actually means "you are allowed to write over that data?" and not just "you can safely read more?". Ideally, yes. I imagine the read side...

If we're making longer term changes surrounding optional alignment in A3, it would be nice to have optional padding as well so that we know how many bytes past `data...

The docs weren't clear to me, but I didn't interpret those as singletons and instead thought that it was just guidance on what data types need to be supported by...

So for some additional context (pun intended!) cuDF doesn't create a CUDA context on import, but we do initialize the CUDA Driver API which seems to cache the value of...

> Yes, cuDF is. We actually aren't creating a CUDA context, but we are initializing the driver which caches the device enumeration from `CUDA_VISIBLE_DEVICES`. May I suggest we hop on...