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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B3A40C43461 for ; Mon, 12 Apr 2021 09:44:00 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F1BDB611AD for ; Mon, 12 Apr 2021 09:43:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1BDB611AD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-541-7Y2SjsUQMx6sib6_sWW05A-1; Mon, 12 Apr 2021 05:43:57 -0400 X-MC-Unique: 7Y2SjsUQMx6sib6_sWW05A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9C32C6D24D; Mon, 12 Apr 2021 09:43:51 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 72C3319C44; Mon, 12 Apr 2021 09:43:51 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 3A1E74ED86; Mon, 12 Apr 2021 09:43:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 13C9hmjI027516 for ; Mon, 12 Apr 2021 05:43:48 -0400 Received: by smtp.corp.redhat.com (Postfix) id 2C3902182DF2; Mon, 12 Apr 2021 09:43:48 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 265842182DF3 for ; Mon, 12 Apr 2021 09:43:45 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AB16E805F48 for ; Mon, 12 Apr 2021 09:43:45 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-225-LccXPtJbMCa407dtlehD3g-1; Mon, 12 Apr 2021 05:43:41 -0400 X-MC-Unique: LccXPtJbMCa407dtlehD3g-1 Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lVsqL-0045x5-8H; Mon, 12 Apr 2021 09:26:54 +0000 Date: Mon, 12 Apr 2021 10:26:53 +0100 From: Christoph Hellwig To: Ming Lei Message-ID: <20210412092653.GA972763@infradead.org> References: <20210401021927.343727-1-ming.lei@redhat.com> <20210401021927.343727-6-ming.lei@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210401021927.343727-6-ming.lei@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: dm-devel@redhat.com Cc: Jens Axboe , Mike Snitzer , linux-block@vger.kernel.org, dm-devel@redhat.com, Jeffle Xu Subject: Re: [dm-devel] [PATCH V5 05/12] block: add new field into 'struct bvec_iter' X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't like where this is going. I think the model of storing the polling cookie in the bio is useful, but: (1) I think having this in the iter is a mess. Can you measure if just marking bvec_iter __packed will generate much worse code at all anymore? If not we can just move this into the bio If it really generates much worse code I think you need to pick a different name as as that i really confusing vs the bio field of the same name that is used entirely differenly. Similarly the bio_get_private_data and bio_set_private_data helpers are entirely misnamed, as the names suggest they deal with the bi_private field in struct bio. I actually suspect not having these helpers would be much preferable (2) once we do have the cookie in the bio we need to take advantage of that properly. That is stop returning the cookie up the stack as we do right now but just rely on the bio, which will clean up tons of crap. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel 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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 ADBFAC433B4 for ; Mon, 12 Apr 2021 09:31:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 78C496125F for ; Mon, 12 Apr 2021 09:31:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239326AbhDLJba (ORCPT ); Mon, 12 Apr 2021 05:31:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242115AbhDLJ1Z (ORCPT ); Mon, 12 Apr 2021 05:27:25 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45E4CC061574 for ; Mon, 12 Apr 2021 02:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ewECoWXjFufcTcBEA3sGrKKbCn2MMxY1VG7zTTsOaUw=; b=YwlcGEAnSOWv7RGnXN8qBemTqT cCUVEokpBcF24P/sZ3EipRgQylkP6jWTCoJWNTB33tBlcL/CNOt4fVmrFlBMA7GjzQV3scpFtxblk uvLDBD1cNqbm9bzXn4smG9s3Bl/IO0R8yGM4c57OPl/PJ+AHmtA28BgqcsFnTsKYPj5fLGVh0zS73 xv3eooElAS1Y2v7fuhn5PEjEfIuNdm0ApqOgMVYOEAtRvzSXgpMtjilVd1UFEvzexKhzrzRmJM3IP w775W5v2wdXHRkS9evgQvFK9r6lESEQ3rOMHiR4YQHKeYqHUfJmp/4JFBkCqR1Ip9jBzHaEUqn6Bd 9uGH0D1Q==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lVsqL-0045x5-8H; Mon, 12 Apr 2021 09:26:54 +0000 Date: Mon, 12 Apr 2021 10:26:53 +0100 From: Christoph Hellwig To: Ming Lei Cc: Jens Axboe , linux-block@vger.kernel.org, Jeffle Xu , Mike Snitzer , dm-devel@redhat.com, Hannes Reinecke Subject: Re: [PATCH V5 05/12] block: add new field into 'struct bvec_iter' Message-ID: <20210412092653.GA972763@infradead.org> References: <20210401021927.343727-1-ming.lei@redhat.com> <20210401021927.343727-6-ming.lei@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210401021927.343727-6-ming.lei@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org I don't like where this is going. I think the model of storing the polling cookie in the bio is useful, but: (1) I think having this in the iter is a mess. Can you measure if just marking bvec_iter __packed will generate much worse code at all anymore? If not we can just move this into the bio If it really generates much worse code I think you need to pick a different name as as that i really confusing vs the bio field of the same name that is used entirely differenly. Similarly the bio_get_private_data and bio_set_private_data helpers are entirely misnamed, as the names suggest they deal with the bi_private field in struct bio. I actually suspect not having these helpers would be much preferable (2) once we do have the cookie in the bio we need to take advantage of that properly. That is stop returning the cookie up the stack as we do right now but just rely on the bio, which will clean up tons of crap.