From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Bart Van Assche <bvanassche@acm.org>,
Ariel Elior <aelior@marvell.com>,
Anna Schumaker <anna@kernel.org>, Jens Axboe <axboe@fb.com>,
Christian Benvenuti <benve@cisco.com>,
Potnuri Bharat Teja <bharat@chelsio.com>,
Bernard Metzler <bmt@zurich.ibm.com>,
Chuck Lever <chuck.lever@oracle.com>,
"David S. Miller" <davem@davemloft.net>,
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
Christoph Hellwig <hch@lst.de>, Keith Busch <kbusch@kernel.org>,
Chaitanya Kulkarni <kch@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>,
Michal Kalderon <mkalderon@marvell.com>,
Mustafa Ismail <mustafa.ismail@intel.com>,
Nelson Escobar <neescoba@cisco.com>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
rds-devel@oss.oracle.com, Sagi Grimberg <sagi@grimberg.me>,
samba-technical@lists.samba.org,
Santosh Shilimkar <santosh.shilimkar@oracle.com>,
Selvin Xavier <selvin.xavier@broadcom.com>,
Steve French <sfrench@samba.org>,
Shiraz Saleem <shiraz.saleem@intel.com>,
target-devel@vger.kernel.org,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Yishai Hadas <yishaih@nvidia.com>,
Zhu Yanjun <zyjzyj2000@gmail.com>
Subject: Re: [PATCH v2] RDMA: Split kernel-only global device caps from uverbs device caps
Date: Thu, 7 Apr 2022 19:10:12 +0300 [thread overview]
Message-ID: <Yk8M5C/7YO7F9sk2@unreal> (raw)
In-Reply-To: <20220407155244.GP2120790@nvidia.com>
On Thu, Apr 07, 2022 at 12:52:44PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 06, 2022 at 12:57:31PM -0700, Bart Van Assche wrote:
> > On 4/6/22 12:27, Jason Gunthorpe wrote:
> > > +enum ib_kernel_cap_flags {
> > > + /*
> > > + * This device supports a per-device lkey or stag that can be
> > > + * used without performing a memory registration for the local
> > > + * memory. Note that ULPs should never check this flag, but
> > > + * instead of use the local_dma_lkey flag in the ib_pd structure,
> > > + * which will always contain a usable lkey.
> > > + */
> > > + IBK_LOCAL_DMA_LKEY = 1 << 0,
> > > + /* IB_QP_CREATE_INTEGRITY_EN is supported to implement T10-PI */
> > > + IBK_INTEGRITY_HANDOVER = 1 << 1,
> > > + /* IB_ACCESS_ON_DEMAND is supported during reg_user_mr() */
> > > + IBK_ON_DEMAND_PAGING = 1 << 2,
> > > + /* IB_MR_TYPE_SG_GAPS is supported */
> > > + IBK_SG_GAPS_REG = 1 << 3,
> > > + /* Driver supports RDMA_NLDEV_CMD_DELLINK */
> > > + IBK_ALLOW_USER_UNREG = 1 << 4,
> > > +
> > > + /* ipoib will use IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK */
> > > + IBK_BLOCK_MULTICAST_LOOPBACK = 1 << 5,
> > > + /* iopib will use IB_QP_CREATE_IPOIB_UD_LSO for its QPs */
> > > + IBK_UD_TSO = 1 << 6,
> > > + /* iopib will use the device ops:
> > > + * get_vf_config
> > > + * get_vf_guid
> > > + * get_vf_stats
> > > + * set_vf_guid
> > > + * set_vf_link_state
> > > + */
> > > + IBK_VIRTUAL_FUNCTION = 1 << 7,
> > > + /* ipoib will use IB_QP_CREATE_NETDEV_USE for its QPs */
> > > + IBK_RDMA_NETDEV_OPA = 1 << 8,
> > > +};
> >
> > Has it been considered to use the kernel-doc syntax? This means moving all
> > comments above "enum ib_kernel_cap_flags {".
>
> TBH I'm not a huge fan of kdoc for how wordy it is:
>
> /** @IBK_RDMA_NETDEV_OPA: ipoib will use IB_QP_CREATE_NETDEV_USE for its QPs */
> IBK_RDMA_NETDEV_OPA = 1 << 8,
>
> Is the shortest format and still a bit awkward.
>
> Given that we don't have a proper kdoc for rdma I haven't been putting
> much energy there.
>
> If someone came with patches to make a kdoc chapter and start to
> organize it nicely I could see enforcing kdoc format..
Do you see any value in kdoc?
I personally didn't find it useful for kernel at all.
>
> Jason
next prev parent reply other threads:[~2022-04-07 16:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 19:27 [PATCH v2] RDMA: Split kernel-only global device caps from uverbs device caps Jason Gunthorpe
2022-04-06 19:57 ` Bart Van Assche
2022-04-07 15:52 ` Jason Gunthorpe
2022-04-07 16:10 ` Leon Romanovsky [this message]
2022-04-07 16:28 ` Jason Gunthorpe
2022-04-06 21:01 ` Max Gurtovoy
2022-04-06 21:54 ` Jason Gunthorpe
2022-04-07 7:09 ` Max Gurtovoy
2022-04-07 15:49 ` Jason Gunthorpe
2022-04-07 5:37 ` Christoph Hellwig
2022-04-08 16:45 ` Jason Gunthorpe
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=Yk8M5C/7YO7F9sk2@unreal \
--to=leon@kernel.org \
--cc=aelior@marvell.com \
--cc=anna@kernel.org \
--cc=axboe@fb.com \
--cc=benve@cisco.com \
--cc=bharat@chelsio.com \
--cc=bmt@zurich.ibm.com \
--cc=bvanassche@acm.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=dennis.dalessandro@cornelisnetworks.com \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mgurtovoy@nvidia.com \
--cc=mike.marciniszyn@cornelisnetworks.com \
--cc=mkalderon@marvell.com \
--cc=mustafa.ismail@intel.com \
--cc=neescoba@cisco.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rds-devel@oss.oracle.com \
--cc=sagi@grimberg.me \
--cc=samba-technical@lists.samba.org \
--cc=santosh.shilimkar@oracle.com \
--cc=selvin.xavier@broadcom.com \
--cc=sfrench@samba.org \
--cc=shiraz.saleem@intel.com \
--cc=target-devel@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
--cc=yishaih@nvidia.com \
--cc=zyjzyj2000@gmail.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;
as well as URLs for NNTP newsgroup(s).