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: <f4cb4816d70e480f1b9bc88bfee1ec5d9017d42a.camel@redhat.com>
Date:   Mon, 28 Sep 2020 10:45:35 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Wei Wang <weiwan@...gle.com>
Cc:     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

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).

Cheers,

Paolo