Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp992485imu; Tue, 20 Nov 2018 09:55:20 -0800 (PST) X-Google-Smtp-Source: AFSGD/WTfwD0Hehk3hCueaiI5FjYhxjXwrPrnDrwlPEIfjVft8DnW/wPzmCNT4gQVHNzrDcsh2G/ X-Received: by 2002:a17:902:bb0a:: with SMTP id l10-v6mr3291532pls.230.1542736519946; Tue, 20 Nov 2018 09:55:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542736519; cv=none; d=google.com; s=arc-20160816; b=Twfh6PzyejzYVdZgTDVusW5DlsP7b/j9ScTEYON12UtcrdlTPUUpKUPWbq7MLxLsby BEXYjk5pfJgnmGXfqRYzwxj6dJGtBtk528wIoKsM2Xg2xme2P48O8d2MP6IFmbTNqSyh uyjpBCwBqWnWsWyCRURgCTB5qLQZEy82hR9Sehnw6vDMY/K6GYjcirCbEo9H3SUxxR1r 4FqWA/WhbnGGt1ax9H8JCMFfvRaXbcxlFs13RN7SbFHjW7NBZMs2eZPXhD9aFIO8eIc0 kALkiVQselYz8WKHuTIAi3V22e1SjNJGeX3ym3pft9PDeDaH1MJTEAox0EsPJ7VsrSlX YMDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=p0Q4nW+x/Spzw6aAw8zxK8H5YkQKGXFsztH+AlJKGaA=; b=x++EYiElQezPhKSZUXQwWKQ4V4NOtpYoXUEBD4+jbZB6mAYOS24aPARAWp5Jfl1rcG myl9Rhxz3N67dSr+06P6JYqj2Kl2IzUkHKtfLjo5yGQzPBu38fpJ6l7dmRNb55mCpMmC yYQUJH+gYENvHJniNz8LVcjoVV5spnKtqAUKDT9KOmzrDZ36vfaYqy7rAxAYqfX7Ms4y BbNtdm6minsScvwd7znzKNsoMX/1r4DmzMpeVJq/NN4s/9W3M1fOJI4Ow0x5D1JcPynf 580LKBs5frVwwV7lwzdDzCLY3baGskOT6Rikod+R5x3Vi4YT4rgqhavHoKfJ52LdocSv WPlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n185-v6si45246557pfn.83.2018.11.20.09.55.05; Tue, 20 Nov 2018 09:55:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729200AbeKUCqs (ORCPT + 99 others); Tue, 20 Nov 2018 21:46:48 -0500 Received: from verein.lst.de ([213.95.11.211]:46161 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727733AbeKUCqr (ORCPT ); Tue, 20 Nov 2018 21:46:47 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 7226368B03; Tue, 20 Nov 2018 17:16:51 +0100 (CET) Date: Tue, 20 Nov 2018 17:16:51 +0100 From: Christoph Hellwig To: Sagi Grimberg Cc: Christoph Hellwig , Ming Lei , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, linux-erofs@lists.ozlabs.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Theodore Ts'o , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V10 09/19] block: introduce bio_bvecs() Message-ID: <20181120161651.GB2629@lst.de> References: <20181115085306.9910-1-ming.lei@redhat.com> <20181115085306.9910-10-ming.lei@redhat.com> <20181116134541.GH3165@lst.de> <002fe56b-25e4-573e-c09b-bb12c3e8d25a@grimberg.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002fe56b-25e4-573e-c09b-bb12c3e8d25a@grimberg.me> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 19, 2018 at 04:49:27PM -0800, Sagi Grimberg wrote: > >> The only user in your final tree seems to be the loop driver, and >> even that one only uses the helper for read/write bios. >> >> I think something like this would be much simpler in the end: > > The recently submitted nvme-tcp host driver should also be a user > of this. Does it make sense to keep it as a helper then? I did take a brief look at the code, and I really don't understand why the heck it even deals with bios to start with. Like all the other nvme transports it is a blk-mq driver and should iterate over segments in a request and more or less ignore bios. Something is horribly wrong in the design.