From: "Rakesh Pillai" <pillair@codeaurora.org> To: "'David Laight'" <David.Laight@ACULAB.COM>, "'Sebastian Gottschall'" <s.gottschall@dd-wrt.com>, "'Hillf Danton'" <hdanton@sina.com> Cc: "'Andrew Lunn'" <andrew@lunn.ch>, <netdev@vger.kernel.org>, <linux-wireless@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <ath10k@lists.infradead.org>, <dianders@chromium.org>, "'Markus Elfring'" <Markus.Elfring@web.de>, <evgreen@chromium.org>, <kuba@kernel.org>, <johannes@sipsolutions.net>, <davem@davemloft.net>, <kvalo@codeaurora.org> Subject: RE: [RFC 0/7] Add support to process rx packets in thread Date: Tue, 28 Jul 2020 22:29:02 +0530 [thread overview] Message-ID: <001001d66500$69a58970$3cf09c50$@codeaurora.org> (raw) In-Reply-To: <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com> > -----Original Message----- > From: David Laight <David.Laight@ACULAB.COM> > Sent: Sunday, July 26, 2020 4:46 PM > To: 'Sebastian Gottschall' <s.gottschall@dd-wrt.com>; Hillf Danton > <hdanton@sina.com> > Cc: Andrew Lunn <andrew@lunn.ch>; Rakesh Pillai <pillair@codeaurora.org>; > netdev@vger.kernel.org; linux-wireless@vger.kernel.org; linux- > kernel@vger.kernel.org; ath10k@lists.infradead.org; > dianders@chromium.org; Markus Elfring <Markus.Elfring@web.de>; > evgreen@chromium.org; kuba@kernel.org; johannes@sipsolutions.net; > davem@davemloft.net; kvalo@codeaurora.org > Subject: RE: [RFC 0/7] Add support to process rx packets in thread > > From: Sebastian Gottschall <s.gottschall@dd-wrt.com> > > Sent: 25 July 2020 16:42 > > >> i agree. i just can say that i tested this patch recently due this > > >> discussion here. and it can be changed by sysfs. but it doesnt work for > > >> wifi drivers which are mainly using dummy netdev devices. for this i > > >> made a small patch to get them working using napi_set_threaded > manually > > >> hardcoded in the drivers. (see patch bellow) > > > > By CONFIG_THREADED_NAPI, there is no need to consider what you did > here > > > in the napi core because device drivers know better and are responsible > > > for it before calling napi_schedule(n). > > > yeah. but that approach will not work for some cases. some stupid > > drivers are using locking context in the napi poll function. > > in that case the performance will runto shit. i discovered this with the > > mvneta eth driver (marvell) and mt76 tx polling (rx works) > > for mvneta is will cause very high latencies and packet drops. for mt76 > > it causes packet stop. doesnt work simply (on all cases no crashes) > > so the threading will only work for drivers which are compatible with > > that approach. it cannot be used as drop in replacement from my point of > > view. > > its all a question of the driver design > > Why should it make (much) difference whether the napi callbacks (etc) > are done in the context of the interrupted process or that of a > specific kernel thread. > The process flags (or whatever) can even be set so that it appears > to be the expected 'softint' context. > > In any case running NAPI from a thread will just show up the next > piece of code that runs for ages in softint context. > I think I've seen the tail end of memory being freed under rcu > finally happening under softint and taking absolutely ages. > > David > Hi All, Is the threaded NAPI change posted to kernel ? Is the conclusion of this discussion that " we cannot use threads for processing packets " ?? > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK > Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: "Rakesh Pillai" <pillair@codeaurora.org> To: 'David Laight' <David.Laight@ACULAB.COM>, 'Sebastian Gottschall' <s.gottschall@dd-wrt.com>, 'Hillf Danton' <hdanton@sina.com> Cc: 'Andrew Lunn' <andrew@lunn.ch>, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, dianders@chromium.org, ath10k@lists.infradead.org, linux-kernel@vger.kernel.org, 'Markus Elfring' <Markus.Elfring@web.de>, evgreen@chromium.org, kuba@kernel.org, johannes@sipsolutions.net, davem@davemloft.net, kvalo@codeaurora.org Subject: RE: [RFC 0/7] Add support to process rx packets in thread Date: Tue, 28 Jul 2020 22:29:02 +0530 [thread overview] Message-ID: <001001d66500$69a58970$3cf09c50$@codeaurora.org> (raw) In-Reply-To: <cb54c2746a3d4ce695e3bda8b576b40e@AcuMS.aculab.com> > -----Original Message----- > From: David Laight <David.Laight@ACULAB.COM> > Sent: Sunday, July 26, 2020 4:46 PM > To: 'Sebastian Gottschall' <s.gottschall@dd-wrt.com>; Hillf Danton > <hdanton@sina.com> > Cc: Andrew Lunn <andrew@lunn.ch>; Rakesh Pillai <pillair@codeaurora.org>; > netdev@vger.kernel.org; linux-wireless@vger.kernel.org; linux- > kernel@vger.kernel.org; ath10k@lists.infradead.org; > dianders@chromium.org; Markus Elfring <Markus.Elfring@web.de>; > evgreen@chromium.org; kuba@kernel.org; johannes@sipsolutions.net; > davem@davemloft.net; kvalo@codeaurora.org > Subject: RE: [RFC 0/7] Add support to process rx packets in thread > > From: Sebastian Gottschall <s.gottschall@dd-wrt.com> > > Sent: 25 July 2020 16:42 > > >> i agree. i just can say that i tested this patch recently due this > > >> discussion here. and it can be changed by sysfs. but it doesnt work for > > >> wifi drivers which are mainly using dummy netdev devices. for this i > > >> made a small patch to get them working using napi_set_threaded > manually > > >> hardcoded in the drivers. (see patch bellow) > > > > By CONFIG_THREADED_NAPI, there is no need to consider what you did > here > > > in the napi core because device drivers know better and are responsible > > > for it before calling napi_schedule(n). > > > yeah. but that approach will not work for some cases. some stupid > > drivers are using locking context in the napi poll function. > > in that case the performance will runto shit. i discovered this with the > > mvneta eth driver (marvell) and mt76 tx polling (rx works) > > for mvneta is will cause very high latencies and packet drops. for mt76 > > it causes packet stop. doesnt work simply (on all cases no crashes) > > so the threading will only work for drivers which are compatible with > > that approach. it cannot be used as drop in replacement from my point of > > view. > > its all a question of the driver design > > Why should it make (much) difference whether the napi callbacks (etc) > are done in the context of the interrupted process or that of a > specific kernel thread. > The process flags (or whatever) can even be set so that it appears > to be the expected 'softint' context. > > In any case running NAPI from a thread will just show up the next > piece of code that runs for ages in softint context. > I think I've seen the tail end of memory being freed under rcu > finally happening under softint and taking absolutely ages. > > David > Hi All, Is the threaded NAPI change posted to kernel ? Is the conclusion of this discussion that " we cannot use threads for processing packets " ?? > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK > Registration No: 1397386 (Wales) _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2020-07-28 16:59 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-21 17:14 [RFC 0/7] Add support to process rx packets in thread Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 17:14 ` [RFC 1/7] mac80211: Add check for napi handle before WARN_ON Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-22 12:56 ` Johannes Berg 2020-07-22 12:56 ` Johannes Berg 2020-07-23 18:26 ` Rakesh Pillai 2020-07-23 18:26 ` Rakesh Pillai 2020-07-23 20:06 ` Johannes Berg 2020-07-23 20:06 ` Johannes Berg 2020-07-24 6:21 ` Rakesh Pillai 2020-07-24 6:21 ` Rakesh Pillai 2020-07-26 16:19 ` Rakesh Pillai 2020-07-26 16:19 ` Rakesh Pillai 2020-07-30 12:40 ` Johannes Berg 2020-07-30 12:40 ` Johannes Berg 2020-07-21 17:14 ` [RFC 2/7] ath10k: Add support to process rx packet in thread Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 21:53 ` Rajkumar Manoharan 2020-07-21 21:53 ` Rajkumar Manoharan 2020-07-22 12:27 ` Felix Fietkau 2020-07-22 12:27 ` Felix Fietkau 2020-07-22 12:55 ` Johannes Berg 2020-07-22 12:55 ` Johannes Berg 2020-07-22 13:00 ` Felix Fietkau 2020-07-22 13:00 ` Felix Fietkau 2020-07-23 6:09 ` Rajkumar Manoharan 2020-07-23 6:09 ` Rajkumar Manoharan 2021-03-22 23:57 ` Ben Greear 2021-03-22 23:57 ` Ben Greear 2021-03-23 1:20 ` Brian Norris 2021-03-23 1:20 ` Brian Norris 2021-03-23 3:01 ` Ben Greear 2021-03-23 3:01 ` Ben Greear 2021-03-23 7:45 ` Felix Fietkau 2021-03-23 7:45 ` Felix Fietkau 2021-03-25 9:45 ` Rakesh Pillai 2021-03-25 9:45 ` Rakesh Pillai 2021-03-25 10:33 ` Felix Fietkau 2021-03-25 10:33 ` Felix Fietkau 2020-07-23 18:25 ` Rakesh Pillai 2020-07-23 18:25 ` Rakesh Pillai 2020-07-24 23:11 ` Jacob Keller 2020-07-24 23:11 ` Jacob Keller 2020-07-21 17:14 ` [RFC 3/7] ath10k: Add module param to enable rx thread Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 17:14 ` [RFC 4/7] ath10k: Do not exhaust budget on process tx completion Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 17:14 ` [RFC 5/7] ath10k: Handle the rx packet processing in thread Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 17:14 ` [RFC 6/7] ath10k: Add deliver to stack from thread context Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-21 17:14 ` [RFC 7/7] ath10k: Handle rx thread suspend and resume Rakesh Pillai 2020-07-21 17:14 ` Rakesh Pillai 2020-07-23 23:06 ` Sebastian Gottschall 2020-07-23 23:06 ` Sebastian Gottschall 2020-07-24 6:19 ` Rakesh Pillai 2020-07-24 6:19 ` Rakesh Pillai 2020-07-21 17:25 ` [RFC 0/7] Add support to process rx packets in thread Andrew Lunn 2020-07-21 17:25 ` Andrew Lunn 2020-07-21 18:05 ` Florian Fainelli 2020-07-21 18:05 ` Florian Fainelli 2020-07-23 18:21 ` Rakesh Pillai 2020-07-23 18:21 ` Rakesh Pillai 2020-07-23 19:02 ` Florian Fainelli 2020-07-23 19:02 ` Florian Fainelli 2020-07-24 6:20 ` Rakesh Pillai 2020-07-24 6:20 ` Rakesh Pillai 2020-07-24 22:28 ` Florian Fainelli 2020-07-24 22:28 ` Florian Fainelli 2020-07-22 9:12 ` David Laight 2020-07-22 9:12 ` David Laight 2020-07-25 8:16 ` Hillf Danton 2020-07-25 10:38 ` Sebastian Gottschall 2020-07-25 10:38 ` Sebastian Gottschall 2020-07-25 12:25 ` Hillf Danton 2020-07-25 14:08 ` Sebastian Gottschall 2020-07-25 14:08 ` Sebastian Gottschall 2020-07-25 14:57 ` Hillf Danton 2020-07-25 15:41 ` Sebastian Gottschall 2020-07-25 15:41 ` Sebastian Gottschall 2020-07-26 11:16 ` David Laight 2020-07-26 11:16 ` David Laight 2020-07-28 16:59 ` Rakesh Pillai [this message] 2020-07-28 16:59 ` Rakesh Pillai 2020-07-29 1:34 ` Hillf Danton 2020-07-25 17:57 ` Felix Fietkau 2020-07-25 17:57 ` Felix Fietkau 2020-07-26 1:22 ` Hillf Danton 2020-07-26 8:10 ` Felix Fietkau 2020-07-26 8:10 ` Felix Fietkau 2020-07-26 8:32 ` Hillf Danton 2020-07-26 8:59 ` Felix Fietkau 2020-07-26 8:59 ` Felix Fietkau 2020-07-22 16:20 ` Jakub Kicinski 2020-07-22 16:20 ` Jakub Kicinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='001001d66500$69a58970$3cf09c50$@codeaurora.org' \ --to=pillair@codeaurora.org \ --cc=David.Laight@ACULAB.COM \ --cc=Markus.Elfring@web.de \ --cc=andrew@lunn.ch \ --cc=ath10k@lists.infradead.org \ --cc=davem@davemloft.net \ --cc=dianders@chromium.org \ --cc=evgreen@chromium.org \ --cc=hdanton@sina.com \ --cc=johannes@sipsolutions.net \ --cc=kuba@kernel.org \ --cc=kvalo@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=s.gottschall@dd-wrt.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.