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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFE2BC433F5 for ; Thu, 28 Apr 2022 18:28:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350720AbiD1Sbj (ORCPT ); Thu, 28 Apr 2022 14:31:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbiD1Sbi (ORCPT ); Thu, 28 Apr 2022 14:31:38 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48C669859A for ; Thu, 28 Apr 2022 11:28:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D87BF619B5 for ; Thu, 28 Apr 2022 18:28:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E15EFC385A0; Thu, 28 Apr 2022 18:28:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651170502; bh=qWVRw5Id6H3dmoXmwzdsRfaIS65ve75GD3sJixbmRMs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qjJPYlH8x7VYARJgTH+3zhDjv0Lg1fF8SyfJaC6FGS+8Cp3EDdrKF9OlmWEiJ4Jd8 JnNP2t1hLP1kOVTt9LnK+qr7PP9oX3+T1dlXkjPpTngmiA6EBn4AQ6H4gdjgEzFL0W Khp9+uvNN86rS+R7Lz5HzHT+TB9tl2wGYSMWwshQPML31Jn+avt+7BQWAcJhXk/bsd 5AXHyEENdQ9OonUhEbzrD15ZWbn6W5NVUFqlyXJ8yc6oifl4Cap5ooAFOPGsfOMWcF 3BYxQHznavyvCB6YhSud/NJ9Tz4mymI4z21nwCfYQ9YQPpCyqpvifwED7GooFj6fT+ zhUKzTSqTYBIg== Date: Thu, 28 Apr 2022 11:28:20 -0700 From: Jakub Kicinski To: "Maloszewski, Michal" Cc: "Nguyen, Anthony L" , "davem@davemloft.net" , "pabeni@redhat.com" , "netdev@vger.kernel.org" , "sassmann@redhat.com" , Sylwester Dziedziuch , "Jankowski, Konrad0" Subject: Re: [PATCH net 1/2] iavf: Fix error when changing ring parameters on ice PF Message-ID: <20220428112820.4f36b5e6@kernel.org> In-Reply-To: References: <20220420172624.931237-1-anthony.l.nguyen@intel.com> <20220420172624.931237-2-anthony.l.nguyen@intel.com> <20220422154752.1fab6496@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 28 Apr 2022 18:10:49 +0000 Maloszewski, Michal wrote: >> Can't we wait for the device to get into the right state? >> Throwing EAGAIN back to user space is not very friendly. > > When we have state which is running, it does not mean that we have > queues configured on PF. So in order to configure queues on PF, the > IAVF_FLAG_QUEUES has to be disabled. I use here EAGAIN, because as > long as we are not configured with queues, it does not make any sense > to trigger command and we are not sure when the configuration of > queues will end - so that is why EAGAIN is used. Let me rephrase the question. Does getting out of the state where error is reported require user to change something, or is it something that happens automatically behind the scenes (i.e. the state is transient).