From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 632F2C4320E for ; Sun, 22 Aug 2021 02:18:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BF0B61248 for ; Sun, 22 Aug 2021 02:18:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231712AbhHVCS5 (ORCPT ); Sat, 21 Aug 2021 22:18:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57602 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231658AbhHVCSy (ORCPT ); Sat, 21 Aug 2021 22:18:54 -0400 Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95C46C061757 for ; Sat, 21 Aug 2021 19:18:14 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id y3so13598647ilm.6 for ; Sat, 21 Aug 2021 19:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3f1402yNnR5XHhynZNjdZxQF7CwaoEz9EzTU8SvpoEI=; b=1ooHuaepzTBUq1/UuK7KBZTJQ3nqI7H2HMnXqTC17jGqlVd8d7q2Bpqylh2DeuaBEd 0vLn54AF3cJ9bbb6g7DG1AsrtX899daKSmF5hOqAj7sPdh8zFe1JQHoGa5znTznIEV0P UewesmAzOQiREHh71RUJ6j45nGyidReqz+uW+3rkk7fg6lqjZb+WoBw4MATJvzMKiqFJ HC8K52JpuuUFI0+gKoNcZFBiL8z0e6psdK1czYV8m1sKbUpBFXfFH4yttvisLsgP2HkB ynnush+uj6Uh3dWf4A8DdVT07IlYPwDi1Ll4gMByceiEiCIrZ2+PvWfYmHoMZiU5M4DD 5nkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3f1402yNnR5XHhynZNjdZxQF7CwaoEz9EzTU8SvpoEI=; b=Kvg1aJE1Hu+Fn9rk79wu969+zcczaLOxEznjAwvkwJHJ0sOJ5K3nUeo51yaARFnX0V 1FX1HPSsIjeLeTBcxQQSf0OH+Payo2Cq4Fnr4vkWM11bAbdlNehhhjRiz7R4GHYpYkya NXwGAZ0LVhz040r2tu2wveiK9LUALHmAeNQFsa0sbST8UnYyJ8Uf+OtslTafPe47fb8Y uTkhdZ096a12cm8ACgMabrEmmUWMRy9DZq7Z/0Ua77Z3ZSbUrs6re/UZKSfnVJQANOGE 0So3eRBFUM2uX6OgGBL+2fF020KO+695327q0Bgq3qY9U5/2U6wY4raTsSWYQrz5I/gO chvw== X-Gm-Message-State: AOAM531bOLJNOxeJtDCy16IZOaZB9RiAqyurmeXxEK2wbggvY+57r8Pk dHwXGb30Ttw4KrupjQgRVDH2bA== X-Google-Smtp-Source: ABdhPJykFZZ6+4oaXXLliFJmzbiSWZ9UKVeN3xoFTI/aTUiVN3h+eTp5d5OMjBHW4b03KO4HzksQEg== X-Received: by 2002:a92:6a05:: with SMTP id f5mr11831470ilc.140.1629598693927; Sat, 21 Aug 2021 19:18:13 -0700 (PDT) Received: from [192.168.1.116] ([66.219.217.159]) by smtp.gmail.com with ESMTPSA id d14sm3988124iod.18.2021.08.21.19.18.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Aug 2021 19:18:13 -0700 (PDT) Subject: Re: [PATCH v3 0/4] open/accept directly into io_uring fixed file table To: Pavel Begunkov , io-uring@vger.kernel.org, Josh Triplett Cc: "David S . Miller" , Jakub Kicinski , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Stefan Metzmacher References: From: Jens Axboe Message-ID: <7fa72eec-9222-60eb-9ec6-e4b6efbfc5fb@kernel.dk> Date: Sat, 21 Aug 2021 20:18:12 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? And we need the net folks to sign off on the first patch, of course. -- Jens Axboe