From: Yuval Shaia <yuval.shaia@oracle.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>,
linux-rdma@vger.kernel.org, leon@kernel.org,
Santosh Shilimkar <santosh.shilimkar@oracle.com>
Subject: Re: [RFC rdma-core] verbs: add ibv_export_to_fd man page
Date: Thu, 4 Jul 2019 16:41:38 +0300 [thread overview]
Message-ID: <20190704134136.GA5711@lap1> (raw)
In-Reply-To: <20190702224807.GE11860@ziepe.ca>
On Tue, Jul 02, 2019 at 07:48:07PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 26, 2019 at 03:46:39PM +0300, Yuval Shaia wrote:
> > On Wed, Jun 26, 2019 at 11:36:14AM +0300, Shamir Rabinovitch wrote:
> > > Add the ibv_export_to_fd man page.
> >
> > This is RFC but still suggesting to give some words here.
> >
> > Also, subject is incorrect since man page is for all functions involved in
> > the shared-obj mechanism, not only the export_to_fd.
> >
> > >
> > > Signed-off-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
> > > libibverbs/man/ibv_export_to_fd.3.md | 109 +++++++++++++++++++++++++++
> > > 1 file changed, 109 insertions(+)
> > > create mode 100644 libibverbs/man/ibv_export_to_fd.3.md
> > >
> > > diff --git a/libibverbs/man/ibv_export_to_fd.3.md b/libibverbs/man/ibv_export_to_fd.3.md
> > > new file mode 100644
> > > index 00000000..8e3f0fb2
> > > +++ b/libibverbs/man/ibv_export_to_fd.3.md
> > > @@ -0,0 +1,109 @@
> > > +---
> > > +date: 2018-06-26
> > > +footer: libibverbs
> > > +header: "Libibverbs Programmer's Manual"
> > > +layout: page
> > > +license: 'Licensed under the OpenIB.org BSD license (FreeBSD Variant) - See COPYING.md'
> > > +section: 3
> > > +title: ibv_export_to_fd
> > > +tagline: Verbs
> > > +---
> > > +
> > > +# NAME
> > > +
> > > +**ibv_export_to_fd**, **ibv_import_pd**, **ibv_import_mr** - export & import ib hw objects.
> > > +
> > > +# SYNOPSIS
> > > +
> > > +```c
> > > +#include <infiniband/verbs.h>
> > > +
> > > +int ibv_export_to_fd(uint32_t fd,
> > > + uint32_t *new_handle,
> > > + struct ibv_context *context,
> > > + enum uverbs_default_objects type,
> > > + uint32_t handle);
>
> This should probably be some internal function and the exports should
> be type safe just like the imports.
So you suggesting something like this (instead of passing handle as arg):
int ibv_export_pd(uint32_t fd,
uint32_t *new_handle,
struct ibv_context *context,
struct ib_pd* pd);
int ibv_export_mr(uint32_t fd,
uint32_t *new_handle,
struct ibv_context *context,
struct ib_mr* mr);
So the handle is taken internally from the pd or mr arg.
Are you still ok with new_handle? asking as this is what is used in the
ibv_import_xxx functions.
>
> > > +struct ibv_pd *ibv_import_pd(struct ibv_context *context,
> > > + uint32_t fd,
> > > + uint32_t handle);
> > > +
> > > +struct ibv_mr *ibv_import_mr(struct ibv_context *context,
> > > + uint32_t fd,
> > > + uint32_t handle);
> > > +
> > > +uint32_t ibv_context_to_fd(struct ibv_context *context);
> > > +
> > > +uint32_t ibv_pd_to_handle(struct ibv_pd *pd);
> > > +
> > > +uint32_t ibv_mr_to_handle(struct ibv_mr *mr);
> >
> > Do you know if extra stuff besides this new file needs to be done so i can
> > do ex man ibv_context_to_fd and get this man page?
>
> Yes, they need to be setup in cmake with aliases.
Will take care of it, thanks.
>
> I think this man page is kind of terse for such a complicated
> thing.
>
> Ie it doesn't talk about what happens when close() or ibv_destroy_X()
> is called.
We've mentioned that the returned object is like a regular object returned
from (ex) ibv_create_pd and should be destroyed with the corresponding
destroy function.
We can add a note saying that the HW object will be destroyed only when all
reference to it will be destroyed.
Is that enough?
>
> Jason
parent reply other threads:[~2019-07-04 13:41 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20190702224807.GE11860@ziepe.ca>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190704134136.GA5711@lap1 \
--to=yuval.shaia@oracle.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=santosh.shilimkar@oracle.com \
--cc=shamir.rabinovitch@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox