From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 158AB31F9B8 for ; Mon, 18 May 2026 10:14:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099255; cv=none; b=ixHZfY9d2GKg1V3cLQCFVBHy48fwXXaKsCdXc2P/IIPVJ0pQs4+nxt0J4IxdN1Iyq/lv240AyEBr17/zg3hU94rvJcmHU3xFGN1L7j4IIs0oDNT7BKQlb1Fd/n9jInr1oI1XqIh/iKVaFizUarRbDuZmxrAovAgPejV/f9FNKzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099255; c=relaxed/simple; bh=3CuHTJb7a1uf/Vt2GUcQwRyWkRY1v//75zEJ72jrsaY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jAE9mAR8qBQxekIwoyy0Em4H6pQWMTwQdU6IVkRTU1oJVwX9Hq+XUHllPCvDkLpM0ZGJi67Hy+tdzWR5s7YRvPrVsXgSv0lIBUZM3xNTP+iXm2Lfl0UnnnQPH7YqV7En/GXGgvg7PzfAg+P1/cI2HxZT7tmB37UHcJa5fwyAPUk= 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=R1ZDf3kA; arc=none smtp.client-ip=209.85.128.49 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="R1ZDf3kA" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-48909558b3aso22501935e9.0 for ; Mon, 18 May 2026 03:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779099252; x=1779704052; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HqBDj90Kc3B5RL3RITDRmt05U20tIBaa43CY99Xd9RQ=; b=R1ZDf3kABY32pxy0h+kPbdKnYZrzH+iwDxvK0ocrMzmv6o/u7R6jnvJNBjuqGhkdpP iB1W2mKv4uHNINJ4/JHtzaDwU9PoOKCte0Dt79zh0ecxFFMPRqapHpVfQA+keKfmXxIS 8DayMB3M23H8ChWcpQzKj5cxBTOrA7GD1qECTci1sCGjehOqYyruEyGzahz/9HNyMIAI dRpw5nxgLiUc9hrvd/73CZz3dusoKm1en3BGRDHuSHotzc8LXPnDIGRjijVTeFqz9yi6 qssw9j+pbQAZjKy7HRStnmeQzG53nx0zF/WhTSRPfs+mJDUbdUBlAoLY7uWrqoLow0SF p8UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779099252; x=1779704052; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HqBDj90Kc3B5RL3RITDRmt05U20tIBaa43CY99Xd9RQ=; b=omu9NtvA6fr5f9KY21ayNKEvgoorWgdErEiXGTkJKainH5zjSql59PUQUSJZj0kz4t JWtjNv63zbaw/PyQlRwJH6MdKB+8IvtAu+AI4CWy0YTHPGbyF4GCu249K1rv+lRLA2SY JD1ZvN4IwDAKF7cBeS2L1kJk1vosOZRPr1u47y/CbSvq3MnIKDhvmff9FRbZQs06FGcH rxm1Jq3Q4JNH4sR0YTtJ6Ls1nH/5OmxmXzNQmh5fO6Zss+3nBzX52VB75g3JoNq0ZNiS BQmnKI3nY9cPWILjmRblinNhB84WZIwF1AWekODXTai/JXE4ymqd1R51oBOuTdG1c1po 3t+g== X-Forwarded-Encrypted: i=1; AFNElJ+dtFu15ltc660wZSTlQYCzFHrIQazm4wgFVghLeyL3MrW6/r5vPBl5L/a+xzqohCxWOAUwMW7FmTLlbA==@vger.kernel.org X-Gm-Message-State: AOJu0YzNUJKW5F7qzacszToD4RJEjCgw8Ffp6DGTtDiS5b2hWGmFWvMT 89m75HpW31a8ejRADiMFnNP5UHFz8/9TkjtDjvIr8Tl+7pB8wIvpvdWe X-Gm-Gg: Acq92OGxq8LpurKs33IOCWVY63eXsQ+YOzDxfhr+U96fN7jjeca1VV5r41GnfMTd4R+ +RKwZRH4ePwBOah9GucZyMUY5R4Kdh1V0/Romqh4vR/pu9DJwszu3tphPavUnecRbkk8B2NuCRL t5HcNMmaCrsmVdx4KufrBMLgkZmx6SsUaeBfl7h7G7LdzJZUgF2mXnPkjgoHUyie38b9zhs/FOW kQn7EDsWmxzlvXN5WxVo/PEljueNmTLHYjA0aJsZWWuraU6jTipFsvGUTTVtcBhKApZ9e7LD7Qr t6of+SJSOhUvPcVH8G1GzW8unM3+h8Jp18Q+G8uzKAKacP4wYjItIJa04xG+nREHQTg14gIuV8k LTXLOuGWgnAlDZFYE/Ks5bgxjC94a2vG2SvJoTMvYXz88IvTlWhMY30kUjDiQCrAnZEFSLM4ANn ytf0cXhkZywxYWbHl2dPmJrB7nQRVA0h8u/RLe03z4YXmUNCl26lvfhbcoH9wR3Pv4LL9BUpszN XurPwFUTopkvcLQg+xuM250wM48uHSvNIQddD1PqkMVg6hITzPoYU6EWpM= X-Received: by 2002:a05:600c:3b12:b0:488:b14f:b8ed with SMTP id 5b1f17b1804b1-48fe59ab80emr218398395e9.0.1779099252361; Mon, 18 May 2026 03:14:12 -0700 (PDT) Received: from ?IPV6:2620:10d:c096:325:77fd:1068:74c8:af87? ([2620:10d:c092:600::1:6e9b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da0fe0f72sm38877974f8f.25.2026.05.18.03.14.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2026 03:14:11 -0700 (PDT) Message-ID: Date: Mon, 18 May 2026 11:14:09 +0100 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 05/10] lib: add dmabuf token infrastructure To: Christoph Hellwig Cc: Jens Axboe , Keith Busch , Sagi Grimberg , Alexander Viro , Christian Brauner , Andrew Morton , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Nitesh Shetty , Kanchan Joshi , Anuj Gupta , Tushar Gohad , William Power , Phil Cayton , Jason Gunthorpe References: <20260513082431.GA6461@lst.de> Content-Language: en-US From: Pavel Begunkov In-Reply-To: <20260513082431.GA6461@lst.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/13/26 09:24, Christoph Hellwig wrote: > Naming and placement: > > This is about dma-buf based I/O. So I'd expect it to be named dma-buf-io > and no io-dmabuf, and live in drivers/dma-buf and not the unrelated lib/. > But I'd like to hear from the dma-buf maintainers about that. Looking at what Ming is saying, it'd make more sense to keep some of the parts like iterator and the file op more flexible and not automatically imply dma-buf even if it's the main and for now the only medium. I.e. ublk/fuse can use a similar interface for mapping buffers to the server even without dma mappings. I don't know how the API should look like, maybe passing memfd, and dma-buf supports mmap, but I think it's better to call the op something like "register_buffer" instead and keep all it in lib/ for the same reasons. > Config option: as this unconditionally when DMA_SHARED_BUFFER is enabled, > why does it need a separate config option? More clearly marking relevant code, easier to make optional if needed, and gives some introspection via /proc/config. > Interface: io_dmabuf_token_create / ->create_dmabuf_token filling > in a structure allocated by the caller feels odd. It's minimising pointer chasing. "token" is mainly used by io_uring in the hot path, and io_uring just keeps it as a part of a larger struct. For the same reasons "map" is allocated by the driver. I can add an extra parameter to io_dmabuf_token_create() for how many extra bytes to allocate for the caller's use, if that makes things any better for you, but it was easier to just pass an already allocated struct. My gut feeling > would be to move most of io_dmabuf_token_create into a helper called > by ->create_dmabuf_token so that the token is allocated in the > driver data structure and returned from create_dmabuf_token. -- Pavel Begunkov