From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail132-21.atl131.mandrillapp.com (mail132-21.atl131.mandrillapp.com [198.2.132.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30F1F220F34 for ; Fri, 18 Jul 2025 08:10:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.2.132.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752826232; cv=none; b=lzqQ1xB3ChlequLv/t3x3p3MkTFOPZ+xVygTxDft5CTZJD+BAVP4EXvYbwO2KPUnUZOsYKrrTP9y7Q3tpqEHaHJ0FsnWL5p97UTqaXewgq2CPQpcY2RwpAZJ5OGDXp4kz/ihI/s1HzvVrUAhj3BnYnBHgtkm6jmwk+woKmnB310= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752826232; c=relaxed/simple; bh=1d3PpO0q077xRQs9WQqLKRGtVTC/vWISiu3MTSGnUzw=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Date: MIME-Version:Content-Type; b=FDNKkCJMcPt2zIhiDTrSnvbU4U2zSnZhY4wXGPuz26Y43ovHO2wCEmVhAcJlaI178OJOj90+UR0O/8zJUMyFjDHOgvoqG3KW3Q2U0o/m16bREsiOf3IVW7CiM19QwGty5iapOfsbPcypRULVz3Bz3ukfTXV4jlLje463gkvW3nk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=vates.tech; spf=pass smtp.mailfrom=bounce.vates.tech; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b=Ms8UgGYP; dkim=pass (2048-bit key) header.d=vates.tech header.i=anthoine.bourgeois@vates.tech header.b=Dvgz0M3q; arc=none smtp.client-ip=198.2.132.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=vates.tech Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bounce.vates.tech Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b="Ms8UgGYP"; dkim=pass (2048-bit key) header.d=vates.tech header.i=anthoine.bourgeois@vates.tech header.b="Dvgz0M3q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1752826229; x=1753096229; bh=9v3RvNn3og/vnGMjRNCHbK2EsjnkNsgZix1oMc/Rcns=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Ms8UgGYPKIWHXIgawYLIOUOGw3+mP+x1OP6dEPonV0fgHt34+8Mbs/fPwjcm8zBJz xVxhhdMLyaZZ9kXucXjjmmXpl9e9FN5p25ZX77lZz+L8AUC+bs/p50x4KqRhiDq5Ss 7rKSTyKO/4rEXtuQ8okU0qmv4blTlWsW76Y0vidxBc54ZqOMQso9IIN8pCfgg0knpd vskyg4m8I4n/R784yCU91p4Hv56FARToVLWBCOoEi1ZPJ6iUQvt2J3ayUf6Ke8jmWX FMCMZ52F2CP8f8ToQOVndjp6bpcVKgvmdkNfZWOtG2GFgGfttDQRVzv+s5T3+oTtD/ HQ/7le80XOROg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1752826229; x=1753086729; i=anthoine.bourgeois@vates.tech; bh=9v3RvNn3og/vnGMjRNCHbK2EsjnkNsgZix1oMc/Rcns=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Dvgz0M3qc4LbJ8GzauIZmGqjpLj0CCAAX8UoAV1e/OgdP+SeuMaASAIc+xreRTfSL 5Lh6dTsV9d+lqOs6CnyQ6Y65mr0bFW/n325SRdBdlU3VKtNQLT6uFk6hdc5daCuoT8 7TVjDUUYswne5oC8L5Dx1GxC97WSDGWxdMjIIFnuFUc4vLGEYUvMRtSIYWdgJhnRfJ 4Fg+BU60PuyPEBTG+7KIq/Giui63iUI7ltnFaO4D9z0hiVkvmspVR/GGPAwko6UXMh jDfahwuWUffynsHhAPXMz2z6pNQ86H/QUVlVWf5KAI0hiCfFcGGVoow4ojJh4hE8Cf nGdhQVxWnIoOQ== Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bk2Xj1Jppz1XLF4g for ; Fri, 18 Jul 2025 08:10:29 +0000 (GMT) From: "Anthoine Bourgeois" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen/netfront:=20Fix=20TX=20response=20spurious=20interrupts?= Received: from [37.26.189.201] by mandrillapp.com id 65a60f28e7d441048fd4f1adbe603a61; Fri, 18 Jul 2025 08:10:29 +0000 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1752826227429 To: "Jakub Kicinski" Cc: "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Wei Liu" , "Paul Durrant" , xen-devel@lists.xenproject.org, netdev@vger.kernel.org, "Elliott Mitchell" Message-Id: References: <20250715160902.578844-2-anthoine.bourgeois@vates.tech> <20250717072951.3bc2122c@kernel.org> In-Reply-To: <20250717072951.3bc2122c@kernel.org> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.65a60f28e7d441048fd4f1adbe603a61?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250718:md Date: Fri, 18 Jul 2025 08:10:29 +0000 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Thu, Jul 17, 2025 at 07:29:51AM -0700, Jakub Kicinski wrote: >On Tue, 15 Jul 2025 16:11:29 +0000 Anthoine Bourgeois wrote: >> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel storms") > >Not entirely sure who you expect to apply this patch, but if networking >then I wouldn't classify this is a fix. The "regression" happened 4 >years ago. And this patch doesn't seem to be tuning the logic added by >the cited commit. I think this is an optimization, -next material, and >therefore there should be no Fixes tag here. You can refer to the commit >without the tag. Ok, you're right the cited commit exacerbates a problem that was already there before. I will change this in v3. >> @@ -849,9 +847,6 @@ static netdev_tx_t xennet_start_xmit(struct sk_buff *skb, struct net_device *dev >> tx_stats->packets++; >> u64_stats_update_end(&tx_stats->syncp); >> >> - /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ >> - xennet_tx_buf_gc(queue); >> - >> if (!netfront_tx_slot_available(queue)) >> netif_tx_stop_queue(netdev_get_tx_queue(dev, queue->id)); > >I thought normally reaping completions from the Tx path is done >to prevent the queue from filling up, when the device-generated >completions are slow or the queue is short. I say "normally" but >this is relatively a uncommon thing to do in networking. >Maybe it's my lack of Xen knowledge but it would be good to add to >the commit message why these calls where here in the first place. Good to know how it should "normally" works, I'm not an expert. The patch also has the advantage of standardizing the network driver with other Xen PV drivers that do not have this reponse collection outside of the interrupt handler. As this part of the code is here since the driver was upsteamed and the author no longer works on xen, I will do my best to add my guess on why this code was there. Regards, Anthoine Anthoine Bourgeois | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 94A4AC83F1A for ; Fri, 18 Jul 2025 08:10:54 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1048143.1418428 (Exim 4.92) (envelope-from ) id 1ucgAr-0002Xa-OX; Fri, 18 Jul 2025 08:10:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1048143.1418428; Fri, 18 Jul 2025 08:10:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ucgAr-0002XT-LE; Fri, 18 Jul 2025 08:10:33 +0000 Received: by outflank-mailman (input) for mailman id 1048143; Fri, 18 Jul 2025 08:10:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ucgAq-0002XN-ND for xen-devel@lists.xenproject.org; Fri, 18 Jul 2025 08:10:32 +0000 Received: from mail132-21.atl131.mandrillapp.com (mail132-21.atl131.mandrillapp.com [198.2.132.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ab2a5647-63ae-11f0-b894-0df219b8e170; Fri, 18 Jul 2025 10:10:30 +0200 (CEST) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4bk2Xh5GJVz1XLF6s for ; Fri, 18 Jul 2025 08:10:28 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id fd920aecd9e04b49b126fd14a70e068c; Fri, 18 Jul 2025 08:10:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ab2a5647-63ae-11f0-b894-0df219b8e170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1752826228; x=1753096228; bh=9v3RvNn3og/vnGMjRNCHbK2EsjnkNsgZix1oMc/Rcns=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=SgWoUij+h35XgWvzk4ZZNgJzu7QcKqzt2UuwFmFfTPu4lO0OXH9rTf9jsiz/oFPYz ND/7LXizAQKsCVOdn5FacMBO3Ko41h8x3v2emjvBFkiljpGm+9ntB1nSHUvJJOAf/+ 5h/vkI2DYSmDrWzMi2F5rBZpfx+VovfjODF0Ar5Z7o1cD335Nh7Jh1uSEgoFLVOWpy dnPLKMdE63eCkGcluUt4AF4VgGXrR5/6zmhuHSgjGDykFohzXSXxWE0+7KgRFSTSCg 7aPH4JRrpbI867ATPRiqpS+v7kOaz8nMNOJG1d5Q5H2fxCy5EjiBzmp3/NTJll32QI E5fofqiiZIgLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1752826228; x=1753086728; i=anthoine.bourgeois@vates.tech; bh=9v3RvNn3og/vnGMjRNCHbK2EsjnkNsgZix1oMc/Rcns=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=KAHN5M6Dkf32LI3IU1rnfS7m35aUHsqdzvOsrzciueBaVGaziil36DDHfpgaQJAlz 3Aq7aVYLnb7KY6XMLbRrqcNPpvZR52pY5/SrvMQ5fGqzC0x0B4ssFRr4YdIljzelNN bInjm8Y5zypb3JEM4XjIIxV4U5zfGHROxsxWiD6GsGwYAov/n6XuUbBTDg9Vkymi00 mAwWCRAxlPDdBXl3cum4+p0G6wm1IMjVlD7+A7X+pTcMIamPSGzBXyIgW1ocnreIfx yck9flQMAMf+dlYIBVNna+05JASz/DmdMnG38Mxc9rN9Q1QDv5cBRhQ6ae0PO/zGOg fcsYG/bRKakbw== From: "Anthoine Bourgeois" Subject: =?utf-8?Q?Re:=20[PATCH=20v2]=20xen/netfront:=20Fix=20TX=20response=20spurious=20interrupts?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1752826227429 To: "Jakub Kicinski" Cc: "Juergen Gross" , "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Wei Liu" , "Paul Durrant" , xen-devel@lists.xenproject.org, netdev@vger.kernel.org, "Elliott Mitchell" Message-Id: References: <20250715160902.578844-2-anthoine.bourgeois@vates.tech> <20250717072951.3bc2122c@kernel.org> In-Reply-To: <20250717072951.3bc2122c@kernel.org> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.fd920aecd9e04b49b126fd14a70e068c?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20250718:md Date: Fri, 18 Jul 2025 08:10:28 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Thu, Jul 17, 2025 at 07:29:51AM -0700, Jakub Kicinski wrote: >On Tue, 15 Jul 2025 16:11:29 +0000 Anthoine Bourgeois wrote: >> Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel storms") > >Not entirely sure who you expect to apply this patch, but if networking >then I wouldn't classify this is a fix. The "regression" happened 4 >years ago. And this patch doesn't seem to be tuning the logic added by >the cited commit. I think this is an optimization, -next material, and >therefore there should be no Fixes tag here. You can refer to the commit >without the tag. Ok, you're right the cited commit exacerbates a problem that was already there before. I will change this in v3. >> @@ -849,9 +847,6 @@ static netdev_tx_t xennet_start_xmit(struct sk_buff *skb, struct net_device *dev >> tx_stats->packets++; >> u64_stats_update_end(&tx_stats->syncp); >> >> - /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */ >> - xennet_tx_buf_gc(queue); >> - >> if (!netfront_tx_slot_available(queue)) >> netif_tx_stop_queue(netdev_get_tx_queue(dev, queue->id)); > >I thought normally reaping completions from the Tx path is done >to prevent the queue from filling up, when the device-generated >completions are slow or the queue is short. I say "normally" but >this is relatively a uncommon thing to do in networking. >Maybe it's my lack of Xen knowledge but it would be good to add to >the commit message why these calls where here in the first place. Good to know how it should "normally" works, I'm not an expert. The patch also has the advantage of standardizing the network driver with other Xen PV drivers that do not have this reponse collection outside of the interrupt handler. As this part of the code is here since the driver was upsteamed and the author no longer works on xen, I will do my best to add my guess on why this code was there. Regards, Anthoine Anthoine Bourgeois | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech