From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 664E83DB63A for ; Tue, 19 May 2026 08:15:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178551; cv=none; b=SAPCb1QCMUEnxse2P4qVqv2P4ESrjP6PFWf+ANpZhE1RPSy7XaSTfNQOOwfPIbYUpU1ifBhNzqIEg0aYRq4yQAXMTrQJODUZxBclF43rnP6pC2CT2+c0N4ITwgAdIv3Sm4MjFpJZEhopkr9cyK8C+dRBQqIcaxwNpFwIX6lYz7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178551; c=relaxed/simple; bh=ukNhp2SUe+V00i+CScbinEy01SmNCkigc3dUv72ANDo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JaAwi87kLsuh+HqgyskMqV/5a7pttRU4nP5yEZFB4BgWmOBwjEy22F5XRdrVJAP3xs7inH24uEE3JOwfTT1+3plPe4d+dkZCnplpK2YuagQaxCfKHj8750LwnHXxh1Y+jbAHjjBFlGE4RxtBQ7Sw2KU1BpTvQVN1GULiJ5YY74Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WaynMlMF; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WaynMlMF" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-441209fb77eso1883042f8f.1 for ; Tue, 19 May 2026 01:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779178548; x=1779783348; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Gq7q4q44H1XtbreNnGBa/qXoQQzGGv2LByvvEOVI2FM=; b=WaynMlMFRuGTf8CvtKr5WJkga/2vuFLI4Z9hDGY2zHP4FUL/W1w8/z5fO03EraWi0k zekysh4ooH3cwk8tMdVKmYd5G8IP80btK8Yhk5SHzuSCv5HNBAerLX9MSP8LjS3gkgEA ivAtRVU/b4BDUVFd3zZS1V8zCW41ny0gc0s0lFjZrSV1HL7nYMJ64ke1uoPlaLmv/Su2 BXawho+iOHQkDKHzJt9a4tSgXH4Nrbp+SJ/MGjog7pHL3YzdCjdfbf165Z2OOgucdGGX Abh/0uCTzxumg1RP3Mk44o90cDLwgXWGWzXlrMgSOjxMdTwS8GBuDixjlSejq9c+uBO4 46wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779178548; x=1779783348; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Gq7q4q44H1XtbreNnGBa/qXoQQzGGv2LByvvEOVI2FM=; b=ZF0/JW414FpWPUa4X0No1AKy+mUcreLG5s4JM9iWhSSE5ZOoV6lPrvS9xf6aZ+Myiq Yy4FK2mABe9bjDxeDPSfL+ovIVOoiC+IVwesCYy8N1CI5RTwnXPzfgns9tBOBZTebIWu /Q7f7lbESkXOXrjkuajK6Tnx5FzWZPOvanPzvbqcAjlgn6NUUuxD7L5nsjzEmqYJOv2S KGSjqx+fk+dHI0wFsE5H7mxSpwbwz3aGimw3QO5JdiikeTaqk+nbwAL1FMXDkKUtVGGQ aXQ6//CLuQEEcxfdIFdARQudUihQ8c59GZzLheGMwmUGPxEuSOOcw7+OTy/spPKDvFJR NRbA== X-Forwarded-Encrypted: i=1; AFNElJ/9XQV8FsThZ6QVy3Ny4nwlZ4cbbuS+EAtaK/FWqWKAzKYsHVG23kj+4rIuiNjcpgZ6bQR+5MKTvQFwipc=@vger.kernel.org X-Gm-Message-State: AOJu0YzA8xwgqvNN4/c4rxt8+naBOgDeTR6uWFh/wrzqqgtlfVcXsHxQ XqpEJ5jtOIzCjfH16WsnrRXnYyCz4SGvPXc4maQVLQEXXjhRR/fBenrj X-Gm-Gg: Acq92OGdhhkyoVMnptWrcHB7kRoIRHVzd1k0idfpHOQ7rj+JLV30Z66OiIi1c9R2HDR Gcxbo3wnAnmBkuHyM4rJTIK37zqM2XWXz1IiaRKEZ8nqL4iA18/cFGb4LJdj5QjHENPB8QD9DrD AR7cO6RNz2dZTVq9BPppxKLGVHj7A+/Gom7+mX7c9Z3ysLoA3guhvtogIilHHi+Su0rzFH+QJu7 yThndd+FZ2EedeI0jpJwzOdVQD5IT/qva3E8NfznKooK9yIBDJqepQHqfJGwwVpRkaLAbb5w9HC PJU7wpiRtxNYtMwpz/g3eb5zBhMNDkK877CCQ4ZCi4Q/vvAmWXUElwovfEQdxdvhcXgD4Y0hHiv 1NTdBWI3JsDrvH7YrCXDLps0irw7pp9hvLeP4eToiJm8hicrbWEdlnCsMk1sy2m9/hyV58Z4ePY xyssw0kn9ym622s30w2XOPBLsHieAmjPFRUv5EWJNMus7w3YaUEQpWyOmc9UgQURY6 X-Received: by 2002:a5d:4577:0:b0:450:b883:dd3c with SMTP id ffacd0b85a97d-45d9352412cmr26263969f8f.20.1779178547828; Tue, 19 May 2026 01:15:47 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45e7c22d8b7sm14602897f8f.6.2026.05.19.01.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 01:15:47 -0700 (PDT) Date: Tue, 19 May 2026 09:15:45 +0100 From: David Laight To: David Howells Cc: Christian Brauner , Matthew Wilcox , Christoph Hellwig , Paulo Alcantara , Jens Axboe , Leon Romanovsky , Steve French , ChenXiaoSong , Marc Dionne , Eric Van Hensbergen , Dominique Martinet , Ilya Dryomov , Trond Myklebust , netfs@lists.linux.dev, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 00/21] netfs: Keep track of folios in a segmented bio_vec[] chain Message-ID: <20260519091545.171c4b85@pumpkin> In-Reply-To: <20260518222959.488126-1-dhowells@redhat.com> References: <20260518222959.488126-1-dhowells@redhat.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 18 May 2026 23:29:32 +0100 David Howells wrote: > Hi Christian, > > Could you add these patches to the VFS tree for next? > > The patches get rid of folio_queue, rolling_buffer and ITER_FOLIOQ, > replacing the folio queue construct used to manage buffers in netfslib with > one based around a segmented chain of bio_vec arrays instead. There are > three main aims here: > > (1) The kernel file I/O subsystem seems to be moving towards consolidating > on the use of bio_vec arrays, so embrace this by moving netfslib to > keep track of its buffers for buffered I/O in bio_vec[] form. > > (2) Netfslib already uses a bio_vec[] to handle unbuffered/DIO, so the > number of different buffering schemes used can be reduced to just a > single one. > > (3) Always send an entire filesystem RPC request message to a TCP socket > with single kernel_sendmsg() call as this is faster, more efficient > and doesn't require the use of corking as it puts the entire > transmission loop inside of a single tcp_sendmsg(). > > For the replacement of folio_queue, a segmented chain of bio_vec arrays > rather than a single monolithic array is provided: > > struct bvecq { > struct bvecq *next; > struct bvecq *prev; > unsigned long long fpos; > refcount_t ref; > u32 priv; > u16 nr_segs; > u16 max_segs; > enum bvecq_mem mem_type:2; > bool inline_bv:1; > bool discontig:1; There doesn't seem to be any point using bitfields. There is a massive hole here anyway. > struct bio_vec *bv; > struct bio_vec __bv[]; > }; > > The fields are: > > (1) next, prev - Link segments together in a list. I want this to be > NULL-terminated linear rather than circular to make it possible to > arbitrarily glue bits on the front. Do you ever need to follow the list backwards? If not making prev point to the pointer to the entry (probably a tailq?) makes the logic simpler (and safer) because you can remove an item without knowing whether it is the head or which list it is on. > > (2) fpos, discontig - Note the current file position of the first byte of > the segment; all the bio_vecs in ->bv[] must be contiguous in the file > space. The fpos can be used to find the folio by file position rather > then from the info in the bio_vec. Should fpos be off_t (or u64) rather than 'long long' (they are all the same underlying type). > If there's a discontiguity, this should break over into a new bvecq > segment with the discontig flag set (though this is redundant if you > keep track of the file position). Note that the beginning and end > file positions in a segment need not be aligned to any filesystem > block size. At this point you lose me :-) -- David