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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 AE9EEC432C0 for ; Wed, 27 Nov 2019 16:31:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 870242075C for ; Wed, 27 Nov 2019 16:31:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=dlink.ru header.i=@dlink.ru header.b="is2hCZ6d" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727176AbfK0Qb3 (ORCPT ); Wed, 27 Nov 2019 11:31:29 -0500 Received: from mail.dlink.ru ([178.170.168.18]:43016 "EHLO fd.dlink.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726593AbfK0Qb3 (ORCPT ); Wed, 27 Nov 2019 11:31:29 -0500 Received: by fd.dlink.ru (Postfix, from userid 5000) id 906C71B21254; Wed, 27 Nov 2019 19:31:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru 906C71B21254 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dlink.ru; s=mail; t=1574872285; bh=D0U/yoZIFmLHwjF+Ayn7vsDRMvJ2hdz+rD6jAk4olMc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=is2hCZ6d7g97DxekjT754vqL7o2BoJRRA51ExITKCw3Ec8ZS42WJPee6O/x7R9hme H648HBJxdeER+b85BgYjiQJKA+CK2c2hJ5tbAeQ9oSTWfsjow2umhlnavKaU4+cSfX 4HeTICyus0f/DPKpKllbwup9OUPRvTyr/Vsv6X7c= Received: from mail.rzn.dlink.ru (mail.rzn.dlink.ru [178.170.168.13]) by fd.dlink.ru (Postfix) with ESMTP id BB8D91B2029D; Wed, 27 Nov 2019 19:31:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru BB8D91B2029D Received: from mail.rzn.dlink.ru (localhost [127.0.0.1]) by mail.rzn.dlink.ru (Postfix) with ESMTP id 3F34A1B20AE9; Wed, 27 Nov 2019 19:31:08 +0300 (MSK) Received: from mail.rzn.dlink.ru (localhost [127.0.0.1]) by mail.rzn.dlink.ru (Postfix) with ESMTPA; Wed, 27 Nov 2019 19:31:08 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 27 Nov 2019 19:31:08 +0300 From: Alexander Lobakin To: Edward Cree Cc: "David S. Miller" , Jiri Pirko , Eric Dumazet , Ido Schimmel , Paolo Abeni , Petr Machata , Sabrina Dubroca , Florian Fainelli , Jassi Brar , Manish Chopra , GR-Linux-NIC-Dev@marvell.com, Johannes Berg , Emmanuel Grumbach , Luca Coelho , Intel Linux Wireless , Kalle Valo , Nicholas Johnson , "Kenneth R. Crudup" , netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: wireless: intel: iwlwifi: fix GRO_NORMAL packet stalling In-Reply-To: <20a018a6-827a-de47-a0e4-45ff8c02087b@solarflare.com> References: <20191127094123.18161-1-alobakin@dlink.ru> <20a018a6-827a-de47-a0e4-45ff8c02087b@solarflare.com> User-Agent: Roundcube Webmail/1.4.0 Message-ID: X-Sender: alobakin@dlink.ru Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Edward Cree wrote 27.11.2019 19:05: > On 27/11/2019 09:41, Alexander Lobakin wrote: >> Commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in >> napi_gro_receive()") has applied batched GRO_NORMAL packets processing >> to all napi_gro_receive() users, including mac80211-based drivers. >> >> However, this change has led to a regression in iwlwifi driver [1][2] >> as >> it is required for NAPI users to call napi_complete_done() or >> napi_complete() and the end of every polling iteration, whilst iwlwifi >> doesn't use NAPI scheduling at all and just calls napi_gro_flush(). >> In that particular case, packets which have not been already flushed >> from napi->rx_list stall in it until at least next Rx cycle. >> >> Fix this by adding a manual flushing of the list to iwlwifi driver >> right >> before napi_gro_flush() call to mimic napi_complete() logics. >> >> I prefer to open-code gro_normal_list() rather than exporting it for 2 >> reasons: >> * to prevent from using it and napi_gro_flush() in any new drivers, >> as it is the *really* bad way to use NAPI that should be avoided; >> * to keep gro_normal_list() static and don't lose any CC >> optimizations. >> >> I also don't add the "Fixes:" tag as the mentioned commit was only a >> trigger that only exposed an improper usage of NAPI in this particular >> driver. >> >> [1] >> https://lore.kernel.org/netdev/PSXP216MB04388962C411CD0B17A86F47804A0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM >> [2] https://bugzilla.kernel.org/show_bug.cgi?id=205647 >> >> Signed-off-by: Alexander Lobakin > Reviewed-by: Edward Cree Thanks! And you were the first who's found the root of the issue. Regards, ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ