On 02/24/2014 10:51 AM, Prarit Bhargava wrote:
> The ixgbe driver assumes that the cpus on a node are mapped 1:1 with the
> indexes into arrays. This is not the case as nodes can contain, for
> example, cpus 0-7, 33-40.
>
> This patch fixes this problem.
>
> Signed-off-by: Prarit Bhargava <pra...@redhat.com>
> Cc: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
> Cc: Jesse Brandeburg <jesse.brandeb...@intel.com>
> Cc: Bruce Allan <bruce.w.al...@intel.com>
> Cc: Carolyn Wyborny <carolyn.wybo...@intel.com>
> Cc: Don Skidmore <donald.c.skidm...@intel.com>
> Cc: Greg Rose <gregory.v.r...@intel.com>
> Cc: Alex Duyck <alexander.h.du...@intel.com>
> Cc: John Ronciak <john.ronc...@intel.com>
> Cc: Mitch Williams <mitch.a.willi...@intel.com>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: nhor...@redhat.com
> Cc: agosp...@redhat.com
> Cc: e1000-devel@lists.sourceforge.net
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> index 3668288..8b3992e 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
> @@ -794,11 +794,15 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter
> *adapter,
> {
> struct ixgbe_q_vector *q_vector;
> struct ixgbe_ring *ring;
> - int node = NUMA_NO_NODE;
> - int cpu = -1;
> + int node = adapter->pdev->dev.numa_node;
> + int cpu, set_affinity = 0;
> int ring_count, size;
> u8 tcs = netdev_get_num_tc(adapter->netdev);
>
> + if (node == NUMA_NO_NODE)
> + cpu = -1;
> + else
> + cpu = cpumask_next(v_idx - 1, cpumask_of_node(node));
> ring_count = txr_count + rxr_count;
> size = sizeof(struct ixgbe_q_vector) +
> (sizeof(struct ixgbe_ring) * ring_count);
Are you sure this does what you think it does? I thought the first
value is just the starting offset to check for a bit? I don't think
cpumask_next is aware of holes in a given mask. So for example if 8-31
are missing I think you will end up with all of your CPUs being
allocated to CPU 32 since it is the first set bit greater than 15.
What might work better here is a function that returns the local node
CPU IDs first, followed by the remote node IDs if ATR is enabled. We
should probably have it configured to loop in the case that the number
of queues is greater than local nodes, but ATR is not enabled.
> @@ -807,10 +811,8 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter
> *adapter,
> if ((tcs <= 1) && !(adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)) {
> u16 rss_i = adapter->ring_feature[RING_F_RSS].indices;
> if (rss_i > 1 && adapter->atr_sample_rate) {
> - if (cpu_online(v_idx)) {
> - cpu = v_idx;
> - node = cpu_to_node(cpu);
> - }
> + if (likely(cpu_online(cpu)))
> + set_affinity = 1;
> }
> }
>
The node assignment is still needed here. We need to be able to assign
queues to remote nodes as applications will be there expecting data. We
have seen a serious performance degradation when trying to feed an
application from a remote queue even if the queue is local to hardware.
> @@ -822,7 +824,7 @@ static int ixgbe_alloc_q_vector(struct ixgbe_adapter
> *adapter,
> return -ENOMEM;
>
> /* setup affinity mask and node */
> - if (cpu != -1)
> + if (set_affinity)
> cpumask_set_cpu(cpu, &q_vector->affinity_mask);
> q_vector->numa_node = node;
>
>
I'm not sure what the point of this change is other than the fact that
you changed the cpu configuration to be earlier. The affinity mask
could be configured with an offline CPU and it should have no negative
affect.
Thanks,
Alex
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
