netdev - Re: [RFC PATCH net-next 1/6] net: implement threaded-able napi poll loop support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEA6p_B3cw0Ae0migRkOyw6t0sXowJ-aOV0eaVxqRcPu9nNQAQ@mail.gmail.com>
Date:   Mon, 28 Sep 2020 11:13:59 -0700
From:   Wei Wang <weiwan@...gle.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     Hannes Frederic Sowa <hannes@...essinduktion.org>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Felix Fietkau <nbd@....name>
Subject: Re: [RFC PATCH net-next 1/6] net: implement threaded-able napi poll
 loop support

On Mon, Sep 28, 2020 at 1:45 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> Hello,
>
> On Sat, 2020-09-26 at 16:22 +0200, Hannes Frederic Sowa wrote:
> > On Sat, Sep 26, 2020, at 01:50, Wei Wang wrote:
> > > I took a look at the current "threadirqs" implementation. From my
> > > understanding, the kthread used there is to handle irq from the
> > > driver, and needs driver-specific thread_fn to be used. It is not
> > > as
> > > generic as in the napi layer where a common napi_poll() related
> > > function could be used as the thread handler. Or did I
> > > misunderstand
> > > your point?
> >
> > Based on my memories: We had napi_schedule & co being invoked inside
> > the threads
>
> I just looked at the code - I really forgot most details. The above is
> correct...
>
> > without touching any driver code when we specified
> > threadirqs. But this would need a double check.
>
> ... but still that code needed some per device driver modification: the
> irq subsystem handled the switch to/from threaded mode, and needed some
> callback, provided from the device driver, to notify the network code
> about the change (specifically, to mark the threaded status inside the
> relevant napi struct).

Thanks for the clarification. This corresponds with my understanding as well.

>
> Cheers,
>
> Paolo
>