Message-ID: <20180917200702.GT3661@mtr-leonro.mtl.com>
Date:   Mon, 17 Sep 2018 23:07:02 +0300
From:   Leon Romanovsky <leonro@...lanox.com>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...lanox.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        Yishai Hadas <yishaih@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH rdma-next 00/24] Extend DEVX functionality

On Mon, Sep 17, 2018 at 10:51:29PM +0300, Or Gerlitz wrote:
> On Mon, Sep 17, 2018 at 10:34 PM, Leon Romanovsky <leonro@...lanox.com> wrote:
> > On Mon, Sep 17, 2018 at 02:03:53PM +0300, Leon Romanovsky wrote:
> >> From: Leon Romanovsky <leonro@...lanox.com>
> >>
> >> From Yishai,
> >>
> >> This series comes to enable the DEVX functionality in some wider scope,
> >> specifically,
> >> - It enables using kernel objects that were created by the verbs
> >>   API in the DEVX flow.
> >> - It enables white list commands without DEVX user context.
> >> - It enables the IB link layer under CAP_NET_RAW capabilities.
> >> - It exposes the PRM handles for RAW QP (i.e. TIRN, TISN, RQN, SQN)
> >>   to be used later on directly by the DEVX interface.
> >>
> >> In General,
> >> Each object that is created/destroyed/modified via verbs will be stamped
> >> with a UID based on its user context. This is already done for DEVX objects
> >> commands.
> >>
> >> This will enable the firmware to enforce the usage of kernel objects
> >> from the DEVX flow by validating that the same UID is used and the resources are
> >> really related to the same user.
> >>
> >> For example in case a CQ was created with verbs it will be stamped with
> >> UID and once will be pointed by a DEVX create QP command the firmware will
> >> validate that the input CQN really belongs to the UID which issues the create QP
> >> command.
> >>
> >> As of the above, all the PRM objects (except of the public ones which
> >> are managed by the kernel e.g. FLOW, etc.) will have a UID upon their
> >> create/modify/destroy commands. The detection of UMEM / physical
> >> addressed in the relevant commands will be done by firmware according to a 'umem
> >> valid bit' as the UID may be used in both cases.
> >>
> >> The series also enables white list commands which don't require a
> >> specific DEVX context, instead of this a device UID is used so that
> >> the firmware will mask un-privileged functionality. The IB link layer
> >> is also enabled once CAP_NET_RAW permission exists.
> >>
> >> To enable using the RAW QP underlay objects (e.g. TIRN, RQN, etc.) later
> >> on by DEVX commands the UHW output for this case was extended to return this
> >> data when a DEVX context is used.
> >>
> >> Thanks
> >>
> >> Leon Romanovsky (1):
> >>   net/mlx5: Update mlx5_ifc with DEVX UID bits
> >>
> >> Yishai Hadas (24):
> >>   net/mlx5: Set uid as part of CQ commands
> >>   net/mlx5: Set uid as part of QP commands
> >>   net/mlx5: Set uid as part of RQ commands
> >>   net/mlx5: Set uid as part of SQ commands
> >>   net/mlx5: Set uid as part of SRQ commands
> >>   net/mlx5: Set uid as part of DCT commands
> >
> > Hi Doug and Jason,
> >
> > Do you want me to resend 7 patches above in one series and other patches
> > in another series just to be below 15 patches limit? Please be aware
> > that those patches above are going to mlx5-next and not to
> > net-next/rdma-next.
> >
> > No rebase, no code change, no much meaning too, but it is your call.
>
> how about yes! for stop shitting on Dave Miller?

Or, are you ok?

This series is not relevant to Dave Miller and he didn't even listed in CC or TO.

I still prefer to hear answer from respective maintainer to whom this
series was sent.

Thanks

Powered by blists - more mailing lists