Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp2113921pxb; Mon, 23 Aug 2021 12:17:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqRKt0SLMMi1p49v8/IFgadzeVEFNT/hShogN9oTnTsV2btdMoaUOuZUejo9+RQ9BMDbPB X-Received: by 2002:a05:6402:27c6:: with SMTP id c6mr8449866ede.111.1629746271770; Mon, 23 Aug 2021 12:17:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629746271; cv=none; d=google.com; s=arc-20160816; b=bWpWyZnWJghm5j1XoPOjemRGgdMktoNj8D8BLTaKO64H7XdKLyP5HTsbgaynEEkWTu rcXx7g3RRViBENiPkS5AEJi7S2y+O2Tl9qv/OpSMmEsOY/GwWxosi0hrNh6NZz/MnBzL FavgaCihk841PLUGzYu9FTH6UVNUn6XHDlTzM7TWVhzqmE81AWGzftiv7aWWgaZi5dra SQGtThGmwgo6cMXRKOwvk74oJ7HgKsU1WSYP82BNbEQKlXnoju3TdQZ9mDPNIs4cYHyA JTg/WixlKO3ELI14OUTwXkHlRPMnl/6WPbWR3UpGOzynTe3Od7M/UyUkclzaI9I00H6F rtpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=C4YiITZLwd1FjTu1OcR03tOrxxe1bILHAoD/r95KPyA=; b=iKF6R0cdP0Ux2KiaOg+wISe7rmqnk21HumJBNV89gimBid28Y1kMh4QsPZRQghyNX9 TD4Vaew43rNWqsiSIUo0x+ON9i25L+Xn9zVQnAXEfXR0XNmQjvF4zpg7pmQWmdF8pi7X 9dWUrB4nC9/aTK+KqVKqekupmztT0oeYIz0fcvfPdQygoEYLhhXajILkFTsZ+M8IXhcE DndNEEvYipem4VDjl4RilpEJETTrAlSe67Bis/AkcF4Ao5NHbsG6KXIA2dmWRwwjXymA Eve0INOITYQOUkOIAXhcUrjxR1oZVjJRj8QwbUiN22bDSju7Nj9xIijORp2WoJIyeNqV UH/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joshtriplett.org header.s=fm1 header.b=bowK4U65; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=RpNw4RGC; 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 g5si16926908ejr.361.2021.08.23.12.17.28; Mon, 23 Aug 2021 12:17:51 -0700 (PDT) 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; dkim=pass header.i=@joshtriplett.org header.s=fm1 header.b=bowK4U65; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=RpNw4RGC; 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 S229622AbhHWTOe (ORCPT + 99 others); Mon, 23 Aug 2021 15:14:34 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:54073 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231747AbhHWTOd (ORCPT ); Mon, 23 Aug 2021 15:14:33 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 785645C01EB; Mon, 23 Aug 2021 15:13:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 23 Aug 2021 15:13:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= joshtriplett.org; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=fm1; bh=C4Y iITZLwd1FjTu1OcR03tOrxxe1bILHAoD/r95KPyA=; b=bowK4U65RhRyDD0/6nz kkN88O9v7TSy2myiNzHU11aMTem0HyXom+u0ipoGEusFSLlBimTIbDGU69oKL9tN Ro1E+tnbkAPiGy5Hw3yh5ZfZf4qRqxTvcT2AzzUlL2BBNn4t6twIRd3sYz5RYD/4 7+UJe3fz4s66SDBWrKWg1E3mPQDljiswMRO+zkVzJq8IYtcfpO9wvdqOfvblUKK4 rlf9+Wl+NUS+MxDhATWfExbhHrOEmIWyEBQ60astJhobGiLqf2XmjzbkOHcnf+mi FMM45gqNwJmn5eVR3SNMsreGCxSnOZGjWvFuh8bFIQkk30Gn4KfnaDSTiwEqhc1n WoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=C4YiIT ZLwd1FjTu1OcR03tOrxxe1bILHAoD/r95KPyA=; b=RpNw4RGCsz9BUChMAYN8IO FKq4cX04tbcC9Ua/JM3uZ/7TxGRRAxC7/QyuXJY5jdDsIAh6t36IudXAHYlhVxBs Xq2UZD2xkt5BHFAqSFIvygdyNGUVTJaETKRjMC4eKsemRuG71o3tpT83hgeNiTw0 4fWsDcrEMPpMHzt8oc+J0D7AO+ojHTsndmNNLLVIImYgSkHo9FbFJl+bjtkSlO/j o/5fMDfP1F377RiWO7fwpwSCH8D/llZwTfxTND9UDVkRvWNxCZjh+TyG6C5jMnhS DOmaVmFqx/qebxJ2YlQXJF+MHFY5j2QGWwJ3xrcCjCJ705UPAfT0U/hn0SrTLRdA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddthedgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheplfhoshhh ucfvrhhiphhlvghtthcuoehjohhshhesjhhoshhhthhrihhplhgvthhtrdhorhhgqeenuc ggtffrrghtthgvrhhnpeegtdfgfeeghfevgeelgfefieegudeuheekkedtueeutefgheff veegueeiteehteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehjohhshhesjhhoshhhthhrihhplhgvthhtrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Aug 2021 15:13:46 -0400 (EDT) Date: Mon, 23 Aug 2021 12:13:45 -0700 From: Josh Triplett To: Jens Axboe Cc: Pavel Begunkov , io-uring@vger.kernel.org, "David S . Miller" , Jakub Kicinski , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Stefan Metzmacher Subject: Re: [PATCH v3 0/4] open/accept directly into io_uring fixed file table Message-ID: References: <7fa72eec-9222-60eb-9ec6-e4b6efbfc5fb@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7fa72eec-9222-60eb-9ec6-e4b6efbfc5fb@kernel.dk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 21, 2021 at 08:18:12PM -0600, Jens Axboe wrote: > On 8/21/21 9:52 AM, Pavel Begunkov wrote: > > Add an optional feature to open/accept directly into io_uring's fixed > > file table bypassing the normal file table. Same behaviour if as the > > snippet below, but in one operation: > > > > sqe = prep_[open,accept](...); > > cqe = submit_and_wait(sqe); > > io_uring_register_files_update(uring_idx, (fd = cqe->res)); > > close((fd = cqe->res)); > > > > The idea in pretty old, and was brough up and implemented a year ago > > by Josh Triplett, though haven't sought the light for some reasons. > > > > The behaviour is controlled by setting sqe->file_index, where 0 implies > > the old behaviour. If non-zero value is specified, then it will behave > > as described and place the file into a fixed file slot > > sqe->file_index - 1. A file table should be already created, the slot > > should be valid and empty, otherwise the operation will fail. > > > > we can't use IOSQE_FIXED_FILE to switch between modes, because accept > > takes a file, and it already uses the flag with a different meaning. > > > > since RFC: > > - added attribution > > - updated descriptions > > - rebased > > > > since v1: > > - EBADF if slot is already used (Josh Triplett) > > - alias index with splice_fd_in (Josh Triplett) > > - fix a bound check bug > > With the prep series, this looks good to me now. Josh, what do you > think? I would still like to see this using a union with the `nofile` field in io_open and io_accept, rather than overloading the 16-bit buf_index field. That would avoid truncating to 16 bits, and make less work for expansion to more than 16 bits of fixed file indexes. (I'd also like that to actually use a union, rather than overloading the meaning of buf_index/nofile.) I personally still feel that using non-zero to signify index-plus-one is both error-prone and not as future-compatible. I think we could do better with no additional overhead. But I think the final call on that interface is up to you, Jens. Do you think it'd be worth spending a flag bit or using a different opcode, to get a cleaner interface? If you don't, then I'd be fine with seeing this go in with just the io_open and io_accept change. - Josh Triplett