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
| ||
|
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
Powered by blists - more mailing lists