All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hillf Danton <hdanton@sina.com>
To: Felix Fietkau <nbd@nbd.name>
Cc: Andrew Lunn <andrew@lunn.ch>, Hillf Danton <hdanton@sina.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Ding Zhao Nan <oshack@hotmail.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>,
	"dianders@chromium.org" <dianders@chromium.org>,
	David Laight <David.Laight@ACULAB.COM>,
	Rakesh Pillai <pillair@codeaurora.org>,
	"evgreen@chromium.org" <evgreen@chromium.org>,
	"kuba@kernel.org" <kuba@kernel.org>,
	Markus Elfring <Markus.Elfring@web.de>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"kvalo@codeaurora.org" <kvalo@codeaurora.org>
Subject: Re: [RFC 0/7] Add support to process rx packets in thread
Date: Sun, 26 Jul 2020 09:22:44 +0800	[thread overview]
Message-ID: <20200726012244.15264-1-hdanton@sina.com> (raw)
In-Reply-To: <a50ebfba-9733-48db-c90b-5fc106e67f29@nbd.name>


Hi Felix,

On Sat, 25 Jul 2020 19:57:23 +0200 Felix Fietkau wrote:
> On 2020-07-25 10:16, Hillf Danton wrote:
> > Hi folks
> > 
> > Below is a minimunm poc implementation I can imagine on top of workqueue
> > to make napi threaded. Thoughts are appreciated.
> > 
> Hi Hillf,
> 
> For some reason I don't see your mails on linux-wireless/netdev.

All is down to my inbox ...

> I've cleaned up your implementation a bit and I ran some tests with mt76
> on an mt7621 embedded board. The results look pretty nice, performance
> is a lot more consistent in my tests now.

Thanks very much for your cleanup and testing.

> Here are the changes that I've made compared to your version:
> 
> - remove the #ifdef, I think it's unnecessary

This makes the code a mile nicer and perhaps I fear pulls some questions
from EricD.

> - add a state bit for threaded NAPI
> - make netif_threaded_napi_add inline
> - run queue_work outside of local_irq_save/restore (it does that
> internally already)
>
> If you don't mind, I'd like to propose this to netdev soon. Can I have
> your Signed-off-by for that?

Feel free to do that. Is it likely for me to select a Cc?

Thanks
Hillf

> Thanks,
> 
> - Felix
> 
> ---
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -347,6 +347,7 @@ struct napi_struct {
>  	struct list_head	dev_list;
>  	struct hlist_node	napi_hash_node;
>  	unsigned int		napi_id;
> +	struct work_struct	work;
>  };
>  
>  enum {
> @@ -357,6 +358,7 @@ enum {
>  	NAPI_STATE_HASHED,	/* In NAPI hash (busy polling possible) */
>  	NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
>  	NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
> +	NAPI_STATE_THREADED,	/* Use threaded NAPI */
>  };
>  
>  enum {
> @@ -367,6 +369,7 @@ enum {
>  	NAPIF_STATE_HASHED	 = BIT(NAPI_STATE_HASHED),
>  	NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
>  	NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
> +	NAPIF_STATE_THREADED	 = BIT(NAPI_STATE_THREADED),
>  };
>  
>  enum gro_result {
> @@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct net_device *dev)
>  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  		    int (*poll)(struct napi_struct *, int), int weight);
>  
> +/**
> + *	netif_threaded_napi_add - initialize a NAPI context
> + *	@dev:  network device
> + *	@napi: NAPI context
> + *	@poll: polling function
> + *	@weight: default weight
> + *
> + * This variant of netif_napi_add() should be used from drivers using NAPI
> + * with CPU intensive poll functions.
> + * This will schedule polling from a high priority workqueue that
> + */
> +static inline void netif_threaded_napi_add(struct net_device *dev,
> +					   struct napi_struct *napi,
> +					   int (*poll)(struct napi_struct *, int),
> +					   int weight)
> +{
> +	set_bit(NAPI_STATE_THREADED, &napi->state);
> +	netif_napi_add(dev, napi, poll, weight);
> +}
> +
>  /**
>   *	netif_tx_napi_add - initialize a NAPI context
>   *	@dev:  network device
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
>  struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
>  struct list_head ptype_all __read_mostly;	/* Taps */
>  static struct list_head offload_base __read_mostly;
> +static struct workqueue_struct *napi_workq;

Is __read_mostly missing?

>  static int netif_rx_internal(struct sk_buff *skb);
>  static int call_netdevice_notifiers_info(unsigned long val,
> @@ -6286,6 +6287,11 @@ void __napi_schedule(struct napi_struct *n)
>  {
>  	unsigned long flags;
>  
> +	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
> +		queue_work(napi_workq, &n->work);
> +		return;
> +	}
> +
>  	local_irq_save(flags);
>  	____napi_schedule(this_cpu_ptr(&softnet_data), n);
>  	local_irq_restore(flags);
> @@ -6333,6 +6339,11 @@ EXPORT_SYMBOL(napi_schedule_prep);
>   */
>  void __napi_schedule_irqoff(struct napi_struct *n)
>  {
> +	if (test_bit(NAPI_STATE_THREADED, &n->state)) {
> +		queue_work(napi_workq, &n->work);
> +		return;
> +	}
> +
>  	____napi_schedule(this_cpu_ptr(&softnet_data), n);
>  }
>  EXPORT_SYMBOL(__napi_schedule_irqoff);
> @@ -6601,6 +6612,29 @@ static void init_gro_hash(struct napi_struct *napi)
>  	napi->gro_bitmask = 0;
>  }
>  
> +static void napi_workfn(struct work_struct *work)
> +{
> +	struct napi_struct *n = container_of(work, struct napi_struct, work);
> +
> +	for (;;) {
> +		if (!test_bit(NAPI_STATE_SCHED, &n->state))
> +			return;
> +
> +		if (n->poll(n, n->weight) < n->weight)
> +			return;
> +
> +		if (need_resched()) {
> +			/*
> +			 * have to pay for the latency of task switch even if
> +			 * napi is scheduled
> +			 */
> +			if (test_bit(NAPI_STATE_SCHED, &n->state))
> +				queue_work(napi_workq, work);
> +			return;
> +		}
> +	}
> +}
> +
>  void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  		    int (*poll)(struct napi_struct *, int), int weight)
>  {
> @@ -6621,6 +6655,7 @@ void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>  #ifdef CONFIG_NETPOLL
>  	napi->poll_owner = -1;
>  #endif
> +	INIT_WORK(&napi->work, napi_workfn);
>  	set_bit(NAPI_STATE_SCHED, &napi->state);
>  	napi_hash_add(napi);
>  }
> @@ -10676,6 +10711,10 @@ static int __init net_dev_init(void)
>  		sd->backlog.weight = weight_p;
>  	}
>  
> +	napi_workq = alloc_workqueue("napi_workq", WQ_UNBOUND | WQ_HIGHPRI,
> +				     WQ_UNBOUND_MAX_ACTIVE);
> +	BUG_ON(!napi_workq);
> +
>  	dev_boot_phase = 0;
>  
>  	/* The loopback device is special if any other network devices
> 


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2020-07-26  1:23 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
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 [this message]
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=20200726012244.15264-1-hdanton@sina.com \
    --to=hdanton@sina.com \
    --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=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=oshack@hotmail.com \
    --cc=pillair@codeaurora.org \
    /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: link
Be 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.