Different vendors support different number of RSS queues by default. Today,
there exists an ethtool API through which users can change the number of
channels their driver supports; This enables us to pursue the goal of using
a default number of RSS queues in various multi-queue drivers.
This RFC intendeds to achieve the above default, by upper-limiting the number
of interrupts multi-queue drivers request (by default, not via the new API)
with correlation to the number of cpus on the machine.
After examining multi-queue drivers that call alloc_etherdev_mq[s],
it became evident that most drivers allocate their devices using hard-coded
values. Changing those defaults directly will most likely cause a regression.
However, (most) multi-queue driver look at the number of online cpus when
requesting for interrupts. We assume that the number of interrupts the
driver manages to request is propagated across the driver, and the number
of RSS queues it configures is based upon it.
This RFC modifies said logic - if the number of cpus is large enough, use
a smaller default value instead. This serves 2 main purposes:
1. A step forward unity in the number of RSS queues of various drivers.
2. It prevents wasteful requests for interrupts on machines with many cpus.
Notice no testing was made on this RFC (other than on the bnx2x driver)
except for compilation test.
Drivers identified as multi-queue, handled in this RFC:
* mellanox mlx4
* neterion vxge
* qlogic qlge
* intel igb, igbxe, igbxevf
* chelsio cxgb3, cxgb4
* myricom myri10ge
* emulex benet
* broadcom tg3, bnx2, bnx2x
Driver identified as multi-queue, no reference to number of online cpus found,
and thus unhandled in this RFC:
* neterion s2io
* marvell mv643xx
* freescale gianfar
* ibm ehea
* ti cpmac
* sun niu
* sfc efx
* chelsio cxgb4vf
Cheers,
Yuval Mintz
Cc: Divy Le Ray <redacted>
Cc: Or Gerlitz <redacted>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Anirban Chakraborty <redacted>
Cc: Jitendra Kalsaria <redacted>
Cc: Ron Mercer <redacted>
Cc: Jeff Kirsher <redacted>
Cc: Jon Mason <redacted>
Cc: Andrew Gallatin <redacted>
Cc: Sathya Perla <redacted>
Cc: Subbu Seetharaman <redacted>
Cc: Ajit Khaparde <redacted>
Cc: Matt Carlson <redacted>
Cc: Michael Chan <mchan@broadcom.com>
@@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);externinteth_change_mtu(structnet_device*dev,intnew_mtu);externinteth_validate_addr(structnet_device*dev);-+/* The maximal number of RSS queues a driver should have unless configured+*soexplicitly.+*/+#define DEFAULT_MAX_NUM_RSS_QUEUES (8)externstructnet_device*alloc_etherdev_mqs(intsizeof_priv,unsignedinttxqs,unsignedintrxqs);
@@ -2380,18 +2380,20 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)#endif /* CONFIG_PCI_IOV */switch(hw->mac.type){casee1000_i210:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I210,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I210;break;casee1000_i211:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I211,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I211;break;default:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES;break;}++adapter->rss_queues=min_t(u32,adapter->rss_queues,+min_t(u32,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES));+/* i350 cannot do RSS and SR-IOV at the same time */if(hw->mac.type==e1000_i350&&adapter->vfs_allocated_count)adapter->rss_queues=1;
@@ -2022,8 +2022,9 @@ static int ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)*thanCPU's.Solet'sbeconservativeandonlyaskfor*(roughly)twicethenumberofvectorsasthereareCPU's.*/+ncpu=min_t(int,num_online_cpus(),DEFAULT_MAX_NUM_RSS_QUEUES);v_budget=min(adapter->num_rx_queues+adapter->num_tx_queues,-(int)(num_online_cpus()*2))+NON_Q_VECTORS;+ncpu*2)+NON_Q_VECTORS;/* A failure in MSI-X entry allocation isn't fatal, but it does*meanwedisableMSI-Xcapabilitiesoftheadapter.*/
@@ -9908,7 +9908,8 @@ static bool tg3_enable_msix(struct tg3 *tp)inti,rc;structmsix_entrymsix_ent[tp->irq_max];-tp->irq_cnt=num_online_cpus();+tp->irq_cnt=min_t(unsigned,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES);if(tp->irq_cnt>1){/* We want as many rx rings enabled as there are cpus.*InmultiqueueMSI-Xmode,thefirstMSI-Xvector
@@ -2153,13 +2153,15 @@ static uint be_num_rss_want(struct be_adapter *adapter)staticvoidbe_msix_enable(structbe_adapter*adapter){#define BE_MIN_MSIX_VECTORS 1-inti,status,num_vec,num_roce_vec=0;+inti,status,num_vec,num_roce_vec=0,ncpu;++ncpu=min_t(int,num_online_cpus(),DEFAULT_MAX_NUM_RSS_QUEUES);/* If RSS queues are not used, need a vec for default RX Q */-num_vec=min(be_num_rss_want(adapter),num_online_cpus());+num_vec=min(be_num_rss_want(adapter),ncpu);if(be_roce_supported(adapter)){num_roce_vec=min_t(u32,MAX_ROCE_MSIX_VECTORS,-(num_online_cpus()+1));+(u32)(ncpu+1));num_roce_vec=min(num_roce_vec,MAX_ROCE_EQS);num_vec+=num_roce_vec;num_vec=min(num_vec,MAX_MSIX_VECTORS);
@@ -2022,8 +2022,9 @@ static int ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)*thanCPU's.Solet'sbeconservativeandonlyaskfor*(roughly)twicethenumberofvectorsasthereareCPU's.*/+ncpu=min_t(int,num_online_cpus(),DEFAULT_MAX_NUM_RSS_QUEUES);v_budget=min(adapter->num_rx_queues+adapter->num_tx_queues,-(int)(num_online_cpus()*2))+NON_Q_VECTORS;+ncpu*2)+NON_Q_VECTORS;/* A failure in MSI-X entry allocation isn't fatal, but it does*meanwedisableMSI-Xcapabilitiesoftheadapter.*/
This change is pointless on the ixgbevf driver. The VF hardware can
support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
will never exceed 8 so you are essentially adding a necessary min(x,8).
Thanks,
Alex
@@ -2380,18 +2380,20 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)#endif /* CONFIG_PCI_IOV */switch(hw->mac.type){casee1000_i210:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I210,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I210;break;casee1000_i211:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I211,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I211;break;default:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES;break;}++adapter->rss_queues=min_t(u32,adapter->rss_queues,+min_t(u32,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES));+/* i350 cannot do RSS and SR-IOV at the same time */if(hw->mac.type==e1000_i350&&adapter->vfs_allocated_count)adapter->rss_queues=1;
Same issue here as ixgbevf, only we support a max of 8 Rx queues in the
hardware. So now you are once again adding another unnecessary limit on
something that is already limited to 8 or less.
Thanks,
Alex
@@ -802,7 +802,8 @@ static int ixgbe_set_interrupt_capability(struct ixgbe_adapter *adapter)*Thedefaultistousepairsofvectors.*/v_budget=max(adapter->num_rx_queues,adapter->num_tx_queues);-v_budget=min_t(int,v_budget,num_online_cpus());+v_budget=min_t(int,v_budget,min_t(int,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES));v_budget+=NON_Q_VECTORS;/*
This patch doesn't limit the number of queues. It is limiting the
number of interrupts. The two are not directly related as we can
support multiple queues per interrupt.
Also this change assumes we are only using receive side scaling. We
have other features such as DCB, FCoE, and Flow Director which require
additional queues.
Thanks,
Alex
@@ -2022,8 +2022,9 @@ static int ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)*thanCPU's.Solet'sbeconservativeandonlyaskfor*(roughly)twicethenumberofvectorsasthereareCPU's.*/+ncpu=min_t(int,num_online_cpus(),DEFAULT_MAX_NUM_RSS_QUEUES);v_budget=min(adapter->num_rx_queues+adapter->num_tx_queues,-(int)(num_online_cpus()*2))+NON_Q_VECTORS;+ncpu*2)+NON_Q_VECTORS;/* A failure in MSI-X entry allocation isn't fatal, but it does*meanwedisableMSI-Xcapabilitiesoftheadapter.*/
This change is pointless on the ixgbevf driver. The VF hardware can
support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
will never exceed 8 so you are essentially adding a necessary min(x,8).
It is pointless with the current value, but if someone will edit the
kernel source code and replace the 8 with a 2, it will become
meaningful. The compiler will optimize this part, and I think that for
completion, it is best to keep this reference so a future default number
change will not be missed.
Eilon
@@ -2380,18 +2380,20 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)#endif /* CONFIG_PCI_IOV */switch(hw->mac.type){casee1000_i210:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I210,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I210;break;casee1000_i211:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES_I211,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES_I211;break;default:-adapter->rss_queues=min_t(u32,IGB_MAX_RX_QUEUES,-num_online_cpus());+adapter->rss_queues=IGB_MAX_RX_QUEUES;break;}++adapter->rss_queues=min_t(u32,adapter->rss_queues,+min_t(u32,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES));+/* i350 cannot do RSS and SR-IOV at the same time */if(hw->mac.type==e1000_i350&&adapter->vfs_allocated_count)adapter->rss_queues=1;
Same issue here as ixgbevf, only we support a max of 8 Rx queues in the
hardware. So now you are once again adding another unnecessary limit on
something that is already limited to 8 or less.
Same issue and same reply :)
It is here to support a change of the DEFAULT_MAX_NUM_RSS_QUEUES macro.
Eilon
@@ -802,7 +802,8 @@ static int ixgbe_set_interrupt_capability(struct ixgbe_adapter *adapter)*Thedefaultistousepairsofvectors.*/v_budget=max(adapter->num_rx_queues,adapter->num_tx_queues);-v_budget=min_t(int,v_budget,num_online_cpus());+v_budget=min_t(int,v_budget,min_t(int,num_online_cpus(),+DEFAULT_MAX_NUM_RSS_QUEUES));v_budget+=NON_Q_VECTORS;/*
This patch doesn't limit the number of queues. It is limiting the
number of interrupts. The two are not directly related as we can
support multiple queues per interrupt.
Also this change assumes we are only using receive side scaling. We
have other features such as DCB, FCoE, and Flow Director which require
additional queues.
You are right - but DEFAULT_MAX_NUM_RSS_QUEUES is there to limit the RSS
and not everything else. It is harder to determine what else should be
set to a lower value and the two goals were to limit the memory waste in
correlation to the number of CPUs and to have some unification between
the drivers - both goals are applicable mostly to the RSS and not so
much to DCB, FCoE and similar features.
Thanks,
Eilon
On Tue, 2012-06-19 at 18:13 +0300, Yuval Mintz wrote:
Different vendors support different number of RSS queues by default. Today,
there exists an ethtool API through which users can change the number of
channels their driver supports; This enables us to pursue the goal of using
a default number of RSS queues in various multi-queue drivers.
This RFC intendeds to achieve the above default, by upper-limiting the number
of interrupts multi-queue drivers request (by default, not via the new API)
with correlation to the number of cpus on the machine.
After examining multi-queue drivers that call alloc_etherdev_mq[s],
it became evident that most drivers allocate their devices using hard-coded
values. Changing those defaults directly will most likely cause a regression.
However, (most) multi-queue driver look at the number of online cpus when
requesting for interrupts. We assume that the number of interrupts the
driver manages to request is propagated across the driver, and the number
of RSS queues it configures is based upon it.
This RFC modifies said logic - if the number of cpus is large enough, use
a smaller default value instead. This serves 2 main purposes:
1. A step forward unity in the number of RSS queues of various drivers.
2. It prevents wasteful requests for interrupts on machines with many cpus.
Notice no testing was made on this RFC (other than on the bnx2x driver)
except for compilation test.
Drivers identified as multi-queue, handled in this RFC:
* mellanox mlx4
* neterion vxge
* qlogic qlge
* intel igb, igbxe, igbxevf
* chelsio cxgb3, cxgb4
* myricom myri10ge
* emulex benet
* broadcom tg3, bnx2, bnx2x
Driver identified as multi-queue, no reference to number of online cpus found,
and thus unhandled in this RFC:
* neterion s2io
* marvell mv643xx
* freescale gianfar
* ibm ehea
* ti cpmac
* sun niu
* sfc efx
* chelsio cxgb4vf
Cheers,
Yuval Mintz
Cc: Divy Le Ray <redacted>
Cc: Or Gerlitz <redacted>
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Anirban Chakraborty <redacted>
Cc: Jitendra Kalsaria <redacted>
Cc: Ron Mercer <redacted>
Cc: Jeff Kirsher <redacted>
Cc: Jon Mason <redacted>
Cc: Andrew Gallatin <redacted>
Cc: Sathya Perla <redacted>
Cc: Subbu Seetharaman <redacted>
Cc: Ajit Khaparde <redacted>
Cc: Matt Carlson <redacted>
Cc: Michael Chan <mchan@broadcom.com>
Obviously we need to make the subject line more self-explanatory and
start with the component name followed by colon. We will fix it in the
next version of the patch, but please comment on the content.
Thanks,
Eilon
@@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);externinteth_change_mtu(structnet_device*dev,intnew_mtu);externinteth_validate_addr(structnet_device*dev);-+/* The maximal number of RSS queues a driver should have unless configured+*soexplicitly.+*/+#define DEFAULT_MAX_NUM_RSS_QUEUES (8)externstructnet_device*alloc_etherdev_mqs(intsizeof_priv,unsignedinttxqs,unsignedintrxqs);
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
Thanks,
Alex
@@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);externinteth_change_mtu(structnet_device*dev,intnew_mtu);externinteth_validate_addr(structnet_device*dev);-+/* The maximal number of RSS queues a driver should have unless configured+*soexplicitly.+*/+#define DEFAULT_MAX_NUM_RSS_QUEUES (8)externstructnet_device*alloc_etherdev_mqs(intsizeof_priv,unsignedinttxqs,unsignedintrxqs);
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
My original suggestion was a kernel command line parameter, but Dave was
less than enthusiastic. If you will follow the original thread, you can
probably understand why I decided to adopt Dave's constant approach
without suggesting Kconfig:
http://marc.info/?l=linux-netdev&m=133992386010982&w=2
However, 8 is not a holy number - I'm open for suggestions.
Thanks,
Eilon
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index
f69ec42..3ad46c2 100644 ---
a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -2014,7
+2014,7 @@ err_tx_ring_allocation: static int
ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
{ int err = 0;
- int vector, v_budget;
+ int vector, v_budget, ncpu;
/*
* It's easy to be greedy for MSI-X vectors, but it
really @@ -2022,8 +2022,9 @@ static int
ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
* than CPU's. So let's be conservative and only ask for
* (roughly) twice the number of vectors as there are
CPU's. */
+ ncpu = min_t(int, num_online_cpus(),
DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
min(adapter->num_rx_queues + adapter->num_tx_queues,
- (int)(num_online_cpus() * 2)) +
NON_Q_VECTORS;
+ ncpu * 2) + NON_Q_VECTORS;
/* A failure in MSI-X entry allocation isn't fatal, but
it does
* mean we disable MSI-X capabilities of the adapter. */
This change is pointless on the ixgbevf driver. The VF hardware can
support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
will never exceed 8 so you are essentially adding a necessary
min(x,8).
It is pointless with the current value, but if someone will edit the
kernel source code and replace the 8 with a 2, it will become
meaningful. The compiler will optimize this part, and I think that for
completion, it is best to keep this reference so a future default
number change will not be missed.
Eilon
I don't feel there is any real point to making this change to the
ixgbevf driver. 82599 virtual functions have 3 MSI-X vectors, one of
which is for the mailbox and the other two can be shared with tx/rx
queue pairs or assigned separately to tx or rx queues. So this code is
pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
Perhaps the patches to the other drivers in your RFC will have some
effect but this one looks like a no-op for the ixgbevf driver so there
is no reason for it.
- Greg
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index
f69ec42..3ad46c2 100644 ---
a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -2014,7
+2014,7 @@ err_tx_ring_allocation: static int
ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
{ int err = 0;
- int vector, v_budget;
+ int vector, v_budget, ncpu;
/*
* It's easy to be greedy for MSI-X vectors, but it
really @@ -2022,8 +2022,9 @@ static int
ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
* than CPU's. So let's be conservative and only ask for
* (roughly) twice the number of vectors as there are
CPU's. */
+ ncpu = min_t(int, num_online_cpus(),
DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
min(adapter->num_rx_queues + adapter->num_tx_queues,
- (int)(num_online_cpus() * 2)) +
NON_Q_VECTORS;
+ ncpu * 2) + NON_Q_VECTORS;
/* A failure in MSI-X entry allocation isn't fatal, but
it does
* mean we disable MSI-X capabilities of the adapter. */
This change is pointless on the ixgbevf driver. The VF hardware can
support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
will never exceed 8 so you are essentially adding a necessary
min(x,8).
It is pointless with the current value, but if someone will edit the
kernel source code and replace the 8 with a 2, it will become
meaningful. The compiler will optimize this part, and I think that for
completion, it is best to keep this reference so a future default
number change will not be missed.
Eilon
I don't feel there is any real point to making this change to the
ixgbevf driver. 82599 virtual functions have 3 MSI-X vectors, one of
which is for the mailbox and the other two can be shared with tx/rx
queue pairs or assigned separately to tx or rx queues. So this code is
pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
Perhaps the patches to the other drivers in your RFC will have some
effect but this one looks like a no-op for the ixgbevf driver so there
is no reason for it.
OK - I guess we can just add a comment in this location saying that
using DEFAULT_MAX_NUM_RSS_QUEUES is meaningless for the ixgbevf with
that explanation so it will not look as if it was simply over looked.
Thanks,
Eilon
@@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);externinteth_change_mtu(structnet_device*dev,intnew_mtu);externinteth_validate_addr(structnet_device*dev);-+/* The maximal number of RSS queues a driver should have unless configured+*soexplicitly.+*/+#define DEFAULT_MAX_NUM_RSS_QUEUES (8)externstructnet_device*alloc_etherdev_mqs(intsizeof_priv,unsignedinttxqs,unsignedintrxqs);
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
My original suggestion was a kernel command line parameter, but Dave was
less than enthusiastic. If you will follow the original thread, you can
probably understand why I decided to adopt Dave's constant approach
without suggesting Kconfig:
http://marc.info/?l=linux-netdev&m=133992386010982&w=2
There is a huge difference between a kernel parameter an a kconfig
value. The main idea behind the kconfig value is that you are going to
have different preferences depending on architectures and such so it
would make much more sense to have the default as a config option.
However, 8 is not a holy number - I'm open for suggestions.
Thanks,
Eilon
I'm not sure why you couldn't just limit it to 16. From what I can tell
that is the largest number that gets used for RSS queues on almost all
the different hardware out there.
As far as the rest of the patches for the Intel drivers go you might be
better off if you understood how we allocate queues on the ixgbe/ixgbevf
drivers. Usually we have the number of queues determined before we set
the number of vectors so your patches that limited the number of vectors
aren't going to have the effect you desire. So for example RSS
configuration is currently handled in either ixgbe_set_rss_queues or
ixgbe_set_dcb_queues depending on the mode the driver is in. You would
be much better off looking there for how to limit the RSS queueing on
the ixgbe adapter.
Thanks,
Alex
@@ -44,7 +44,10 @@ extern int eth_mac_addr(struct net_device *dev, void *p);externinteth_change_mtu(structnet_device*dev,intnew_mtu);externinteth_validate_addr(structnet_device*dev);-+/* The maximal number of RSS queues a driver should have unless configured+*soexplicitly.+*/+#define DEFAULT_MAX_NUM_RSS_QUEUES (8)externstructnet_device*alloc_etherdev_mqs(intsizeof_priv,unsignedinttxqs,unsignedintrxqs);
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
My original suggestion was a kernel command line parameter, but Dave was
less than enthusiastic. If you will follow the original thread, you can
probably understand why I decided to adopt Dave's constant approach
without suggesting Kconfig:
http://marc.info/?l=linux-netdev&m=133992386010982&w=2
There is a huge difference between a kernel parameter an a kconfig
value. The main idea behind the kconfig value is that you are going to
have different preferences depending on architectures and such so it
would make much more sense to have the default as a config option.
Yes, I'm aware of that. Coming from the orientation of number of CPUs
and memory constrains, the kernel parameter came to mind first, after
receiving the reply about using just a good default, I have considered
the kconfig alternative but decided not to make further suggestions and
just go with a good default.
I'm not sure why you couldn't just limit it to 16. From what I can tell
that is the largest number that gets used for RSS queues on almost all
the different hardware out there.
cxgb4 32, myril10ge 32, efx 32, niu 24.
The point is that I was requested by a customer to support more queues,
but simply enabling that much more MSI-X vectors in the FW will cause
the driver to consume too much memory and this is probably not desired
for most users. Having the set_channels API is good solution to have a
default value which is different than the maximal value, and that brings
us to where we are now - finding a default value for all multi-queue
drivers.
As far as the rest of the patches for the Intel drivers go you might be
better off if you understood how we allocate queues on the ixgbe/ixgbevf
drivers. Usually we have the number of queues determined before we set
the number of vectors so your patches that limited the number of vectors
aren't going to have the effect you desire. So for example RSS
configuration is currently handled in either ixgbe_set_rss_queues or
ixgbe_set_dcb_queues depending on the mode the driver is in. You would
be much better off looking there for how to limit the RSS queueing on
the ixgbe adapter.
From: David Miller <davem@davemloft.net> Date: 2012-06-19 21:22:52
From: Alexander Duyck <redacted>
Date: Tue, 19 Jun 2012 09:37:18 -0700
I'm not a big fan of just having this as a fixed define in the code. It
seems like it would make much more sense to have this in the Kconfig
somewhere as a range value if you plan on making this changeable in the
future.
From: David Miller <davem@davemloft.net> Date: 2012-06-19 21:26:05
From: Alexander Duyck <redacted>
Date: Tue, 19 Jun 2012 12:01:54 -0700
There is a huge difference between a kernel parameter an a kconfig
value. The main idea behind the kconfig value is that you are going to
have different preferences depending on architectures and such so it
would make much more sense to have the default as a config option.
I don't think the issue of how many queues to use in a network driver
when you have 1024 cpus is architecture specific.
Please drop this idea, thanks.
From: Eric Dumazet <hidden> Date: 2012-06-20 08:55:20
On Tue, 2012-06-19 at 08:54 -0700, Alexander Duyck wrote:
This patch doesn't limit the number of queues. It is limiting the
number of interrupts. The two are not directly related as we can
support multiple queues per interrupt.
Also this change assumes we are only using receive side scaling. We
have other features such as DCB, FCoE, and Flow Director which require
additional queues.
Yet, it would be good if ixgbe doesnt allocate 36 queues on a 4 cpu
machine.
"tc -s class show dev eth0" output is full of not used classes.
From: John Fastabend <hidden> Date: 2012-06-20 15:30:50
On 6/20/2012 1:55 AM, Eric Dumazet wrote:
On Tue, 2012-06-19 at 08:54 -0700, Alexander Duyck wrote:
quoted
This patch doesn't limit the number of queues. It is limiting the
number of interrupts. The two are not directly related as we can
support multiple queues per interrupt.
Also this change assumes we are only using receive side scaling. We
have other features such as DCB, FCoE, and Flow Director which require
additional queues.
Yet, it would be good if ixgbe doesnt allocate 36 queues on a 4 cpu
machine.
"tc -s class show dev eth0" output is full of not used classes.
We do this for the DCB/FCoE/RSS/Flow Director case where we want to
use multiple queues per traffic class (802.1Qaz). As it is now we
have to set the max queues at alloc_etherdev_mq() time so we use a
max of
(num_cpu * max traffic classes) + num_cpu
The last num_cpu is in error and I have a patch in JeffK's tree to
remove this. In many cases it seems excessive but sometimes it is
helpful.
.John
From: Ben Hutchings <hidden> Date: 2012-06-20 20:43:41
On Tue, 2012-06-19 at 18:13 +0300, Yuval Mintz wrote:
Different vendors support different number of RSS queues by default. Today,
there exists an ethtool API through which users can change the number of
channels their driver supports; This enables us to pursue the goal of using
a default number of RSS queues in various multi-queue drivers.
This RFC intendeds to achieve the above default, by upper-limiting the number
of interrupts multi-queue drivers request (by default, not via the new API)
with correlation to the number of cpus on the machine.
After examining multi-queue drivers that call alloc_etherdev_mq[s],
it became evident that most drivers allocate their devices using hard-coded
values. Changing those defaults directly will most likely cause a regression.
However, (most) multi-queue driver look at the number of online cpus when
requesting for interrupts. We assume that the number of interrupts the
driver manages to request is propagated across the driver, and the number
of RSS queues it configures is based upon it.
This RFC modifies said logic - if the number of cpus is large enough, use
a smaller default value instead. This serves 2 main purposes:
1. A step forward unity in the number of RSS queues of various drivers.
2. It prevents wasteful requests for interrupts on machines with many cpus.
[...]
Driver identified as multi-queue, no reference to number of online cpus found,
and thus unhandled in this RFC:
[...]
* sfc efx
[...]
In sfc we currently look at the CPU topology to count cores instead of
threads. The result is the same unless the system has hyperthreading
(or other SMT) enabled.
I've seen many diagnostic reports from customer support tickets where
there were 32 queue-sets and MSI-X vectors in use (the maximum currently
supported by the driver), but very few had a problem with that.
I would be interested in a scheme to use fewer queues for RSS but more
for flow steering (accelerated RFS, XPS and ethtool NFC). We had some
discussion of this at last year's netconf but sadly I've not yet found
time to work on it.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
From: Ben Hutchings <hidden> Date: 2012-06-20 20:48:48
Also, I would recommend encapsulating the calculation of default number
of RSS queues in a function, rather than repeating it in every driver.
That will make it easier to replace with something more sophisticated
and configurable later on.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Also, I would recommend encapsulating the calculation of default number
of RSS queues in a function, rather than repeating it in every driver.
That will make it easier to replace with something more sophisticated
and configurable later on.
Ben.
Do You also have the notion of where's the correct place to place such a
function?
Thanks,
Yuval
Also, I would recommend encapsulating the calculation of default number
of RSS queues in a function, rather than repeating it in every driver.
That will make it easier to replace with something more sophisticated
and configurable later on.
Ben.
Do You also have the notion of where's the correct place to place such a
function?
I would put the extern declaration into linux/netdevice.h and the
implementation in net/core/dev.c
@@ -2153,13 +2153,15 @@ static uint be_num_rss_want(struct be_adapter *adapter)staticvoidbe_msix_enable(structbe_adapter*adapter){#define BE_MIN_MSIX_VECTORS 1-inti,status,num_vec,num_roce_vec=0;+inti,status,num_vec,num_roce_vec=0,ncpu;++ncpu=min_t(int,num_online_cpus(),DEFAULT_MAX_NUM_RSS_QUEUES);/* If RSS queues are not used, need a vec for default RX Q */-num_vec=min(be_num_rss_want(adapter),num_online_cpus());+num_vec=min(be_num_rss_want(adapter),ncpu);if(be_roce_supported(adapter)){num_roce_vec=min_t(u32,MAX_ROCE_MSIX_VECTORS,-(num_online_cpus()+1));+(u32)(ncpu+1));num_roce_vec=min(num_roce_vec,MAX_ROCE_EQS);num_vec+=num_roce_vec;num_vec=min(num_vec,MAX_MSIX_VECTORS);--
* It's easy to be greedy for MSI-X vectors, but it
quoted
quoted
quoted
really @@ -2022,8 +2022,9 @@ static int
ixgbevf_set_interrupt_capability(struct ixgbevf_adapter *adapter)
* than CPU's. So let's be conservative and only ask for
* (roughly) twice the number of vectors as there are
CPU's. */
+ ncpu = min_t(int, num_online_cpus(),
DEFAULT_MAX_NUM_RSS_QUEUES); v_budget =
min(adapter->num_rx_queues + adapter->num_tx_queues,
- (int)(num_online_cpus() * 2)) +
NON_Q_VECTORS;
+ ncpu * 2) + NON_Q_VECTORS;
/* A failure in MSI-X entry allocation isn't fatal, but
it does
* mean we disable MSI-X capabilities of the adapter. */
This change is pointless on the ixgbevf driver. The VF hardware can
support at most 4 RSS queues. As such num_rx_queues + num_tx_queues
will never exceed 8 so you are essentially adding a necessary
min(x,8).
It is pointless with the current value, but if someone will edit the
kernel source code and replace the 8 with a 2, it will become
meaningful. The compiler will optimize this part, and I think that for
completion, it is best to keep this reference so a future default
number change will not be missed.
Eilon
I don't feel there is any real point to making this change to the
ixgbevf driver. 82599 virtual functions have 3 MSI-X vectors, one of
which is for the mailbox and the other two can be shared with tx/rx
queue pairs or assigned separately to tx or rx queues. So this code is
pointless no matter what value is set for DEFAULT_MAX_NUM_RSS_QUEUES.
Perhaps the patches to the other drivers in your RFC will have some
effect but this one looks like a no-op for the ixgbevf driver so there
is no reason for it.
- Greg
Hi Greg,
Since we're changing the RFC to use a new wrapper function which should
replace num_online_cpus (for these purpose), the next RFC version will still
change this driver (for uniformity, if nothing else).
Of course, if you would still have reservations for this change - send them.
Thanks,
Yuval