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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 6644DC433E0 for ; Thu, 25 Mar 2021 10:34:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D4CD61A2E for ; Thu, 25 Mar 2021 10:34:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229900AbhCYKeY (ORCPT ); Thu, 25 Mar 2021 06:34:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbhCYKeF (ORCPT ); Thu, 25 Mar 2021 06:34:05 -0400 Received: from nbd.name (nbd.name [IPv6:2a01:4f8:221:3d45::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DD0FC06174A; Thu, 25 Mar 2021 03:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbd.name; s=20160729; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Subject:From:References:Cc:To:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zX4w/YCkqpoXy6bZV/Ut/Ci2wQiJmAv2JfLAPxQJFqE=; b=Ia8EkU18A2xNwsyK3OpzgjLKLN 5CoFQt5FqnnsFZdgK9ZQAHhiC//FyW9i1ap51uUVLdvmTahmQPtEpeO1O0QXweTu1njJ1rf/oomaz bhhfmOoH9d118Fg1dbfcniJgUstgdh4CnwLGfZzXH6BAtG8O4ej9hHECFYAPeiA8J+Fg=; Received: from p4ff13c8d.dip0.t-ipconnect.de ([79.241.60.141] helo=nf.local) by ds12 with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lPNJL-0003xC-IU; Thu, 25 Mar 2021 11:33:55 +0100 To: Rakesh Pillai , 'Ben Greear' , 'Brian Norris' Cc: 'Johannes Berg' , 'Rajkumar Manoharan' , 'ath10k' , 'linux-wireless' , 'Linux Kernel' , 'Kalle Valo' , "'David S. Miller'" , 'Jakub Kicinski' , netdev@vger.kernel.org, 'Doug Anderson' , 'Evan Green' References: <1595351666-28193-1-git-send-email-pillair@codeaurora.org> <1595351666-28193-3-git-send-email-pillair@codeaurora.org> <13573549c277b34d4c87c471ff1a7060@codeaurora.org> <04d7301d5ad7555a0377c7df530ad8522fc00f77.camel@sipsolutions.net> <1f2726ff-8ba9-5278-0ec6-b80be475ea98@nbd.name> <06a4f84b-a0d4-3f90-40bb-f02f365460ec@candelatech.com> <47d8be60-14ce-0223-bdf3-c34dc2451945@candelatech.com> <633feaed-7f34-15d3-1899-81eb1d6ae14f@nbd.name> <003701d7215b$a44ae030$ece0a090$@codeaurora.org> From: Felix Fietkau Subject: Re: [RFC 2/7] ath10k: Add support to process rx packet in thread Message-ID: Date: Thu, 25 Mar 2021 11:33:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <003701d7215b$a44ae030$ece0a090$@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 2021-03-25 10:45, Rakesh Pillai wrote: > Hi Felix / Ben, > > In case of ath10k (snoc based targets), we have a lot of processing in the NAPI context. > Even moving this to threaded NAPI is not helping much due to the load. > > Breaking the tasks into multiple context (with the patch series I posted) is helping in improving the throughput. > With the current rx_thread based approach, the rx processing is broken into two parallel contexts > 1) reaping the packets from the HW > 2) processing these packets list and handing it over to mac80211 (and later to the network stack) > > This is the primary reason for choosing the rx thread approach. Have you considered the possibility that maybe the problem is that the driver doing too much work? One example is that you could take advantage of the new 802.3 decap offload to simplify rx processing. Worked for me on mt76 where a dual-core 1.3 GHz A64 can easily handle >1.8 Gbps local TCP rx on a single card, without the rx NAPI thread being the biggest consumer of CPU cycles. And if you can't do that and still consider all of the metric tons of processing work necessary, you could still do this: On interrupts, spawn a processing thread that traverses the ring and does the preparation work (instead of NAPI). >From that thread you schedule the threaded NAPI handler that processes these packets further and hands them to mac80211. To keep the load somewhat balanced, you can limit the number of pre-processed packets in the ring. - Felix