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 2AB1CC433F5 for ; Fri, 18 Feb 2022 07:41:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231270AbiBRHmC (ORCPT ); Fri, 18 Feb 2022 02:42:02 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:43854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbiBRHmB (ORCPT ); Fri, 18 Feb 2022 02:42:01 -0500 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 1E07E26121 for ; Thu, 17 Feb 2022 23:41:44 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=haoxu@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0V4oPGuS_1645170101; Received: from 192.168.31.208(mailfrom:haoxu@linux.alibaba.com fp:SMTPD_---0V4oPGuS_1645170101) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Feb 2022 15:41:42 +0800 Message-ID: <44b5cc5e-5417-b766-5d28-15b7bcaaafed@linux.alibaba.com> Date: Fri, 18 Feb 2022 15:41:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: napi_busy_poll Content-Language: en-US To: Olivier Langlois , Jens Axboe , io-uring@vger.kernel.org References: <21bfe359aa45123b36ee823076a036146d1d9518.camel@trillion01.com> <0446f39d-f926-0ae4-7ea4-00aff9236322@linux.alibaba.com> <995e65ce3d353cacea4d426c9876b2a5e88faa99.camel@trillion01.com> <51b4d363a9bd926243a2f7928335cdd2ac3f1218.camel@trillion01.com> From: Hao Xu In-Reply-To: <51b4d363a9bd926243a2f7928335cdd2ac3f1218.camel@trillion01.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On 2/18/22 13:05, Olivier Langlois wrote: > On Wed, 2022-02-16 at 20:14 +0800, Hao Xu wrote: >> @@ -5583,6 +5650,7 @@ static void io_poll_task_func(struct io_kiocb >> *req, bool *locked) >>          struct io_ring_ctx *ctx = req->ctx; >>          int ret; >> >> +       io_add_napi(req->file, req->ctx); >>          ret = io_poll_check_events(req); >>          if (ret > 0) >>                  return; >> @@ -5608,6 +5676,7 @@ static void io_apoll_task_func(struct io_kiocb >> *req, bool *locked) >>          struct io_ring_ctx *ctx = req->ctx; >>          int ret; >> >> +       io_add_napi(req->file, req->ctx); >>          ret = io_poll_check_events(req); >>          if (ret > 0) >>                  return; >> > I have a doubt about these call sites for adding the napi_id into the > list. AFAIK, these are the functions called when the desired events are > ready therefore, it is too late for polling the device. [1] > > OTOH, my choice of doing it from io_file_get_normal() was perhaps a > poor choice too because it is premature. > > Possibly the best location might be __io_arm_poll_handler()... Hi Oliver, Have you tried just issue one recv/pollin request and observe the napi_id? From my understanding of the network stack, the napi_id of a socket won't be valid until it gets some packets. Because before that moment, busy_poll doesn't know which hw queue to poll. In other words, the idea of NAPI polling is: the packets of a socket can be from any hw queue of a net adapter, but we just poll the queue which just received some data. So to get this piece of info, there must be some data coming to one queue, before doing the busy_poll. Correct me if I'm wrong since I'm also a newbie of network stuff... I was considering to poll all the rx rings, but it seemed to be not efficient from some tests by my colleague. for question [1] you mentioned, I think it's ok, since:  - not all the data has been ready at that moment  - the polling is not just for that request, there may be more data comming    from the rx ring since we usually use polling mode under high workload    pressure. See the implementation of epoll busy_poll, the same thing. Regards, Hao