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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2942C433F5 for ; Thu, 14 Apr 2022 11:23:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242657AbiDNLZe (ORCPT ); Thu, 14 Apr 2022 07:25:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233099AbiDNLZd (ORCPT ); Thu, 14 Apr 2022 07:25:33 -0400 Received: from out30-44.freemail.mail.aliyun.com (out30-44.freemail.mail.aliyun.com [115.124.30.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 919C88594F for ; Thu, 14 Apr 2022 04:23:08 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=xiaoguang.wang@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0VA2KpuH_1649935385; Received: from 30.225.28.188(mailfrom:xiaoguang.wang@linux.alibaba.com fp:SMTPD_---0VA2KpuH_1649935385) by smtp.aliyun-inc.com(127.0.0.1); Thu, 14 Apr 2022 19:23:06 +0800 Message-ID: Date: Thu, 14 Apr 2022 19:23:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: questions about io_uring buffer select feature Content-Language: en-US To: Pavel Begunkov , io-uring@vger.kernel.org Cc: Jens Axboe References: From: Xiaoguang Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org hi, > On 4/14/22 08:41, Xiaoguang Wang wrote: >> hi, >> >> I spent some time to learn the history of buffer select feature, especially >> from https://lwn.net/Articles/813311/. According to the description in this >> link: >>      when doing the same IORING_OP_RECV, no buffer is passed in >>      with the request. Instead, it's flagged with IOSQE_BUFFER_SELECT, and >>      sqe->buf_group is filled in with a valid group ID. When the kernel can >>      satisfy the receive, a buffer is selected from the specified group ID >>      pool. If none are available, the IO is terminated with -ENOBUFS. On >>      success, the buffer ID is passed back through the (CQE) completion >>      event. This tells the application what specific buffer was used. >> >> According to my understandings, buffer select feature is suggested to be >> used with fast-poll feature, then in example of io_read(), for the first nowait >> try, io_read() will always get one io_buffer even later there is no data >> ready, eagain is returned and this req will enter io_arm_poll_handler(). >> So it seems that this behaviour violates the rule that buffer is only selected >> when data is ready? > > Right, that's how it was working, but recently Jens was queueing > patches to fix it, e.g. see io_kbuf_recycle(). I think it was > for 5.18. I see now, thanks for clarification. > >> And for ENOBUFS error, how should apps handle this error? Re-provide >> buffers and re-issue requests from user space again? Thanks. > > It sounds just right. If the userspace can't re-provide buffers, > I assume it may want to wait for some inflight requests to complete. ok. Regards, Xiaoguang Wang