From: Jason Gunthorpe <jgg@ziepe.ca>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
Yishai Hadas <yishaih@mellanox.com>,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next v1 06/10] IB/uverbs: Move QP, SRQ, WQ type and flags to UAPI
Date: Sun, 17 May 2020 19:57:47 -0300 [thread overview]
Message-ID: <20200517225747.GA31510@ziepe.ca> (raw)
In-Reply-To: <20200506082444.14502-7-leon@kernel.org>
On Wed, May 06, 2020 at 11:24:40AM +0300, Leon Romanovsky wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> These constants are going to be used in the ioctl interface in coming
> patches so they are part of the UAPI, place them in the correct header
> for clarity.
>
> Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> include/rdma/ib_verbs.h | 43 ++++++++++++++-----------
> include/uapi/rdma/ib_user_ioctl_verbs.h | 34 +++++++++++++++++++
> 2 files changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index b8b5b5310529..9cf2d9d05c06 100644
> +++ b/include/rdma/ib_verbs.h
> @@ -1012,9 +1012,9 @@ enum ib_cq_notify_flags {
> };
>
> enum ib_srq_type {
> - IB_SRQT_BASIC,
> - IB_SRQT_XRC,
> - IB_SRQT_TM,
> + IB_SRQT_BASIC = IB_UVERBS_SRQT_BASIC,
> + IB_SRQT_XRC = IB_UVERBS_SRQT_XRC,
> + IB_SRQT_TM = IB_UVERBS_SRQT_TM,
> };
>
> static inline bool ib_srq_has_cq(enum ib_srq_type srq_type)
> @@ -1083,16 +1083,16 @@ enum ib_qp_type {
> IB_QPT_SMI,
> IB_QPT_GSI,
>
> - IB_QPT_RC,
> - IB_QPT_UC,
> - IB_QPT_UD,
> + IB_QPT_RC = IB_UVERBS_QPT_RC,
> + IB_QPT_UC = IB_UVERBS_QPT_UC,
> + IB_QPT_UD = IB_UVERBS_QPT_UD,
> IB_QPT_RAW_IPV6,
> IB_QPT_RAW_ETHERTYPE,
> - IB_QPT_RAW_PACKET = 8,
> - IB_QPT_XRC_INI = 9,
> - IB_QPT_XRC_TGT,
> + IB_QPT_RAW_PACKET = IB_UVERBS_QPT_RAW_PACKET,
> + IB_QPT_XRC_INI = IB_UVERBS_QPT_XRC_INI,
> + IB_QPT_XRC_TGT = IB_UVERBS_QPT_XRC_TGT,
> IB_QPT_MAX,
> - IB_QPT_DRIVER = 0xFF,
> + IB_QPT_DRIVER = IB_UVERBS_QPT_DRIVER,
> /* Reserve a range for qp types internal to the low level driver.
> * These qp types will not be visible at the IB core layer, so the
> * IB_QPT_MAX usages should not be affected in the core layer
> @@ -1111,17 +1111,21 @@ enum ib_qp_type {
>
> enum ib_qp_create_flags {
> IB_QP_CREATE_IPOIB_UD_LSO = 1 << 0,
> - IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK = 1 << 1,
> + IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK =
> + IB_UVERBS_QP_CREATE_BLOCK_MULTICAST_LOOPBACK,
> IB_QP_CREATE_CROSS_CHANNEL = 1 << 2,
> IB_QP_CREATE_MANAGED_SEND = 1 << 3,
> IB_QP_CREATE_MANAGED_RECV = 1 << 4,
> IB_QP_CREATE_NETIF_QP = 1 << 5,
> IB_QP_CREATE_INTEGRITY_EN = 1 << 6,
> /* FREE = 1 << 7, */
> - IB_QP_CREATE_SCATTER_FCS = 1 << 8,
> - IB_QP_CREATE_CVLAN_STRIPPING = 1 << 9,
> + IB_QP_CREATE_SCATTER_FCS =
> + IB_UVERBS_QP_CREATE_SCATTER_FCS,
> + IB_QP_CREATE_CVLAN_STRIPPING =
> + IB_UVERBS_QP_CREATE_CVLAN_STRIPPING,
> IB_QP_CREATE_SOURCE_QPN = 1 << 10,
> - IB_QP_CREATE_PCI_WRITE_END_PADDING = 1 << 11,
> + IB_QP_CREATE_PCI_WRITE_END_PADDING =
> + IB_UVERBS_QP_CREATE_PCI_WRITE_END_PADDING,
> /* reserve bits 26-31 for low level drivers' internal use */
> IB_QP_CREATE_RESERVED_START = 1 << 26,
> IB_QP_CREATE_RESERVED_END = 1 << 31,
> @@ -1626,7 +1630,7 @@ enum ib_raw_packet_caps {
> };
>
> enum ib_wq_type {
> - IB_WQT_RQ
> + IB_WQT_RQ = IB_UVERBS_WQT_RQ,
> };
>
> enum ib_wq_state {
> @@ -1649,10 +1653,11 @@ struct ib_wq {
> };
>
> enum ib_wq_flags {
> - IB_WQ_FLAGS_CVLAN_STRIPPING = 1 << 0,
> - IB_WQ_FLAGS_SCATTER_FCS = 1 << 1,
> - IB_WQ_FLAGS_DELAY_DROP = 1 << 2,
> - IB_WQ_FLAGS_PCI_WRITE_END_PADDING = 1 << 3,
> + IB_WQ_FLAGS_CVLAN_STRIPPING = IB_UVERBS_WQ_FLAGS_CVLAN_STRIPPING,
> + IB_WQ_FLAGS_SCATTER_FCS = IB_UVERBS_WQ_FLAGS_SCATTER_FCS,
> + IB_WQ_FLAGS_DELAY_DROP = IB_UVERBS_WQ_FLAGS_DELAY_DROP,
> + IB_WQ_FLAGS_PCI_WRITE_END_PADDING =
> + IB_UVERBS_WQ_FLAGS_PCI_WRITE_END_PADDING,
For flags that are not used by kernel ULPs, like these, it makes more
sense to have the driver refer to the IB_UVERBS_* constant and remove
this stuff from the ULP facing header. Probably as individual patches
Same above from the create flags I suppose
Jason
next prev parent reply other threads:[~2020-05-17 22:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 8:24 [PATCH rdma-next v1 00/10] Enable asynchronous event FD per object Leon Romanovsky
2020-05-06 8:24 ` [PATCH rdma-next v1 01/10] RDMA/core: Allow the ioctl layer to abort a fully created uobject Leon Romanovsky
2020-05-06 8:24 ` [PATCH rdma-next v1 02/10] IB/uverbs: Refactor related objects to use their own asynchronous event FD Leon Romanovsky
2020-05-17 22:52 ` Jason Gunthorpe
2020-05-06 8:24 ` [PATCH rdma-next v1 03/10] IB/uverbs: Extend CQ to get its " Leon Romanovsky
2020-05-17 22:53 ` Jason Gunthorpe
2020-05-06 8:24 ` [PATCH rdma-next v1 04/10] IB/uverbs: Cleanup wq/srq context usage from uverbs layer Leon Romanovsky
2020-05-06 8:24 ` [PATCH rdma-next v1 05/10] RDMA/core: Consolidate ib_create_srq flows Leon Romanovsky
2020-05-06 8:24 ` [PATCH rdma-next v1 06/10] IB/uverbs: Move QP, SRQ, WQ type and flags to UAPI Leon Romanovsky
2020-05-17 22:57 ` Jason Gunthorpe [this message]
2020-05-06 8:24 ` [PATCH rdma-next v1 07/10] IB/uverbs: Introduce create/destroy SRQ commands over ioctl Leon Romanovsky
2020-05-17 23:04 ` Jason Gunthorpe
2020-05-06 8:24 ` [PATCH rdma-next v1 08/10] IB/uverbs: Fix create WQ to use the given user handle Leon Romanovsky
2020-05-06 8:24 ` [PATCH rdma-next v1 09/10] IB/uverbs: Introduce create/destroy WQ commands over ioctl Leon Romanovsky
2020-05-17 23:09 ` Jason Gunthorpe
2020-05-06 8:24 ` [PATCH rdma-next v1 10/10] IB/uverbs: Introduce create/destroy QP " Leon Romanovsky
2020-05-17 23:37 ` [PATCH rdma-next v1 00/10] Enable asynchronous event FD per object Jason Gunthorpe
2020-05-18 6:17 ` Leon Romanovsky
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=20200517225747.GA31510@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dledford@redhat.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=yishaih@mellanox.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).