On Fri, Aug 03, 2018 at 01:31:35PM -0600, Jason Gunthorpe wrote:
> From: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
>
> This radix tree datastructure is intended to replace the 'hash' structure
> used today for parsing ioctl methods during system calls. This first
> commit introduces the structure and builds it from the existing .rodata
> descriptions.
>
> The so-called hash arrangement is actually a 5 level open coded radix tree.
> This new version uses a 3 level radix tree built using the radix tree
> library.
>
> Overall this is much less code and much easier to build as the radix tree
> API allows for dynamic modification during the building. There is a small
> memory penalty to pay for this, but since the radix tree is allocated on
> a per device basis, a few kb of RAM seems immaterial considering the
> gained simplicity.
>
> The radix tree is similar to the existing tree, but also has a 'attr_bkey'
> concept, which is a small value'd index for each method attribute. This is
> used to simplify and improve performance of everything in the next
> patches.
>
> Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
> ---
> drivers/infiniband/core/Makefile | 3 +-
> drivers/infiniband/core/rdma_core.h | 50 ++++
> drivers/infiniband/core/uverbs.h | 1 +
> drivers/infiniband/core/uverbs_main.c | 14 +-
> drivers/infiniband/core/uverbs_uapi.c | 350 ++++++++++++++++++++++++++
> include/rdma/uverbs_ioctl.h | 137 ++++++++++
> 6 files changed, 552 insertions(+), 3 deletions(-)
> create mode 100644 drivers/infiniband/core/uverbs_uapi.c
>
<...>
> +static inline __attribute_const__ u32 uapi_key_attrs_start(u32 ioctl_method_key)
> +{
> + /* 0 is the method slot itself */
> + return ioctl_method_key + 1;
> +}
<...>
> +/*
> + * This returns a value in the range [0 to UVERBS_API_ATTR_BKEY_LEN),
> + * basically it undoes the reservation of 0 in the ID numbering. attr_key
> + * must already be masked with UVERBS_API_ATTR_KEY_MASK, or be the output of
> + * uapi_key_attr().
> + */
> +static inline __attribute_const__ u32 uapi_bkey_attr(u32 attr_key)
> +{
> + return attr_key - 1;
> +}
It is very unclear that attr_key starts from 1 and not from 0.
Other than that, I have no clue how this patch can be properly reviewed.
Thanks
Attachment:
signature.asc
Description: PGP signature
