On 27/03/2018 17:32, Jason Gunthorpe wrote:
On Tue, Mar 27, 2018 at 11:25:38AM +0300, Matan Barak wrote:
On 27/03/2018 05:05, Jason Gunthorpe wrote:
On Tue, Mar 20, 2018 at 03:01:41PM +0200, Leon Romanovsky wrote:
+#include <rdma/ib_user_ioctl_cmds.h>
+
+enum mlx5_ib_create_flow_action_attrs {
+ /* This attribute belong to the driver namespace */
+ MLX5_IB_ATTR_CREATE_FLOW_ACTION_FLAGS = (1U << UVERBS_ID_NS_SHIFT),
+};
This overlaps with UVERBS_ATTR_UHW_IN, so no.. There is special global
support for UVERBS_ATTR_UHW_IN/OUT meaning those attribute ID numbers
should not be re-used.
Instead we need to add a constant
UVERBS_ATTR_DRV_START = UVERBS_ATTR_UHW_OUT+1
and use that..
I think UVERBS_ATTR_UHW_IN and UVERBS_ATTR_UHW_OUT attributes should be
reserved for methods that were migrated from the write() to ioctl()
infrastructure. I don't see any valid reason to reserve them for ioctl()
only commands or for new provider driver methods.
The UHW attributes are the only ones that the core stuff in rdma-core
understands specially. I think those are all on callpaths that are
supposed to be guarded only for legacy things, but it sure seems
to make things confusing to have them get re-used.
I see that as a layered approach. The write() comparability layer is
above the basic ioctl() layer (this also fit both the kernel's and the
user-space structure). Therefore, I think that for methods that are
implemented straight above the ioctl() layer, we don't need to reserve
these attributes. These new methods won't go through the write()
compatibility in user-space or kernel.
Jason
Matan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
