From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68B33C606B0 for ; Tue, 9 Jul 2019 11:00:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3BC08214AF for ; Tue, 9 Jul 2019 11:00:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562670040; bh=2XsTmWCfqT5Fa4cZZJO+REL76wsoOz4bHJL9fpj5At8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=dodw4hiRWVMvNFTpiN4/rou8dWIRQ/PjEVxevMRigLW+qel3v7uiXXIlt0xDCmI35 blM0eX9w42CinOX7n3LsgtU7yKZt9tC9Yg+EDaJJON/Ch5xjGEg0LO4BGjL8jJA7tS AisJlBy0xsWemyGnLYVkV57SbvO73TEBY1BiKhjI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726241AbfGILAj (ORCPT ); Tue, 9 Jul 2019 07:00:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:40090 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbfGILAj (ORCPT ); Tue, 9 Jul 2019 07:00:39 -0400 Received: from localhost (unknown [193.47.165.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AFDC120861; Tue, 9 Jul 2019 11:00:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562670039; bh=2XsTmWCfqT5Fa4cZZJO+REL76wsoOz4bHJL9fpj5At8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fv2pKjptyF2Liggy5U6pHGehR/sr+XnJc9c0WEuyy7ySwLU2b56IiehBJQGmE+L01 xlHlExpoAGE+2HGAKp/6NhOXpQyxce/g9sPAM8ICnrVmGjM40ULx4oMsZfCLK3OUcZ fVFoY4HqmMr3Tya6T9R7gAF1C/rxnGQH9hc1kXfY= Date: Tue, 9 Jul 2019 14:00:36 +0300 From: Leon Romanovsky To: Danil Kipnis Cc: Jack Wang , linux-block@vger.kernel.org, linux-rdma@vger.kernel.org, axboe@kernel.dk, Christoph Hellwig , Sagi Grimberg , bvanassche@acm.org, jgg@mellanox.com, dledford@redhat.com, Roman Pen , gregkh@linuxfoundation.org Subject: Re: [PATCH v4 00/25] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Message-ID: <20190709110036.GQ7034@mtr-leonro.mtl.com> References: <20190620150337.7847-1-jinpuwang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Archived-At: List-Archive: List-Post: On Tue, Jul 09, 2019 at 11:55:03AM +0200, Danil Kipnis wrote: > Hallo Doug, Hallo Jason, Hallo Jens, Hallo Greg, > > Could you please provide some feedback to the IBNBD driver and the > IBTRS library? > So far we addressed all the requests provided by the community and > continue to maintain our code up-to-date with the upstream kernel > while having an extra compatibility layer for older kernels in our > out-of-tree repository. > I understand that SRP and NVMEoF which are in the kernel already do > provide equivalent functionality for the majority of the use cases. > IBNBD on the other hand is showing higher performance and more > importantly includes the IBTRS - a general purpose library to > establish connections and transport BIO-like read/write sg-lists over > RDMA, while SRP is targeting SCSI and NVMEoF is addressing NVME. While > I believe IBNBD does meet the kernel coding standards, it doesn't have > a lot of users, while SRP and NVMEoF are widely accepted. Do you think > it would make sense for us to rework our patchset and try pushing it > for staging tree first, so that we can proof IBNBD is well maintained, > beneficial for the eco-system, find a proper location for it within > block/rdma subsystems? This would make it easier for people to try it > out and would also be a huge step for us in terms of maintenance > effort. > The names IBNBD and IBTRS are in fact misleading. IBTRS sits on top of > RDMA and is not bound to IB (We will evaluate IBTRS with ROCE in the > near future). Do you think it would make sense to rename the driver to > RNBD/RTRS? It is better to avoid "staging" tree, because it will lack attention of relevant people and your efforts will be lost once you will try to move out of staging. We are all remembering Lustre and don't want to see it again. Back then, you was asked to provide support for performance superiority. Can you please share any numbers with us? Thanks