Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp123875pxb; Thu, 21 Apr 2022 18:56:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfo36CzPYlSdk9B5GMa1emH/oGhHP2QiYaCV48yhdFCESdmDI0hNF4+m3KSRZa6px0ZlJq X-Received: by 2002:a17:906:a219:b0:6e4:86a3:44ea with SMTP id r25-20020a170906a21900b006e486a344eamr2051457ejy.385.1650592614943; Thu, 21 Apr 2022 18:56:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650592614; cv=none; d=google.com; s=arc-20160816; b=Fvhg9lt+yAkqFqsdemqgkh37Tp6Ocw3vhZC7hcQhlyWSk6kHsYufKf7Ge2AOKHYvkB dnDHyiKWQiwtSSDGXl3/rcknou7Qd6u850osiq/0pon7qPP8QE1yxPl9gfbEnjMX8X8s 6uYxsxtFBnXZecym6tTBi/q1v5k+fJuUYHv71NFZWAuKeziP0sOqnM3weLjCZhCkF1UX pi2F3OO0SxvIroPStqcTknY5QNzfD0HvJ55vk8BI2NdNgTH+a0DA1I1GIeKawik2Vdhr wTrj66T+zYIMbv9OlpeCQD2PTtbpKXKpGRdi8cqwJ0H2csaz2mCd9R9qodHL8LnDe26C RfSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=S6fnd+0TbcHO+9lyQndF2LzjWrtKXhuCCWIYNTM/fRc=; b=SKGltiHRISyjHtrY3wemcvS4rVhcNLM1SKwyvf0OY0PWz6hXbvDvXwoBXCA86/auNP mnwTY0ej08zivK4DqehqNQz7od0dUVk28GYCNsnXK+JTWIB5TvDdjHnwhjrtVTbdJHZr /o4NadGIE6fBQLMek7Y2BCeUFbnFs3PEtxLVflHsDWAhty3m9de2JQ0BT51RC+bwxx+2 75zF2kyHSP5/bjD6RdQ+GjOYQPfiX0JwkUCVXPXCCnM6Xg7T448C2aKOMGKYAXbmF1lT qTq3qWB9nnSQeeLeLhYcPOa1RAmSSqf79XNKIW0FGmQhSJUdKlpWKkcClhSVuPTvPbVV XJSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jPJDFi10; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ge8-20020a170907908800b006e83b74d0b2si4945630ejb.495.2022.04.21.18.56.31; Thu, 21 Apr 2022 18:56:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jPJDFi10; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355543AbiDSRHm (ORCPT + 99 others); Tue, 19 Apr 2022 13:07:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355710AbiDSRHI (ORCPT ); Tue, 19 Apr 2022 13:07:08 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 513291583E; Tue, 19 Apr 2022 10:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650387824; x=1681923824; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=9qpy676qE+GQBGiNZy1vWDAhbXjYL7YBg7SD1FIiYLg=; b=jPJDFi10UNA5UTWPkD3v2gKiEZ3O+pYUHddOc0kAJ8V6AVOQ+HaUvFJo qiWr964+NT1dctnHmOCOXr139Edj9dKvsNHAudALmr7XspbRL+rQhMVCT gfNFUwIamXF/NqSbgWoXJmB7jFAZkp3yUJyOOxSCSc8vjuDcQrFvmP/r0 Lixc+7vC/dKgkxZu5Sind6Td16lAahKNCd2yRjbYfScin4BFT3g8x6inE iA4ov5DMu7Nl01InWzPOtGCyf6nY6tx5cWCn/ovo6cCOZkcj+spU9J7/S G2ImdHzkORx8uYS/CLyfYRQjHptV6xxrQPzxUrSupR9fwWc3DwrQdSnsY A==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="263279532" X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="263279532" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 10:03:43 -0700 X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="576190835" Received: from magillis-mobl.amr.corp.intel.com (HELO vcostago-mobl3) ([10.255.229.182]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 10:03:43 -0700 From: Vinicius Costa Gomes To: Jeff Evanson , Jeff Evanson , Jesse Brandeburg , Tony Nguyen , "David S. Miller" , Jakub Kicinski , "intel-wired-lan@lists.osuosl.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "jeff.evanson@gmail.com" Subject: RE: [PATCH 2/2] Trigger proper interrupts in igc_xsk_wakeup In-Reply-To: References: <20220415210546.11294-1-jeff.evanson@qsc.com> <87v8v6477g.fsf@intel.com> Date: Tue, 19 Apr 2022 10:03:43 -0700 Message-ID: <87v8v5t380.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jeff, Jeff Evanson writes: > Hi Vinicius. Thank you for the reply. > > The scenario only happens when the transmit queue interrupt is mapped > to a different interrupt from the receive queue. In the case where > XDP_WAKEUP_TX is set in the flags argument, the previous code would > only trigger the interrupt for the receive queue, causing the transmit > queue's napi_struct to never be scheduled. This is a good explanation, adding it to the commit message for the v2 would be a good idea. > > In the scenario where XDP_WAKEUP_TX and XDP_WAKEUP_RX are both set in > flags, the receive interrupt is always triggered and the transmit > interrupt is only triggered when the transmit q_vector differs from > the receive q_vector. I missed that condition when I looked at the patch. Sorry about that. Makes more sense now. Acked-by: Vinicius Costa Gomes > > Regards, > Jeff Evanson > > -----Original Message----- > From: Vinicius Costa Gomes > Sent: Monday, April 18, 2022 11:45 AM > To: Jeff Evanson ; Jesse Brandeburg ; Tony Nguyen ; David S. Miller ; Jakub Kicinski ; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Jeff Evanson ; jeff.evanson@gmail.com > Subject: Re: [PATCH 2/2] Trigger proper interrupts in igc_xsk_wakeup > > -External- > > Jeff Evanson writes: > >> in igc_xsk_wakeup, trigger the proper interrupt based on whether flags >> contains XDP_WAKEUP_RX and/or XDP_WAKEUP_TX >> >> Signed-off-by: Jeff Evanson >> --- >> drivers/net/ethernet/intel/igc/igc_main.c | 36 >> +++++++++++++++++------ >> 1 file changed, 27 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c >> b/drivers/net/ethernet/intel/igc/igc_main.c >> index a36a18c84aeb..d706de95dc06 100644 >> --- a/drivers/net/ethernet/intel/igc/igc_main.c >> +++ b/drivers/net/ethernet/intel/igc/igc_main.c >> @@ -6073,7 +6073,7 @@ static void igc_trigger_rxtxq_interrupt(struct >> igc_adapter *adapter, int igc_xsk_wakeup(struct net_device *dev, u32 >> queue_id, u32 flags) { >> struct igc_adapter *adapter = netdev_priv(dev); >> - struct igc_q_vector *q_vector; >> + struct igc_q_vector *txq_vector = 0, *rxq_vector = 0; >> struct igc_ring *ring; >> >> if (test_bit(__IGC_DOWN, &adapter->state)) @@ -6082,17 +6082,35 @@ >> int igc_xsk_wakeup(struct net_device *dev, u32 queue_id, u32 flags) >> if (!igc_xdp_is_enabled(adapter)) >> return -ENXIO; >> >> - if (queue_id >= adapter->num_rx_queues) >> - return -EINVAL; >> + if (flags & XDP_WAKEUP_RX) { >> + if (queue_id >= adapter->num_rx_queues) >> + return -EINVAL; >> >> - ring = adapter->rx_ring[queue_id]; >> + ring = adapter->rx_ring[queue_id]; >> + if (!ring->xsk_pool) >> + return -ENXIO; >> >> - if (!ring->xsk_pool) >> - return -ENXIO; >> + rxq_vector = ring->q_vector; >> + } >> + >> + if (flags & XDP_WAKEUP_TX) { >> + if (queue_id >= adapter->num_tx_queues) >> + return -EINVAL; >> + >> + ring = adapter->tx_ring[queue_id]; >> + if (!ring->xsk_pool) >> + return -ENXIO; >> + >> + txq_vector = ring->q_vector; >> + } >> + >> + if (rxq_vector && >> + !napi_if_scheduled_mark_missed(&rxq_vector->napi)) >> + igc_trigger_rxtxq_interrupt(adapter, rxq_vector); >> >> - q_vector = adapter->q_vector[queue_id]; >> - if (!napi_if_scheduled_mark_missed(&q_vector->napi)) >> - igc_trigger_rxtxq_interrupt(adapter, q_vector); >> + if (txq_vector && txq_vector != rxq_vector && >> + !napi_if_scheduled_mark_missed(&txq_vector->napi)) >> + igc_trigger_rxtxq_interrupt(adapter, txq_vector); > > Two things: > - My imagination was not able to produce a scenario where this commit would solve any problems. Can you explain better the case where the current code would cause the wrong interrupt to be generated (or miss generating an interrupt)? (this should be in the commit message) > - I think that with this patch applied, there would cases (both TX and RX flags set) that we cause two writes into the EICS register. That could cause unnecessary wakeups. > >> >> return 0; >> } >> -- >> 2.17.1 >> > > Cheers, > -- > Vinicius > -- Vinicius