From patchwork Tue Dec 27 15:56:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9489577 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A4B1662AB0 for ; Tue, 27 Dec 2016 16:11:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 976A4200E7 for ; Tue, 27 Dec 2016 16:11:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8C4C1223B2; Tue, 27 Dec 2016 16:11:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 288DA201BC for ; Tue, 27 Dec 2016 16:11:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933171AbcL0QL0 (ORCPT ); Tue, 27 Dec 2016 11:11:26 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:33233 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933011AbcL0QG5 (ORCPT ); Tue, 27 Dec 2016 11:06:57 -0500 Received: by mail-pg0-f67.google.com with SMTP id g1so12812045pgn.0; Tue, 27 Dec 2016 08:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ZsMJhCJrMhVeOzfvJtnHJxM9cOERu4YAdx26D2S+mWY=; b=dwthGBQtBnu2Ujbf8AB/mR+vWCXfDJnAP3iNlYYMY/FM9/4+Py2U7SGRiLleCKvBrn tcMOm44Fzfs7EQ+P8pfPT4O4p8UqqqpOUSnErn8Ejlu/SIx0s2N233h5lgRFwEMhwERM ewv/2mL5f//jJhRvdeP3AMuTbBfOryaIVHWHtBLjrQVmBDVxf+W+R0Be3AbmnzEZUmQD PgKSOPtZNRLRtq8AGgEzgIe0kQ3qBKzNCOxVN8DmHhwNreuBShnuv6XJ1lybYI53Adua /NaQuQOy0MbJSdT5x5KpxydR0yHy/iRw46NMctAFVviAezZpg92QhnW34rlYcSnhRC2c eQGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ZsMJhCJrMhVeOzfvJtnHJxM9cOERu4YAdx26D2S+mWY=; b=rGTv8w/TH6d7JnXzWz//opH14+FOerG0vYma9cBdW27pAt/RV/d8mdfkQk0Jvjsd0J QnYu+AGqTDAWIz7rxFqmRi5QsR2ZfHIdfJWyS4AbRFc6CS87YDumons5PKe0rx4OI1Fk IdKKP2cKT71IUh60+gUbw0C9mC8FyvxpjG7SXdcTTcKQRlxQHd5ZMpyJ4OOZ3zgl4iPY Pdg943ymNXiN39gjRR3U7KjZ1+ANVLJxWjoQVQ+oMiNh5fD+R4zgL3tnCfn0DEN/ti3P xXniuyPmmHMFqi4CM26CxpCo0FMXRuC+cJ5GJtq6WCDrjvvyHXxtEvGAGVUswOS8Tf0t z2hA== X-Gm-Message-State: AIkVDXINopkWXQ5WVN4luRcUI7enVUQap0mqMkLFpCOp9BQG3U4XyfPFmoZfu3/l96KEzQ== X-Received: by 10.84.148.134 with SMTP id k6mr67099057pla.57.1482854399769; Tue, 27 Dec 2016 07:59:59 -0800 (PST) Received: from localhost ([45.35.47.137]) by smtp.gmail.com with ESMTPSA id u64sm83782859pgc.39.2016.12.27.07.59.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 07:59:58 -0800 (PST) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, Christoph Hellwig , Ming Lei , Johannes Berg Subject: [PATCH v1 14/54] block: introduce multipage/single page bvec helpers Date: Tue, 27 Dec 2016 23:56:03 +0800 Message-Id: <1482854250-13481-15-git-send-email-tom.leiming@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1482854250-13481-1-git-send-email-tom.leiming@gmail.com> References: <1482854250-13481-1-git-send-email-tom.leiming@gmail.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch introduces helpers which are suffixed with _mp and _sp for the multipage bvec/segment support. The helpers with _mp suffix are the interfaces for treating one bvec/segment as real multipage one, for example, .bv_len is the total length of the multipage segment. The helpers with _sp suffix are interfaces for supporting current bvec iterator which is thought as singlepage only by drivers, fs, dm and etc. These _sp helpers are introduced to build singlepage bvec in flight, so users of bio/bvec iterator still can work well and needn't change even though we store multipage into bvec. Signed-off-by: Ming Lei --- include/linux/bvec.h | 56 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 53 insertions(+), 3 deletions(-) diff --git a/include/linux/bvec.h b/include/linux/bvec.h index 89b65b82d98f..307a387eb29c 100644 --- a/include/linux/bvec.h +++ b/include/linux/bvec.h @@ -24,6 +24,42 @@ #include /* + * What is multipage bvecs(segment)? + * + * - bvec stored in bio->bi_io_vec is always multipage style vector + * + * - bvec(struct bio_vec) represents one physically contiguous I/O + * buffer, now the buffer may include more than one pages since + * multipage(mp) bvec is supported, and all these pages represented + * by one bvec is physically contiguous. Before mp support, at most + * one page can be included in one bvec, we call it singlepage(sp) + * bvec. + * + * - .bv_page of th bvec represents the 1st page in the mp segment + * + * - .bv_offset of the bvec represents offset of the buffer in the bvec + * + * The effect on the current drivers/filesystem/dm/bcache/...: + * + * - almost everyone supposes that one bvec only includes one single + * page, so we keep the sp interface not changed, for example, + * bio_for_each_segment() still returns bvec with single page + * + * - bio_for_each_segment_all() will be changed to return singlepage + * bvec too + * + * - during iterating, iterator variable(struct bvec_iter) is always + * updated in multipage bvec style and that means bvec_iter_advance() + * is kept not changed + * + * - returned(copied) singlepage bvec is generated in flight by bvec + * helpers from the stored mp bvec + * + * - In case that some components(such as iov_iter) need to support mp + * segment, we introduce new helpers(suffixed with _mp) for them. + */ + +/* * was unsigned short, but we might as well be ready for > 64kB I/O pages */ struct bio_vec { @@ -49,16 +85,30 @@ struct bvec_iter { */ #define __bvec_iter_bvec(bvec, iter) (&(bvec)[(iter).bi_idx]) -#define bvec_iter_page(bvec, iter) \ +#define bvec_iter_page_mp(bvec, iter) \ (__bvec_iter_bvec((bvec), (iter))->bv_page) -#define bvec_iter_len(bvec, iter) \ +#define bvec_iter_len_mp(bvec, iter) \ min((iter).bi_size, \ __bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done) -#define bvec_iter_offset(bvec, iter) \ +#define bvec_iter_offset_mp(bvec, iter) \ (__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done) +/* + * of singlepage(sp) segment. + * + * This helpers will be implemented for building sp bvec in flight. + */ +#define bvec_iter_offset_sp(bvec, iter) bvec_iter_offset_mp((bvec), (iter)) +#define bvec_iter_len_sp(bvec, iter) bvec_iter_len_mp((bvec), (iter)) +#define bvec_iter_page_sp(bvec, iter) bvec_iter_page_mp((bvec), (iter)) + +/* current interfaces support sp style at default */ +#define bvec_iter_page(bvec, iter) bvec_iter_page_sp((bvec), (iter)) +#define bvec_iter_len(bvec, iter) bvec_iter_len_sp((bvec), (iter)) +#define bvec_iter_offset(bvec, iter) bvec_iter_offset_sp((bvec), (iter)) + #define bvec_iter_bvec(bvec, iter) \ ((struct bio_vec) { \ .bv_page = bvec_iter_page((bvec), (iter)), \