Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1278208pxb; Fri, 21 Jan 2022 14:09:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJzOcZkcW0JMcjgDJ3To5lVJVNDZYemzluUqn59FoAO8WgGDFOvI5fN0/QOT4SuHOwNc9Tlg X-Received: by 2002:a65:460d:: with SMTP id v13mr4262862pgq.373.1642802989447; Fri, 21 Jan 2022 14:09:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642802989; cv=none; d=google.com; s=arc-20160816; b=DhbSI/BHOmkxD7MfqiqdTaCNS1bfJcWSQMpPz4/RLPRJIgV/QkSqPzL/B2nTGDfP5Q 1Nt3WuBWamkh5rQtFjjBQ4Tr4d8sNIJRwg8lV9N3Uu3KCYxLKJXcRSE9bO9StOMzjFmQ 8Wa9RFIJV0qcYAu8RSDuVQLWJgQbKFC+O5HL18WirS5kZY4TsevZZltrg5/rDEqniYl7 wkeo48vQmbkQ72nNkYq+TIPujjK+P17hvh8vJaDYjcxWxRo1fgnKAIzpI7jX6oSCO1Df zALy7Qbd3JMTw9dgogmw740MOwUdhX6EfAs75vyJRITbIaAhzyIq5XgyGO/PNt6BQ7wN Yk2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Y7F55Pwv+TvSHNc40tzEeXyXzGaTgHkVoaPVcIEj/zc=; b=t5EAKonLlJC6IP/u+xsW72XQkYRj2qhXhxrlv1yXJ9VKzMbJPJ3YuAlgcxyVq8OYYF ufG2BAOkyA2+S0jjiuZlSDZOj3PnA2bZWhp9Zkqi9fL+gbmULyWKic8DZNYNMt/O6rjW 3j4yjtbLquo71kN1WNuVdlT3WThKA9S0TTzzZbzev3I991qjI3uJ2YwxbPEAwmIaLjcC W5hBzxUJB7b/CPGTStV/LWf8/nlitIPiWGhKf9kV3HqigUtztPkSPMvy6pO9cucX0SlT dwaKNuKO/7kFl7xlj8IyQsoL7k2Y8aeKBA+u9As9pG6RjYoRUvxOsGWTziIO7a8fsiGc MHtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pi3si15603316pjb.156.2022.01.21.14.09.37; Fri, 21 Jan 2022 14:09:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238163AbiATNjR (ORCPT + 99 others); Thu, 20 Jan 2022 08:39:17 -0500 Received: from verein.lst.de ([213.95.11.211]:44631 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232587AbiATNjR (ORCPT ); Thu, 20 Jan 2022 08:39:17 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 906E668BEB; Thu, 20 Jan 2022 14:39:11 +0100 (CET) Date: Thu, 20 Jan 2022 14:39:11 +0100 From: Christoph Hellwig To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, Christoph Hellwig , Jason Gunthorpe , Joao Martins , John Hubbard , Logan Gunthorpe , Ming Lei , linux-block@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org, nvdimm@lists.linux.dev Subject: Re: Phyr Starter Message-ID: <20220120133911.GA11052@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 10, 2022 at 07:34:49PM +0000, Matthew Wilcox wrote: > TLDR: I want to introduce a new data type: > > struct phyr { > phys_addr_t addr; > size_t len; > }; > > and use it to replace bio_vec as well as using it to replace the array > of struct pages used by get_user_pages() and friends. FYI, I've done a fair amount of work (some already mainline as in all the helpers for biovec page access), some of it still waiting (switching more users over to these helpers and cleaning up some other mess) to move bio_vecs into a form like that. The difference in my plan is to have a u32 len, both to allow for flags space on 64-bit which we might need to support things like P2P without dev_pagemap structures. > Finally, it may be possible to stop using scatterlist to describe the > input to the DMA-mapping operation. We may be able to get struct > scatterlist down to just dma_address and dma_length, with chaining > handled through an enclosing struct. Yes, I have some prototype could that takes a bio_vec as input and returns an array of struct dma_range { dma_addr_t addr; u32 len; } І need to get back to it and especially back to the question if this needs the chaining support that the current scatterlist has.