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=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 373ACC47082 for ; Tue, 8 Jun 2021 07:45:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A2496127A for ; Tue, 8 Jun 2021 07:45:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230266AbhFHHrp (ORCPT ); Tue, 8 Jun 2021 03:47:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:42568 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbhFHHro (ORCPT ); Tue, 8 Jun 2021 03:47:44 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 09E3861184 for ; Tue, 8 Jun 2021 07:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623138352; bh=AkUl8Q24/0XKmG2S67RhU07Q4g50X3FT6MduHRZDzyU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DyWzA7ndYEiuQ1awn5A4Yl/dTGFu8uPqgudOYq6SAVZZ3epxd/0V7J64+gzWDm/MB Rtg2+zP1r4rlSI6m7CpOk/Lley2e7LjHThRfBZfPWk8Xt+fLn8PjDBpmhIqDK6seqR wtrUpd9F8R4bTd5Q19OpSElEGRTQAQSBiAzS/oJYY/tGODcy3v6zbvwP1Vdhe0hfU6 yRcDCX6n/UFsPvy8FEUb4uqiEf37oHPMXea32lS5YTumPgRAcHUwdNy+NjXjMISFqh NgZI7psqdG8FfttLppU9NRexmW4WKe8WkOgQnsDMVfxTAM7qebEg+Gb+edEWC0F5AI IVkz37QXUTFNQ== Received: by mail-wm1-f54.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso1060179wmc.1 for ; Tue, 08 Jun 2021 00:45:51 -0700 (PDT) X-Gm-Message-State: AOAM5312M/y1t0oiQKoBdjLaF1cRDaCrgMDKwthEQ1fr19bmGXrWWkj5 mhQ6sUTqciby/8mrkUf6h6x8c7aoxXheAQsbJ4g= X-Google-Smtp-Source: ABdhPJw7eQojZkth660KJeQokoKOzuKw7ZUeqo2yjiAiDJRC3w+i13NNzA6abSZrUFp+ELanfgn4vP2c62MPFqMenKY= X-Received: by 2002:a1c:7d15:: with SMTP id y21mr2739827wmc.120.1623138350627; Tue, 08 Jun 2021 00:45:50 -0700 (PDT) MIME-Version: 1.0 References: <60B24AC2.9050505@gmail.com> <60B2E0FF.4030705@gmail.com> <60B36A9A.4010806@gmail.com> <60B3CAF8.90902@gmail.com> <60B41D00.8050801@gmail.com> <60B514A0.1020701@gmail.com> <60B560A8.8000800@gmail.com> <49f40dd8-da68-f579-b359-7a7e229565e1@gmail.com> <60B611C6.2000801@gmail.com> <60B65BBB.2040507@gmail.com> <60B6C4B2.1080704@gmail.com> <60BEA6CF.9080500@gmail.com> In-Reply-To: <60BEA6CF.9080500@gmail.com> From: Arnd Bergmann Date: Tue, 8 Jun 2021 09:44:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Realtek 8139 problem on 486. To: Nikolai Zhubr Cc: Heiner Kallweit , netdev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jun 8, 2021 at 1:07 AM Nikolai Zhubr wrote: > 02.06.2021 12:12, Arnd Bergmann: > [...] > > I think the easiest workaround to address this reliably would be to move all > > the irq processing into the poll function. This way the interrupt is completely > > masked in the device until the poll handler finishes, and unmasking it > > while there > > are pending events would reliably trigger a new irq regardless of level or edge > > mode. Something like the untested change at https://pastebin.com/MhBJDt6Z . > > I don't know of other drivers that do it like this though, so I'm not > > sure if this causes a different set of problems. > > I started applying your patch (trying to morph it a little bit so as to > shove in a minimally invasive manner into 4.14) and then noticed that it > probably won't work as intended. If I'm not mistaken this rx poll thing > is only active within kind of "rx bursts", so it is not guaranteed to be > continually running all the time when there is no or little rx input. > I'd suppose some new additional work/thread would have to be introduced > in order for such approach to be reliably implemented. The basic idea of the napi poll function is to do batch processing as much as possible and avoid excessive interrupts when the system is already busy processing the received data. However, it should not lead to any missed interrupts with my patch: at any point in time, you have either all hardware interrupts enabled, or you are in napi polling mode and are guaranteed to call the poll function within a relatively short timespan. If you have no pending rx events, processing should be pretty much instantaneous, it just gets pushed from the irq handler to immediately following the irq handler. If there is a constant stream of incoming data, it gets moved into softirqd context, which may be delayed when there is another thread running. Arnd