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 19DAEC433F5 for ; Wed, 16 Feb 2022 03:12:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237750AbiBPDMb (ORCPT ); Tue, 15 Feb 2022 22:12:31 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236446AbiBPDMb (ORCPT ); Tue, 15 Feb 2022 22:12:31 -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 DE508939D3 for ; Tue, 15 Feb 2022 19:12:19 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=haoxu@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0V4bHGHq_1644981136; Received: from 30.225.24.82(mailfrom:haoxu@linux.alibaba.com fp:SMTPD_---0V4bHGHq_1644981136) by smtp.aliyun-inc.com(127.0.0.1); Wed, 16 Feb 2022 11:12:17 +0800 Message-ID: <4d889559-9268-7948-eb6b-1cb60d90016f@linux.alibaba.com> Date: Wed, 16 Feb 2022 11:12:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: napi_busy_poll 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> From: Hao Xu In-Reply-To: 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 在 2022/2/16 上午2:05, Olivier Langlois 写道: > On Tue, 2022-02-15 at 03:37 -0500, Olivier Langlois wrote: >> >> That being said, I have not been able to make it work yet. For some >> unknown reasons, no valid napi_id is extracted from the sockets added >> to the context so the net_busy_poll function is never called. >> >> I find that very strange since prior to use io_uring, my code was >> using >> epoll and the busy polling was working fine with my application >> sockets. Something is escaping my comprehension. I must tired and >> this >> will become obvious... >> > The napi_id values associated with my sockets appear to be in the range > 0 < napi_id < MIN_NAPI_ID > > from busy_loop.h: > /* 0 - Reserved to indicate value not set > * 1..NR_CPUS - Reserved for sender_cpu > * NR_CPUS+1..~0 - Region available for NAPI IDs > */ > #define MIN_NAPI_ID ((unsigned int)(NR_CPUS + 1)) > > I have found this: > https://lwn.net/Articles/619862/ > > hinting that busy_poll may be incompatible with RPS > (Documentation/networking/scaling.rst) that I may have discovered > *AFTER* my epoll -> io_uring transition (I don't recall exactly the > sequence of my learning process). > I read your code, I guess the thing is the sk->napi_id is set from skb->napi_id and the latter is set when the net device received some packets. > With my current knowledge, it makes little sense why busy polling would > not be possible with RPS. Also, what exactly is a NAPI device is quite > nebulous to me... Looking into the Intel igb driver code, it seems like > 1 NAPI device is created for each interrupt vector/Rx buffer of the > device. AFAIK, yes, each Rx ring has its own NAPI. > > Bottomline, it seems like I have fallen into a new rabbit hole. It may > take me a day or 2 to figure it all... you are welcome to enlight me if > you know a thing or 2 about those topics... I am kinda lost right > now... >