From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965182AbcIPTuA (ORCPT ); Fri, 16 Sep 2016 15:50:00 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:19118 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964846AbcIPTtu (ORCPT ); Fri, 16 Sep 2016 15:49:50 -0400 Message-ID: <1474055349.20134.39.camel@oracle.com> Subject: Re: [PATCH v2 8/8] ib_uverbs: Support for kernel implementation of XRC From: Knut Omang To: Jason Gunthorpe Cc: Doug Ledford , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Sean Hefty , Hal Rosenstock , Matan Barak , Sagi Grimberg , Leon Romanovsky , Yishai Hadas , Majd Dibbiny , Eran Ben Elisha , Or Gerlitz Date: Fri, 16 Sep 2016 21:49:09 +0200 In-Reply-To: <20160916193102.GB28859@obsidianresearch.com> References: <88ffb8c9407a71069b52e155dde308a36dfaf247.1474049924.git-series.knut.omang@oracle.com> <20160916193102.GB28859@obsidianresearch.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-09-16 at 13:31 -0600, Jason Gunthorpe wrote: > On Fri, Sep 16, 2016 at 08:31:19PM +0200, Knut Omang wrote: > > +++ b/include/uapi/rdma/ib_user_verbs.h > > @@ -725,6 +725,8 @@ struct ib_uverbs_send_wr { > > __u32 reserved; > > } ud; > > } wr; > > + __u32 xrc_remote_srq_num; > > + __u32 reserved; > > }; > > You still need to discuss why this is OK... > > Are you doing all this just to be able to use the existing post_send user > space path in the common code? Is there a kernel XRC user planned? Yes, with this patch, the SIF user level provider library is able to use either kernel verbs or user verbs on a per QP basis. This is a very useful capability that the verbs API neatly lends itself almost completely to, except for this particular missing piece. > Another approach would be to implement post_send in your driver and > not rely on this common code path. I agree this would be possible, but that would have been to implement a generic feature which seems a natural completion of what is already in there in provider specific code, something I would have thought from other discussions here is considered bad practice? Thanks, Knut > > Jason