-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hmem: Define ofi_hmem_put_dmabuf_fd #10716
Changes from all commits
e540e80
7c74473
c93c257
50d7a22
d1e73d0
fb19b96
d28282f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,10 @@ static int cxip_dmabuf_hints(enum fi_hmem_iface iface, void *iov_base, | |
hints->dmabuf_offset = offset; | ||
hints->dmabuf_valid = true; | ||
|
||
/* Need to cache DMA buf FD to release later. */ | ||
md->dmabuf_fd = dmabuf_fd; | ||
md->dmabuf_fd_valid = true; | ||
|
||
return FI_SUCCESS; | ||
} | ||
|
||
|
@@ -106,7 +110,7 @@ static int cxip_do_map(struct ofi_mr_cache *cache, struct ofi_mr_entry *entry) | |
CXIP_WARN(MAP_FAIL_MSG, dom->lni->lni->id, | ||
entry->info.iov.iov_base, entry->info.iov.iov_len, | ||
map_flags, ret, fi_strerror(-ret)); | ||
goto err; | ||
goto err_free_dmabuf; | ||
} | ||
|
||
/* If the md len is larger than the iov_len, the VA and len have | ||
|
@@ -161,6 +165,9 @@ static int cxip_do_map(struct ofi_mr_cache *cache, struct ofi_mr_entry *entry) | |
|
||
err_unmap: | ||
cxil_unmap(md->md); | ||
err_free_dmabuf: | ||
if (md->dmabuf_fd_valid) | ||
ofi_hmem_put_dmabuf_fd(entry->info.iface, md->dmabuf_fd); | ||
err: | ||
md->dom = NULL; | ||
return ret; | ||
|
@@ -181,6 +188,9 @@ static void cxip_do_unmap(struct ofi_mr_cache *cache, | |
if (md->handle_valid) | ||
ofi_hmem_dev_unregister(entry->info.iface, md->handle); | ||
|
||
if (md->dmabuf_fd_valid) | ||
ofi_hmem_put_dmabuf_fd(entry->info.iface, md->dmabuf_fd); | ||
|
||
ret = cxil_unmap(md->md); | ||
if (ret) | ||
CXIP_WARN("cxil_unmap failed: %d\n", ret); | ||
|
@@ -426,7 +436,7 @@ static int cxip_map_nocache(struct cxip_domain *dom, struct fi_mr_attr *attr, | |
&uncached_md->md); | ||
if (ret) { | ||
CXIP_WARN("cxil_map failed: %d:%s\n", ret, fi_strerror(-ret)); | ||
goto err_free_uncached_md; | ||
goto err_free_dmabuf; | ||
} | ||
|
||
/* zeHostMalloc() returns FI_HMEM_ZE but this cannot currently be | ||
|
@@ -466,8 +476,12 @@ static int cxip_map_nocache(struct cxip_domain *dom, struct fi_mr_attr *attr, | |
|
||
return FI_SUCCESS; | ||
|
||
|
||
err_unmap: | ||
cxil_unmap(uncached_md->md); | ||
err_free_dmabuf: | ||
if (uncached_md->dmabuf_fd_valid) | ||
ofi_hmem_put_dmabuf_fd(attr->iface, uncached_md->dmabuf_fd); | ||
err_free_uncached_md: | ||
free(uncached_md); | ||
|
||
|
@@ -575,6 +589,9 @@ static void cxip_unmap_nocache(struct cxip_md *md) | |
{ | ||
int ret; | ||
|
||
if (md->dmabuf_fd_valid) | ||
ofi_hmem_put_dmabuf_fd(md->info.iface, md->dmabuf_fd); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd be curious to know why cxi requires that the close of the dmabuf is deferred until point of unmapping it? Why can't you just close it immediately after you do the map? I thought this was a property of the dmabuf kernel interface and not something that would be different between providers, but I don't know this code well and might be missing something. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I assume the kernel driver would reference count properly so that closing right after mapping should work just fine. I don't see the drawback of doing either way. |
||
|
||
if (md->handle_valid) | ||
ofi_hmem_dev_unregister(md->info.iface, md->handle); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just name it as
close_dmabuf_fd
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose put_dmabuf_fd to semantically align with get_dmabuf_fd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any hmem type where a
get_dmabuf_fd
does not implicitly increase the open count on the file? if not, I'd recommend going the other way and renamingget
toopen
so that it's clear that it's not simply resolving an already-open file descriptor, but is actually opening a resource which must be eventually closed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the ZE hmem type always return the same fd.