From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 618BC3EFD37 for ; Fri, 27 Feb 2026 13:03:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772197439; cv=none; b=tqd7B0WYqaF961owq6VB3YcTk2P2LfeBpMBOks8aAWuWUcrC+RF4CkeVPkmUxpDBLZIz0jzqOyneekJyYY62AMVc7wPXF4837Nxiogx0ynZLqyXIS0NcwvDLg2xqsQgeW8QvH14LZ0dGBRVWn2+61I9XdzH/qOvWaz67BhyMs84= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772197439; c=relaxed/simple; bh=QxRNqrOWtY4W9PsVH/ATqeFPXiahp4CeK11M6wq/n98=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RYRpg4scFYk6OglnOJxYhoYRhl+ykWq1bbyomAkvbr6FVQMY+GqH9HnRSkt+mDDJrsQ0Kr+mUutHvUIWVi1kc+1WoMlp41YXzxTthSsnRqgPooP1/2sZmNvOiDNP9WjsyHAWT3oPdz27ZVAwrmfSHHQ2dWuLYot+dgSAOM7PZsI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lRkqP5R9; arc=none smtp.client-ip=209.85.218.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lRkqP5R9" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-b932fe2e1a7so284624066b.1 for ; Fri, 27 Feb 2026 05:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772197437; x=1772802237; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=290JGGfAoFlThz6wF0wfNkvuCjanUoBb4lMREKo2BoM=; b=lRkqP5R91yknEYSPmmgKqMAGrtrQVWMND6r+g7wnG2BzIt5wsAyGTPyo1qaOIZFVn9 izVzoObWmyboEqTWim40L5NeAwc5JYrLhAweIzxYpaU8VT2rYIqxqvjEYkpraoGRzXdE dSEogKl3n3zJu+BjjhrXuUjI2GSvFKu8aiixBPE2kdkPc/smH0BuSRoVI+6dwTFyvmU/ Fl9wKy+24R2cVM/N1SppLJ91lBYI5lsWR3tUil6zilTIyb4DX54t1xcwFaKBlwYYymZj nQtlB7jbu+MSHMSDZE/s+zsfeG783N3fDqF/MvPL8a4vuK7QDwISQFs8HCOwX4BjeUit PDow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772197437; x=1772802237; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=290JGGfAoFlThz6wF0wfNkvuCjanUoBb4lMREKo2BoM=; b=QRjFhT47iSe/Kw9UcSDPz/QD+x7eFqqkMf1yISwHBi4xZcpYNR3soE54aBvY1tjaYm 2CuyanzhvT/IC0ngiFF3stgTkSiQ8qe6+wtdneJFgO0g7yxS39iAgQ5aaDv7JD0iFrow uhDMrz+jwH9mD8luryKAIdn638dCLKJv9Ls4Wzyy55oP4wBBjNl8fNdDx/ttn9sDsspG 9o9x3wNLI/++svKeNh3v7FqoV4nDbnN2675UrdW8ROtkWCAQ/EIicKTw9tql8oOFXmea 9AkOyRHpkltXViBX8j0AS7AwAIVlWXlHoJTcDi6DcHqsmx6zoE2OL915VRWCF81sePX1 VwtA== X-Forwarded-Encrypted: i=1; AJvYcCUnZM8sfyYhJw5WOErwgXs1yyzBvyuoWWV5Fnnk0ckxu8R2DU1B0D2wvdqArSD6YUGS4kQ7vi0RnuTCF14=@vger.kernel.org X-Gm-Message-State: AOJu0YyqfmLidJIOuC5fLFJEKekFw4xAJfgd1KHpnB76qCj9FmghJbB5 1UuHPUKTKnibLk9rN0u4rPKQcBGpfK668aVhM3D/fohnFPVwDwdfptEd X-Gm-Gg: ATEYQzwsynHWUJYoQmU/mwuZmMFGekBPpbgH3jlc/sFpmcfqkmruEz8bEHpKCo0NGtg 7hv8T4GXVrJTjK+8domr7OLysnU3prCFKG/7KFjMaJaEmp5dXoXobrjbzVHWc3CcPZUghu3kFAW T/pyyUFVh1Z2+7OuSEUDCvj9J6fMfsXok501O4PUDyr4jdzQgFAPcxpjJFdCG+z+HOd2MJD5Pdb sU2yAfg//ZcqKex3u8sBi8u08STJh3cSzRVWHtaDWT5vs9+5Wp42vJmmYQKnascgOlEtVaGL9wY YEdx+1SRUlj0dmuyFXrnT9RJ1em+n89M/3LJ+JtsOLDVOj2gXFY4PsmGiRgNhjtWjgsfnNcU2PH 4BAdGPpkxEjP1KgZCT4k9bdb5XCzISjYV3vL5gsZJg4QcivdtACpaxoWVFxzl+7h7efAHmalT3r aUiQuDb3wWAs9z0Zr1+3an7qOPQbsGKXI54J4dulzRfB+cgUPVTJmHYFEP8uQHlEZxsBEMig== X-Received: by 2002:a17:907:787:b0:b87:718:5da2 with SMTP id a640c23a62f3a-b937637a69amr164082366b.1.1772197436358; Fri, 27 Feb 2026 05:03:56 -0800 (PST) Received: from [192.168.178.48] (80-218-237-147.dclient.hispeed.ch. [80.218.237.147]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ae65662sm147297066b.41.2026.02.27.05.03.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Feb 2026 05:03:55 -0800 (PST) Message-ID: <53f850f9-8f05-49ba-9247-ef2f823cc2b2@gmail.com> Date: Fri, 27 Feb 2026 14:03:54 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] net: enetc: fix sirq-storm by clearing IDR registers To: Vladimir Oltean Cc: claudiu.manoil@nxp.com, wei.fang@nxp.com, xiaoning.wang@nxp.com, davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Zefir Kurtisi References: <20260220132930.2521155-1-zefir.kurtisi@gmail.com> <20260223163227.y3yzzpncyf5a7klq@skbuf> <20260226195158.sagjq3hgs6l64w2u@skbuf> <20260220132930.2521155-1-zefir.kurtisi@gmail.com> <20260223163227.y3yzzpncyf5a7klq@skbuf> <20260226195158.sagjq3hgs6l64w2u@skbuf> <786338e0-0a6b-4b7b-9e22-8253bb655aec@gmail.com> <786338e0-0a6b-4b7b-9e22-8253bb655aec@gmail.com> <20260227115708.lkpbea3b24ztdsgl@skbuf> Content-Language: en-US From: Zefir Kurtisi Autocrypt: addr=zefir.kurtisi@gmail.com; keydata= xsFNBE3rwDkBEACqmSp0GQXGTXO4J/7pGj+kHxlS8V96OH5kUAfTnVq1tFNxterPmCtlPqfE GJTy1MrH8eo+DAdRtBSExabf0pXiZeP3xlpnQ//L5QbQ//6LMV5uiGW3E+jgspvboWrr37Xb CbppRje0Ok0XJolKuXtmnT0NZ3wa8N4vhlGmfwM+7n9wRtGw1bRuWb43em/EWK9UiTs/QPY6 wQQTFLT5N6xSKP0xBzpXz9N/VldaNYbTaurKgAnVFiLHQLYDRg18Jx3F0kFoTXIFa9ba2MMu OzLGSZypEOg+SVg5zRBLXbCY4PS7jJ6k+sY9yGiw6KG36lvoGp97mQB1X20McI8WTD84t+LB DyCy8OsZXriBxDGwgkpd/y9z+teClYqx0HJ+R5Fr/wFVaAApERPeNbzvhKR0LRI9lBvbFyd+ JCZ4fQDuWEwTQEEY97+CKdr0vWFwx8RBf8eplNzOQvx/BMBu2q03NDHHipKQSYW0ZGcmq/x9 kn0L1Fisg0mPq5Z8XbXuE9WSXySYXogJLw0kFCouQE7Kvfo04Do2vX+CS9ZrQbZkCDhd8sik J7JEskD43Wt+VhN3xRSM4VLdMrTtBuKDMYEAm8V+HHO3PFct45zymnvtHso/VtriU8poE8l4 NjrqFbKPZsGPTXdZXgRmzcaOkMRM1gAoZpC/ZekqQdqouCJUywARAQABzSdaZWZpciBLdXJ0 aXNpIDx6ZWZpci5rdXJ0aXNpQGdtYWlsLmNvbT7CwXgEEwECACIFAlE7DLoCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAAoJEN6md73WDkYsOtYP/RlQUkqfO1XYjg9I5LBVMqOEcKCl sgNPkgqiCHu2PrwV9W8bKK4zG0g71HY8kLkdN7rolP0KR+WmLqBAv6XNqXuaz8dEAupRO9Fc M+fxtrhdhqjlxXww0DbKeYahoQ62pB9pnkhC6u/MzST7hQenxT2eqRZtDR7Hpx4xWQNgbWH7 uyJhAYW5BUi35enDHuBvvgXblvCCjm0QTqN1xr4GkU2luch8Xf9/8kUbuLwbe5eivBdyozLs 1u8UEc9+OGfWKBenAOqZMis+21aJD83PGsCWIUgepa42YY4sezawch2wKJfEHW3dYrs3CdeG SYP0U+31aGFyb70XOX/N+G0ZzPUPBTLRKnDxG2OMkYFfO2eiKe2zm1L/tpw0U9TdZbennTC1 7ulJEB1zsIQSMqUUsw1h0aIS9X3k7SxlknjYa+Z3dYtf1vxsqvw2xmZ4N1FpMk8ljx9QwNtD lgQlI2fgsFHNSeaNbUULGfI+CXUZ3jPTpw3zvQGD35MNaeZ4agrTcFa/shs6f+2H/9kOl4ok mc3n41lqpvzWaA3GKGHUOoNbrjj/vaLrYSofPWyMX+iLFGFt0+ewQmPchWMpIjtB8Sx+2pMY jrqfU26alWwuXkQqIEiGEP8YkZtnCNrCIcE0lYcQ4agUTmyqo3jTv6SRDYeZzBkQOOtyuwKl RK4OgCv9zsFNBE3rwDkBEACkyTE78ZpoUXw+n2QPTDEUvY5Yxgj8fznLcSrUfkAf77rM86ob wPS5xvJpbxHABbsHZyI7Abk/7RKmmSZ38aaxW8+3h48YdGIyKcpDq3DkgZKhNri1LWyJ3X4G 2Hkl+LoxefadmztnsWlqVum5CHqpuwgOrwr4SFwBPQ4mHzVNR0zb4bPdU9/emaFziW6taj6E emSyVO7BP5SQAlqmLyMXTdI/95mGnAtgethMSjy3+PdvAvyMxOLqgFNgZXa8jjxmuCtwS4N3 41qFIeAGncLI9s28E3YitXxQaAYbW3Suzt0RQEHd5kjoJWx2T9oJBap81t9/kxNWyDwTNkRD RtnxWRD/stXYB6d0KpG5skqRtkTrs6daZ/Z+nxyQb4BH/N6ATuwhhnmjDwLhe7rH6B2WuBPn 5BWgGybf2BlcMNnOllFOa2fSii8PF/uqivUi8QG/5wjBLzQxGfw11Ry/5jbsjljubzrDSjX2 KAqlI+zWkBUJz51RZEdiy2Q+8haurSvpV64DQRWFHXNlCLyoC6dgen+14t8OS73eKJxHlqVC oCsE8WaJeADc0Ty8xYbfzaZZzL1KuKJQiNf3wpDDEIIc+YEWKnWJ6uN8PY45B7ionbXBsrmT jEwSX4A2VIT83tp3BqtR2eD92/iwOo8Nk/23kjtFHQLh+TZiIsVprBXEVwARAQABwsFfBBgB AgAJBQJN68A5AhsMAAoJEN6md73WDkYsb5wP/3KRQ/eJGu2i1KVmw4fCQm0aSOQXDamnMPGQ qJj9XomyYyXLN/PkPhu2iBMVDxaqlou2z8OqlsjHw/0RPZet0AziBRRRKrwbnfKNg7y8CtOr Um1UM3U9i87rjDHveV//D5jZWNRyK9Vx6GjS5foJkC7wnS5VeV6Y86tqNxIcJIjUr6/u86Dd bxdGWyR9rjf4AvXxt4g51X0lB0PpLkZxgvDa7bZAfDH+jGbKvd1oCxmTw2UMQpaY/psbxtRK nPpoVvWhwd5skZMqco9ptLBq5RFnNSEJERx8u1NpFbJ+Co6QFIhVg284XUA850iDSDwGzEqU vAErstsk109xfJ6PqQWKXuCVxcCWTHyWQtcBISvXe4NIVWeLK9iPMKIAWvHp9IEiYKmy1XaZ zEQNeNBIuxgv2J/xzpxM1kb95Dzf4DhLT5qPBFsQyRvd9eUWQRghuOhI0e2nORYlwNfuI7+7 pLdgxnV4PgOBEXQYWLe/PXNLFcATcVyykj3UppMsqUUIbJqSV3A5q2McRe1S+ShY684Cq+ht HrLM4M8YG9cNPG3W1vbX3w/EgxmxvfQ8xjDmzOYF1C/IddWeIyUFRl9ii22q8gY0Ka/gc6nP HD4hTu77qdJmepjje6wGHCBvxidwiZfJ2UWHp9Bkof5iEDiyVzqIT6OGymi51Fe9Ye4f5s1Y In-Reply-To: <20260227115708.lkpbea3b24ztdsgl@skbuf> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/27/26 12:57, Vladimir Oltean wrote: > On Fri, Feb 27, 2026 at 12:28:17PM +0100, Zefir Kurtisi wrote: >> While I was debugging the issue I extended enetc with features that still >> might be useful; the first change was to selectively process only the >> pending BDs instead of looping over all available, saving a significant >> number of unneeded calls to enetc_clean_rx/tx_ring(); the second adds a >> fail-safe mechanism for potentially other issues taking the same code path >> based on the fact that now a BD is only processed when its IDR is active, >> which means there must be BDs available to process. > > We'll perform our own investigation of what is happening when > transmitting short frames. It will take some time. > > But I'm not sure I understand what you mean about processing a BD ring > when its interrupt is active. NAPI (Documentation/networking/napi.rst) > works on the basic premise that a single hardirq is sufficient to process > a very large batch of frames, and keeping hardirqs enabled is detrimential > to performance. Instead, NAPI (re-)schedules softirqs until there are no > further frames to process, and only then re-enables the hardirq. > > Perhaps I didn't understand very well what you mean, but it sounds like > you want to circumvent NAPI, essentially. When enetc_poll() is called, > you seem to assume it's the first time it's been called after enetc_msix() > has called napi_schedule(). But it's not. It can also reschedule itself, > when the work done is equal to the NAPI budget (complete==false), with > the hardirq _still_ masked. > > The correct NAPI behaviour _is_ for the hardirq to be masked for a very > long while, when subject to continuous streams of traffic. The change proposed does in no way change how and when interrupts are re-enabled or NAPI is re-scheduled. What it does is: assume there are completed RX frames, but no completed TX frames: SIRXIDR=0x0001, SITXIDR=0x0000 enetc_poll today does: * enetc_clean_tx_ring(0) -> nop * read TB0CIR and find out it did not progress * enetc_clean_tx_ring(2) -> nop * enetc_clean_tx_ring(4) -> nop * enetc_clean_tx_ring(6) -> nop * enetc_clean_rx_ring(0) Proposal instead: as long as SITXIDR==0x0000, limit to * enetc_clean_rx_ring(0) IRQ remains masked until NAPI is completed, behaviour is same as before. If there was an RX burst and NAPI is re-scheduled multiple times and during that time a TX BD completes, the SITXIDR would get the related bit set and TX BD would be processed in enetc_poll - all before the interrupt is re-armed. But if the improvement is not obvious, it maybe does not justify adding the change - in the end it spares some function calls and register reads, which might not be that significant. Cheers, Zefir