Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 19 May 2022 09:49:00 -0300
From:   Jason Gunthorpe <jgg@ziepe.ca>
To:     Long Li <longli@microsoft.com>
Cc:     KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Leon Romanovsky <leon@kernel.org>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH 12/12] RDMA/mana_ib: Add a driver for Microsoft Azure
 Network Adapter
Message-ID: <20220519124900.GR63055@ziepe.ca>
References: <1652778276-2986-1-git-send-email-longli@linuxonhyperv.com>
 <1652778276-2986-13-git-send-email-longli@linuxonhyperv.com>
 <20220517152409.GJ63055@ziepe.ca>
 <PH7PR21MB326393A3D6BF619C2A7B4A42CED09@PH7PR21MB3263.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <PH7PR21MB326393A3D6BF619C2A7B4A42CED09@PH7PR21MB3263.namprd21.prod.outlook.com>
Precedence: bulk

On Thu, May 19, 2022 at 05:57:01AM +0000, Long Li wrote:

> > > +
> > > +	err = ib_copy_from_udata(&ucmd, udata, min(sizeof(ucmd),
> > > +udata->inlen));
> > 
> > Skeptical this min is correct, many other drivers get this wrong.
> 
> I think this is correct. This is to prevent user-mode passing more data that may overrun the kernel buffer.

And what happens when udata->inlen is, say, 0?
 
> > > +	// map to the page indexed by ucontext->doorbell
> > 
> > Not kernel style, be sure to run checkpatch and fix the egregious things.
> > 
> > > +static void mana_ib_disassociate_ucontext(struct ib_ucontext
> > > +*ibcontext) { }
> > 
> > Does this driver actually support disassociate? Don't define this function if it
> > doesn't.
> > 
> > I didn't see any mmap zapping so I guess it doesn't.
> 
> The user-mode deals with zapping.
> I see the following comments on rdma_umap_priv_init():
> 
> /* RDMA drivers supporting disassociation must have their user space designed
>  * to cope in some way with their IO pages going to the zero page. */
> 
> Is there any other additional work for the kernel driver to support
> disassociate? It seems uverbs_user_mmap_disassociate() has done all
> the zapping when destroying a ucontext.

Nope, that looks OK then
 
> I will open PR to rdma-core. The current version of the driver
> supports queue pair type IB_QPT_RAW_PACKET. The test case will be
> limited to querying device and load/unload. Running traffic tests
> will require DPDK (or other user-mode program making use of
> IB_QPT_RAW_PACKET).
> 
> Is it acceptable to develop test cases for this driver without
> traffic/data tests?

I'm not keen on that, even EFA was able to do simple traffic.

Even with RAW_PACKET I would expect the driver to be able to send/recv
using standard verbs as RAW_PACKET is a common feature.

Jason