From: Jakub Kicinski <kuba@kernel.org>
To: Ahmed Zaki <ahmed.zaki@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
andrew+netdev@lunn.ch, edumazet@google.com, horms@kernel.org,
pabeni@redhat.com, davem@davemloft.net,
michael.chan@broadcom.com, tariqt@nvidia.com,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
jdamato@fastly.com, shayd@nvidia.com, akpm@linux-foundation.org,
shayagr@amazon.com, kalesh-anakkur.purayil@broadcom.com,
pavan.chebbi@broadcom.com, yury.norov@gmail.com,
darinzon@amazon.com
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/6] net: move ARFS rmap management to core
Date: Tue, 14 Jan 2025 14:08:13 -0800 [thread overview]
Message-ID: <20250114140813.5a7d527f@kernel.org> (raw)
In-Reply-To: <20250113171042.158123-2-ahmed.zaki@intel.com>
On Mon, 13 Jan 2025 10:10:37 -0700 Ahmed Zaki wrote:
> -#endif /* CONFIG_RFS_ACCEL */
> + return netif_enable_cpu_rmap(adapter->netdev, adapter->num_io_queues);
> +#else
> return 0;
> +#endif /* CONFIG_RFS_ACCEL */
Let's try to eliminate some of the ifdef-ery on the driver side.
netif_enable_cpu_rmap() should simply do nothing if !CONFIG_RFS_ACCEL
> @@ -2398,6 +2401,9 @@ struct net_device {
> struct lock_class_key *qdisc_tx_busylock;
> bool proto_down;
> bool threaded;
> +#ifdef CONFIG_RFS_ACCEL
> + bool rx_cpu_rmap_auto;
> +#endif
similar point, don't hide it, it's just one byte and we can just leave
it as false if !CONFIG_RFS_ACCEL. It can save us a bunch of other ifdefs
> +#ifdef CONFIG_RFS_ACCEL
> +static void netif_disable_cpu_rmap(struct net_device *dev)
> +{
> + free_irq_cpu_rmap(dev->rx_cpu_rmap);
> + dev->rx_cpu_rmap = NULL;
> + dev->rx_cpu_rmap_auto = false;
> +}
Better do do:
static void netif_disable_cpu_rmap(struct net_device *dev)
{
#ifdef CONFIG_RFS_ACCEL
free_irq_cpu_rmap(dev->rx_cpu_rmap);
dev->rx_cpu_rmap = NULL;
dev->rx_cpu_rmap_auto = false;
#endif
}
IOW if not relevant the function should do nothing
> +int netif_enable_cpu_rmap(struct net_device *dev, unsigned int num_irqs)
> +{
> + dev->rx_cpu_rmap = alloc_irq_cpu_rmap(num_irqs);
> + if (!dev->rx_cpu_rmap)
> + return -ENOMEM;
> +
> + dev->rx_cpu_rmap_auto = true;
> + return 0;
> +}
> +EXPORT_SYMBOL(netif_enable_cpu_rmap);
here you can depend on dead code elimination:
int netif_enable_cpu_rmap(struct net_device *dev, unsigned int num_irqs)
{
if (!IS_ENABLED(CONFIG_RFS_ACCEL))
return 0;
...
}
> +#endif
> +
> +void netif_napi_set_irq(struct napi_struct *napi, int irq)
> +{
> +#ifdef CONFIG_RFS_ACCEL
> + int rc;
> +#endif
> + napi->irq = irq;
> +
> +#ifdef CONFIG_RFS_ACCEL
> + if (napi->dev->rx_cpu_rmap && napi->dev->rx_cpu_rmap_auto) {
> + rc = irq_cpu_rmap_add(napi->dev->rx_cpu_rmap, irq);
> + if (rc) {
> + netdev_warn(napi->dev, "Unable to update ARFS map (%d)\n",
> + rc);
> + netif_disable_cpu_rmap(napi->dev);
> + }
> + }
> +#endif
Declare rc inside the if to avoid the extra ifdef on variable decl
> +}
> +EXPORT_SYMBOL(netif_napi_set_irq);
> +
> static void napi_restore_config(struct napi_struct *n)
> {
> n->defer_hard_irqs = n->config->defer_hard_irqs;
> @@ -11421,6 +11461,10 @@ void free_netdev(struct net_device *dev)
> /* Flush device addresses */
> dev_addr_flush(dev);
>
> +#ifdef CONFIG_RFS_ACCEL
> + if (dev->rx_cpu_rmap && dev->rx_cpu_rmap_auto)
don't check dev->rx_cpu_rmap, dev->rx_cpu_rmap_auto is enough
> + netif_disable_cpu_rmap(dev);
> +#endif
> list_for_each_entry_safe(p, n, &dev->napi_list, dev_list)
> netif_napi_del(p);
>
IRQs are often allocated in ndo_open and freed in ndo_stop, so
you need to catch netif_napi_del or napi_disable and remove
the IRQ from the map.
Similarly netif_napi_set_irq() may get called with -1 to clear
the IRQ number, which you currently treat at a real IRQ id, AFAICT.
--
pw-bot: cr
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Ahmed Zaki <ahmed.zaki@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
andrew+netdev@lunn.ch, edumazet@google.com, horms@kernel.org,
pabeni@redhat.com, davem@davemloft.net,
michael.chan@broadcom.com, tariqt@nvidia.com,
anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
jdamato@fastly.com, shayd@nvidia.com, akpm@linux-foundation.org,
shayagr@amazon.com, kalesh-anakkur.purayil@broadcom.com,
pavan.chebbi@broadcom.com, yury.norov@gmail.com,
darinzon@amazon.com
Subject: Re: [PATCH net-next v5 1/6] net: move ARFS rmap management to core
Date: Tue, 14 Jan 2025 14:08:13 -0800 [thread overview]
Message-ID: <20250114140813.5a7d527f@kernel.org> (raw)
In-Reply-To: <20250113171042.158123-2-ahmed.zaki@intel.com>
On Mon, 13 Jan 2025 10:10:37 -0700 Ahmed Zaki wrote:
> -#endif /* CONFIG_RFS_ACCEL */
> + return netif_enable_cpu_rmap(adapter->netdev, adapter->num_io_queues);
> +#else
> return 0;
> +#endif /* CONFIG_RFS_ACCEL */
Let's try to eliminate some of the ifdef-ery on the driver side.
netif_enable_cpu_rmap() should simply do nothing if !CONFIG_RFS_ACCEL
> @@ -2398,6 +2401,9 @@ struct net_device {
> struct lock_class_key *qdisc_tx_busylock;
> bool proto_down;
> bool threaded;
> +#ifdef CONFIG_RFS_ACCEL
> + bool rx_cpu_rmap_auto;
> +#endif
similar point, don't hide it, it's just one byte and we can just leave
it as false if !CONFIG_RFS_ACCEL. It can save us a bunch of other ifdefs
> +#ifdef CONFIG_RFS_ACCEL
> +static void netif_disable_cpu_rmap(struct net_device *dev)
> +{
> + free_irq_cpu_rmap(dev->rx_cpu_rmap);
> + dev->rx_cpu_rmap = NULL;
> + dev->rx_cpu_rmap_auto = false;
> +}
Better do do:
static void netif_disable_cpu_rmap(struct net_device *dev)
{
#ifdef CONFIG_RFS_ACCEL
free_irq_cpu_rmap(dev->rx_cpu_rmap);
dev->rx_cpu_rmap = NULL;
dev->rx_cpu_rmap_auto = false;
#endif
}
IOW if not relevant the function should do nothing
> +int netif_enable_cpu_rmap(struct net_device *dev, unsigned int num_irqs)
> +{
> + dev->rx_cpu_rmap = alloc_irq_cpu_rmap(num_irqs);
> + if (!dev->rx_cpu_rmap)
> + return -ENOMEM;
> +
> + dev->rx_cpu_rmap_auto = true;
> + return 0;
> +}
> +EXPORT_SYMBOL(netif_enable_cpu_rmap);
here you can depend on dead code elimination:
int netif_enable_cpu_rmap(struct net_device *dev, unsigned int num_irqs)
{
if (!IS_ENABLED(CONFIG_RFS_ACCEL))
return 0;
...
}
> +#endif
> +
> +void netif_napi_set_irq(struct napi_struct *napi, int irq)
> +{
> +#ifdef CONFIG_RFS_ACCEL
> + int rc;
> +#endif
> + napi->irq = irq;
> +
> +#ifdef CONFIG_RFS_ACCEL
> + if (napi->dev->rx_cpu_rmap && napi->dev->rx_cpu_rmap_auto) {
> + rc = irq_cpu_rmap_add(napi->dev->rx_cpu_rmap, irq);
> + if (rc) {
> + netdev_warn(napi->dev, "Unable to update ARFS map (%d)\n",
> + rc);
> + netif_disable_cpu_rmap(napi->dev);
> + }
> + }
> +#endif
Declare rc inside the if to avoid the extra ifdef on variable decl
> +}
> +EXPORT_SYMBOL(netif_napi_set_irq);
> +
> static void napi_restore_config(struct napi_struct *n)
> {
> n->defer_hard_irqs = n->config->defer_hard_irqs;
> @@ -11421,6 +11461,10 @@ void free_netdev(struct net_device *dev)
> /* Flush device addresses */
> dev_addr_flush(dev);
>
> +#ifdef CONFIG_RFS_ACCEL
> + if (dev->rx_cpu_rmap && dev->rx_cpu_rmap_auto)
don't check dev->rx_cpu_rmap, dev->rx_cpu_rmap_auto is enough
> + netif_disable_cpu_rmap(dev);
> +#endif
> list_for_each_entry_safe(p, n, &dev->napi_list, dev_list)
> netif_napi_del(p);
>
IRQs are often allocated in ndo_open and freed in ndo_stop, so
you need to catch netif_napi_del or napi_disable and remove
the IRQ from the map.
Similarly netif_napi_set_irq() may get called with -1 to clear
the IRQ number, which you currently treat at a real IRQ id, AFAICT.
--
pw-bot: cr
next prev parent reply other threads:[~2025-01-14 22:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 17:10 [Intel-wired-lan] [PATCH net-next v5 0/6] net: napi: add CPU affinity to napi->config Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 1/6] net: move ARFS rmap management to core Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-14 9:33 ` [Intel-wired-lan] " Arinzon, David
2025-01-14 9:33 ` Arinzon, David
2025-01-14 22:08 ` Jakub Kicinski [this message]
2025-01-14 22:08 ` Jakub Kicinski
2025-01-15 1:00 ` [Intel-wired-lan] " Ahmed Zaki
2025-01-15 1:00 ` Ahmed Zaki
2025-01-15 1:38 ` [Intel-wired-lan] " Jakub Kicinski
2025-01-15 1:38 ` Jakub Kicinski
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 2/6] net: napi: add internal ARFS rmap management Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 3/6] net: napi: add CPU affinity to napi_config Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 4/6] bnxt: use napi's irq affinity Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 5/6] ice: " Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
2025-01-13 17:10 ` [Intel-wired-lan] [PATCH net-next v5 6/6] idpf: " Ahmed Zaki
2025-01-13 17:10 ` Ahmed Zaki
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=20250114140813.5a7d527f@kernel.org \
--to=kuba@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=darinzon@amazon.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jdamato@fastly.com \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=shayagr@amazon.com \
--cc=shayd@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=yury.norov@gmail.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: 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.