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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.