From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EAF938F86; Thu, 16 May 2024 08:27:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715848040; cv=none; b=BxKfDeMBKFm5Hqsw/5JweiYKHf+qXrcpEEA68fumCfU31GvRehq602rp16yN/gGJdXxCOKFNCkcMN5m2pUGZ+LePMziaZvWYYbUpg/hF7zSgnRNK23fYlBEi4EDVxzi0Zxjun3RDbJg/eV33YgAD4BwRB7fPXR7vC5odfFllVn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715848040; c=relaxed/simple; bh=XS+c13dsUKZqV4fhUJ4NseTT8YN+F9dJ7nFDGFXcNrs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XHpZ2QwYrmozH0w1E4f39ZHzGrqbXQ3JJgTi3el6NNUGGjmhT2xgWYXwbJidFH/EdTzCTmO9qTQsmUUVjyDwtsTmaRt2fFttntjDGm5TzXQ5b8XncRB8M4MyS997OFnY3cPnpc6zOoIn3Q9hZidVodpnZaoqJN6YlestYWk5Ul4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W+e1arsP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W+e1arsP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48018C113CC; Thu, 16 May 2024 08:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715848039; bh=XS+c13dsUKZqV4fhUJ4NseTT8YN+F9dJ7nFDGFXcNrs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W+e1arsPk3v9M3A8EeaJpe0Z8uAAfgVylWc7wCMixoFpsYxiO9MFuM1ocFVQWmAeR KXFZOav5FfjYm03+McmjOpIdXEii1bxqkQ7/8xTAZEo2U8XQP2rBp6ipgo4uPalkuV pI3G5UHIJFYjL0qdyyW6ncIlnV77pQwjI/oV4GeDMHeZ7LFeQvodFEnlwh6ocDojZr Rhs+0VJzxcuD+TJmk93Zdt4cUvlMlwGtl17UBaYbgqvPjPtKbodCgnDVOZUE/yT/c6 S0rmmeB4QipQDwpYo8jNBtAQs0cXym7XCM1RjrkdHC2gnkNB/buheVMKzkKahzGDYt IN9+Y3ltxHvdA== Date: Thu, 16 May 2024 09:27:13 +0100 From: Simon Horman To: Larysa Zaremba Cc: intel-wired-lan@lists.osuosl.org, Jacob Keller , maciej.fijalkowski@intel.com, Magnus Karlsson , Przemek Kitszel , igor.bagnucki@intel.com, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH iwl-net 3/3] ice: map XDP queues to vectors in ice_vsi_map_rings_to_vectors() Message-ID: <20240516082713.GC179178@kernel.org> References: <20240515160246.5181-1-larysa.zaremba@intel.com> <20240515160246.5181-4-larysa.zaremba@intel.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240515160246.5181-4-larysa.zaremba@intel.com> On Wed, May 15, 2024 at 06:02:16PM +0200, Larysa Zaremba wrote: > ice_pf_dcb_recfg() re-maps queues to vectors with > ice_vsi_map_rings_to_vectors(), which does not restore the previous > state for XDP queues. This leads to no AF_XDP traffic after rebuild. > > Map XDP queues to vectors in ice_vsi_map_rings_to_vectors(). > Also, move the code around, so XDP queues are mapped independently only > through .ndo_bpf(). Hi Larysa, I take it the last sentence refers to the placement of ice_map_xdp_rings() in ice_prepare_xdp_rings() after rather than before the (cfg_type == ICE_XDP_CFG_PART) condition. If so, I see that it is a small change. But I do wonder if it is separate from fixing the issue described in the first paragraph. And thus would be better as a separate patch. Also, (I'm raising a separate issue :) breaking out logic into ice_xdp_ring_from_qid() seems very nice. But I wonder if this ought to be part of a cleanup-patch for 'iwl' rather than a fixes patch for 'iwl-next'. OTOH, I do see that breaking out ice_map_xdp_rings() makes sense in the context of this fix as the same logic is to be called in two places. Splitting patches aside, the resulting code looks good to me. ... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5C73AC25B74 for ; Thu, 16 May 2024 08:27:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id F246041C9D; Thu, 16 May 2024 08:27:25 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id EfKBDRyAD2ab; Thu, 16 May 2024 08:27:23 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.34; helo=ash.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EB4ED40B75 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1715848043; bh=8hBF7tpJr16x0wIWbdc4Wr4SNml531faoWZIDjkVO7Q=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=NTLfvifvgmD4kAmvQ87U18cXMopacJNuR1EpEk42OgziaDwYx8pLoW7C1CCILfDRG bbWwAiRgNtsQNHVPCeKO1US8Swsz/WsmVBDVdKgy0nOiaHev1r8UUEou/lqrWHznsc 85vQzM8kRUTzzawcpQD6xR3ddkStBWUT7rGvuO+Cf1Fd/kMSAn0sTiI9Whd7kkDF5B MngGZulnIJ8R9olL6M8Fw1Vu0L2AI//mw+lixlKiYezF8pmtPazPXPt0i0D+LTW+47 NElZVwZbWVJPjI/XxPJxlm7MlNd0O1EOp5jCqk9xKNKopVtc8US0NdubsmH7V0kuxE ZhidZj3PpdqNw== Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp2.osuosl.org (Postfix) with ESMTP id EB4ED40B75; Thu, 16 May 2024 08:27:22 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 19F921BF855 for ; Thu, 16 May 2024 08:27:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0235360BF5 for ; Thu, 16 May 2024 08:27:22 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id D2L-bRXFGvgt for ; Thu, 16 May 2024 08:27:21 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp3.osuosl.org 3A4EA60BE7 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3A4EA60BE7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by smtp3.osuosl.org (Postfix) with ESMTPS id 3A4EA60BE7 for ; Thu, 16 May 2024 08:27:21 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 114DD615F4; Thu, 16 May 2024 08:27:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48018C113CC; Thu, 16 May 2024 08:27:16 +0000 (UTC) Date: Thu, 16 May 2024 09:27:13 +0100 From: Simon Horman To: Larysa Zaremba Message-ID: <20240516082713.GC179178@kernel.org> References: <20240515160246.5181-1-larysa.zaremba@intel.com> <20240515160246.5181-4-larysa.zaremba@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240515160246.5181-4-larysa.zaremba@intel.com> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1715848039; bh=XS+c13dsUKZqV4fhUJ4NseTT8YN+F9dJ7nFDGFXcNrs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W+e1arsPk3v9M3A8EeaJpe0Z8uAAfgVylWc7wCMixoFpsYxiO9MFuM1ocFVQWmAeR KXFZOav5FfjYm03+McmjOpIdXEii1bxqkQ7/8xTAZEo2U8XQP2rBp6ipgo4uPalkuV pI3G5UHIJFYjL0qdyyW6ncIlnV77pQwjI/oV4GeDMHeZ7LFeQvodFEnlwh6ocDojZr Rhs+0VJzxcuD+TJmk93Zdt4cUvlMlwGtl17UBaYbgqvPjPtKbodCgnDVOZUE/yT/c6 S0rmmeB4QipQDwpYo8jNBtAQs0cXym7XCM1RjrkdHC2gnkNB/buheVMKzkKahzGDYt IN9+Y3ltxHvdA== X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dmarc=pass (p=none dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=W+e1arsP Subject: Re: [Intel-wired-lan] [PATCH iwl-net 3/3] ice: map XDP queues to vectors in ice_vsi_map_rings_to_vectors() X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maciej.fijalkowski@intel.com, Jesper Dangaard Brouer , Daniel Borkmann , Przemek Kitszel , John Fastabend , Alexei Starovoitov , "David S. Miller" , Eric Dumazet , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, Jacob Keller , Jakub Kicinski , bpf@vger.kernel.org, Paolo Abeni , Magnus Karlsson , igor.bagnucki@intel.com, linux-kernel@vger.kernel.org Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Wed, May 15, 2024 at 06:02:16PM +0200, Larysa Zaremba wrote: > ice_pf_dcb_recfg() re-maps queues to vectors with > ice_vsi_map_rings_to_vectors(), which does not restore the previous > state for XDP queues. This leads to no AF_XDP traffic after rebuild. > > Map XDP queues to vectors in ice_vsi_map_rings_to_vectors(). > Also, move the code around, so XDP queues are mapped independently only > through .ndo_bpf(). Hi Larysa, I take it the last sentence refers to the placement of ice_map_xdp_rings() in ice_prepare_xdp_rings() after rather than before the (cfg_type == ICE_XDP_CFG_PART) condition. If so, I see that it is a small change. But I do wonder if it is separate from fixing the issue described in the first paragraph. And thus would be better as a separate patch. Also, (I'm raising a separate issue :) breaking out logic into ice_xdp_ring_from_qid() seems very nice. But I wonder if this ought to be part of a cleanup-patch for 'iwl' rather than a fixes patch for 'iwl-next'. OTOH, I do see that breaking out ice_map_xdp_rings() makes sense in the context of this fix as the same logic is to be called in two places. Splitting patches aside, the resulting code looks good to me. ...