From patchwork Sat Oct 29 08:08:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ming Lei X-Patchwork-Id: 9403369 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 453AC60587 for ; Sat, 29 Oct 2016 08:26:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2FA9B2A63F for ; Sat, 29 Oct 2016 08:26:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 244A62A655; Sat, 29 Oct 2016 08:26:26 +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.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, 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 B41C72A63F for ; Sat, 29 Oct 2016 08:26:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965025AbcJ2I0Z (ORCPT ); Sat, 29 Oct 2016 04:26:25 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35074 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942968AbcJ2IOT (ORCPT ); Sat, 29 Oct 2016 04:14:19 -0400 Received: by mail-pf0-f194.google.com with SMTP id s8so3381730pfj.2; Sat, 29 Oct 2016 01:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=ihsA30OjsGRE+KR/73CpgV7JHIrRfEfI9EP/M4YV/q8=; b=jd/HmfcHe5alORZPOtOumVazY3NHbxWona0somp5BEUhnCq/dX3LFCP9OtWMJaeIqe bsOTWHhMCC/NywodWu8Eus/WD1mTKjveiLNBTn1pIYq28Szo4VRoUsbnAKjyJ8+Si4M0 XlKAIRUvulDVWGd6FSbnHb4Yp2/nqULnJGdqM5xBq9zxf9jkk0sPkMeQFEmaIGe1viZ/ g1nKv++igkjt3TIicSfQXf8/sgKF/4NrvWjxc7DWcgVgo841MKJLIGLKEVL2bEXzoe3S 62pnFMuhke/md2bhF0VdDOxSdsCyKfDxuA61wsjRr/Zja8UNUoqDMlfZpAl21HINR4dn gG/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=ihsA30OjsGRE+KR/73CpgV7JHIrRfEfI9EP/M4YV/q8=; b=gZNRJQnDuI7UkJ58e7FaUBnIXmA5tdyvx0LYESNW3QHExY11loudtyvRzE9/UeofXO E0ukw6w5jxw3dedmej9Bz/wKMKxF26FY7YBRyxcDVE2BSM/2Q2z6RGM+r+f0zrprjYgU XkyNiZe3AoVZigbUp7QI0RdDAY4ZyJuYJWCGcZ679ayFgRe1QlsokhYp06PPbo0HLXPw PU7XRyyiH9Vgw4GClelLxfco1SqhTg0Pu/Bg6y7cFAHGqviBuw0ux/0/z+h9guNlwp7L XMGjoOhNFZ8HAQTXK5MixIVka+tPBjS9Sc9xiZ7DQOXCkkDXql5huOLHqQ5LlTX/BOZx B+dQ== X-Gm-Message-State: ABUngvfQGgOtR1FF0vZgbNz/iamBZvSScfDZv6VVC2jZo3iEgHkIYFfqj0odk6B9JBAiDg== X-Received: by 10.99.55.66 with SMTP id g2mr25942593pgn.65.1477728858667; Sat, 29 Oct 2016 01:14:18 -0700 (PDT) Received: from localhost ([45.34.23.101]) by smtp.gmail.com with ESMTPSA id m69sm8073634pfg.39.2016.10.29.01.14.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 01:14:18 -0700 (PDT) From: Ming Lei To: Jens Axboe , linux-kernel@vger.kernel.org Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Christoph Hellwig , "Kirill A . Shutemov" , Ming Lei , Johannes Berg Subject: [PATCH 31/60] block: introduce multipage/single page bvec helpers Date: Sat, 29 Oct 2016 16:08:30 +0800 Message-Id: <1477728600-12938-32-git-send-email-tom.leiming@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1477728600-12938-1-git-send-email-tom.leiming@gmail.com> References: <1477728600-12938-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 | 57 +++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 3 deletions(-) diff --git a/include/linux/bvec.h b/include/linux/bvec.h index 89b65b82d98f..da984fa171bc 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 from bvec + * helpers + * + * - 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,31 @@ 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 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)), \