Received: by 10.192.165.148 with SMTP id m20csp1846791imm; Sun, 6 May 2018 00:35:07 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrO90/3fVnNBPsGug009aRiv/VhvXAy3xjajUQBWVjp8CtAMYkzd6it6XYgIbRSRwCXMoZn X-Received: by 2002:a17:902:2a43:: with SMTP id i61-v6mr34500156plb.54.1525592107614; Sun, 06 May 2018 00:35:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525592107; cv=none; d=google.com; s=arc-20160816; b=h+EMt2I88eWd1FgKFKprfkalf79gOfkyOjLyIv+QV0QfE1n1Nkb7GYcy89pYY+FdkW 2tFJ9kOCK2bF1gQvi6ZmIGpxVXTXsr29vTt8VDGxiY/uXY3ZFXhkK9OzE/Wfpqfnp2CW xuNqsnoIv0FGgCy/5MYP2LgKi26cyZwaLKfTmVr6rl2tY4Zb0+FUqNt2hwWGpEE5viS3 0ylLUvtLjOOSEsGY9OyDyO9fK326TBDl9kWJaAcrCx1A79Eq2j5nnufuy1FsjqEWPbNv dXunKNOxg2Rz7i+x+MEdh8sygYx67/UBP5nql8p3+JQVCPMuhJW4v0/UwdU0VGVQibmC ZH4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=vImfXCrS+TWq1r+YDUKRqazqJ0qinTvxYNhcTWAKHMY=; b=hvxcDLPujHZ8jUQP2mESKpSDpEPQp6KWLywPfOmv/PNTwhgXpw8M3nHrDyTLbIqGMY pVhBzwrWO3WXW9RWUr109ce8dN2jcXUfVUilZf8jwxa+5v1uVJ3NXZ/m1uWZVSOyh/RT nFSguQjyiYxqUBS3j3VJozVRcBbpB7JgrOWiMG/CCIc4uJxJZhjUb7Xu3gvy0jhGfRol 6HD2jmc5vfyKgjdYM0Pc8mZvDBSTsXEplIgmiaQDaHuI2G/lQuv9bw3/Kt5zkgwe4wOO B1fnO4OYT+7h1dhwJt3rPkJiJovMZSWIxLI6T0fAzMqoKmZ4ZviRtKd1kbUGzDYeABWS 1dig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t187-v6si55418pgc.689.2018.05.06.00.34.53; Sun, 06 May 2018 00:35:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751831AbeEFHeG (ORCPT + 99 others); Sun, 6 May 2018 03:34:06 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:47114 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbeEFHde (ORCPT ); Sun, 6 May 2018 03:33:34 -0400 Received: from p57927711.dip0.t-ipconnect.de ([87.146.119.17] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fFEAg-0004W2-Kt; Sun, 06 May 2018 09:33:26 +0200 Date: Sun, 6 May 2018 09:33:26 +0200 (CEST) From: Thomas Gleixner To: Guenter Roeck cc: Israel Rukshin , Max Gurtovoy , Matan Barak , Doug Ledford , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH] net/mlx5: Fix mlx5_get_vector_affinity function In-Reply-To: <20180505143838.GA12621@roeck-us.net> Message-ID: References: <20180505143838.GA12621@roeck-us.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1015051829-1525592006=:1685" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1015051829-1525592006=:1685 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Sat, 5 May 2018, Guenter Roeck wrote: > On Thu, Apr 12, 2018 at 09:49:11AM +0000, Israel Rukshin wrote: > > Adding the vector offset when calling to mlx5_vector2eqn() is wrong. > > This is because mlx5_vector2eqn() checks if EQ index is equal to vector number > > and the fact that the internal completion vectors that mlx5 allocates > > don't get an EQ index. > > > > The second problem here is that using effective_affinity_mask gives the same > > CPU for different vectors. > > This leads to unmapped queues when calling it from blk_mq_rdma_map_queues(). > > This doesn't happen when using affinity_hint mask. > > > Except that affinity_hint is only defined if SMP is enabled. Without: > > include/linux/mlx5/driver.h: In function ‘mlx5_get_vector_affinity_hint’: > include/linux/mlx5/driver.h:1299:13: error: > ‘struct irq_desc’ has no member named ‘affinity_hint’ > > Note that this is the only use of affinity_hint outside kernel/irq. > Don't other drivers have similar problems ? Aside of that. > > static inline const struct cpumask * > > -mlx5_get_vector_affinity(struct mlx5_core_dev *dev, int vector) > > +mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector) > > { > > - const struct cpumask *mask; > > struct irq_desc *desc; > > unsigned int irq; > > int eqn; > > int err; > > > > - err = mlx5_vector2eqn(dev, MLX5_EQ_VEC_COMP_BASE + vector, &eqn, &irq); > > + err = mlx5_vector2eqn(dev, vector, &eqn, &irq); > > if (err) > > return NULL; > > > > desc = irq_to_desc(irq); > > -#ifdef CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK > > - mask = irq_data_get_effective_affinity_mask(&desc->irq_data); > > -#else > > - mask = desc->irq_common_data.affinity; > > -#endif > > - return mask; > > + return desc->affinity_hint; NAK. Nothing in regular device drivers is supposed to ever fiddle with struct irq_desc. The existing code is already a violation of that rule and needs to be fixed, but not in that way. The logic here is completely screwed. affinity_hint is set by the driver, so the driver already knows what it is. If the driver does not set it, then the thing is NULL. Thanks, tglx --8323329-1015051829-1525592006=:1685--