From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751694AbdHLSts (ORCPT ); Sat, 12 Aug 2017 14:49:48 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:60971 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbdHLStq (ORCPT ); Sat, 12 Aug 2017 14:49:46 -0400 Date: Sat, 12 Aug 2017 11:49:42 -0700 From: Christoph Hellwig To: Long Li Cc: Stefan Metzmacher , Steve French , "linux-cifs@vger.kernel.org" , "samba-technical@lists.samba.org" , "linux-kernel@vger.kernel.org" Subject: Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport Message-ID: <20170812184942.GA26295@infradead.org> References: <1501704648-20159-1-git-send-email-longli@exchange.microsoft.com> <1501704648-20159-3-git-send-email-longli@exchange.microsoft.com> <9632c208-d6a5-2c47-b583-274d046d97bd@samba.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 12, 2017 at 08:32:48AM +0000, Long Li via samba-technical wrote: > I think it is possible to separate the common code that implements the SMBDirect transport. There are some challenges to reuse the same code for both kernel and user spaces. > 1. Kernel mode RDMA verbs are similar but different to user-mode ones. > 2. Some RDMA features (e.g Fast Registration Work Request) are not available in user-mode. > 3. Locking and synchronization mechanism is different > 4. Memory management is different. > 5. Process creation/scheduling and data sharing between processes are different, and there is no user-mode code running in interrupt/softirq. > > Those needs to be abstracted through a layer, the rest of the code can be shared. I can work on this after patch set is reviewed. NAK - code with those sort of obsfucation layer will be rejected for kernel inclusion - don't add it.