Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Schmidt <mschmidt@redhat.com>
To: intel-wired-lan@lists.osuosl.org
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	Radoslaw Tyl <radoslawx.tyl@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>
Subject: [Intel-wired-lan] [PATCH net-next 5/5] iavf: fix the waiting time for initial reset
Date: Tue, 10 Oct 2023 02:24:44 +0200	[thread overview]
Message-ID: <20231010002444.43507-6-mschmidt@redhat.com> (raw)
In-Reply-To: <20231010002444.43507-1-mschmidt@redhat.com>

Every time I create VFs on ice, I receive at least one "Device is still
in reset (-16), retrying" message per VF. It recovers fine, but typical
usecases should not trigger scary-looking messages.

The waiting for reset is too short. It makes no sense to check every 10
microseconds. Typical reset waiting times are at least tens of
milliseconds and can be several seconds. I suspect the polling interval
was meant to be 10 milliseconds all along.

IAVF_RESET_WAIT_COMPLETE_COUNT is defined as 2000, so the total waiting
time could be over 20 seconds. I have seen resets take 5 seconds (with
128 VFs on ice).

The added benefit of not triggering the "Device is still in reset" path
is that we avoid going through the __IAVF_INIT_FAILED state, which would
take a full second before retrying.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
 drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 2ab08b015b85..f35d74566faa 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -4791,7 +4791,7 @@ static int iavf_check_reset_complete(struct iavf_hw *hw)
 		if ((rstat == VIRTCHNL_VFR_VFACTIVE) ||
 		    (rstat == VIRTCHNL_VFR_COMPLETED))
 			return 0;
-		usleep_range(10, 20);
+		msleep(IAVF_RESET_WAIT_MS);
 	}
 	return -EBUSY;
 }
-- 
2.41.0

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  parent reply	other threads:[~2023-10-10  0:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  0:24 [Intel-wired-lan] [PATCH net-next 0/5] iavf: cleanup, improvements in init and Michal Schmidt
2023-10-10  0:24 ` [Intel-wired-lan] [PATCH net-next 1/5] iavf: fix comments about old bit locks Michal Schmidt
2023-10-10 11:24   ` Drewek, Wojciech
2023-10-18 11:31     ` Romanowski, Rafal
2023-10-10  0:24 ` [Intel-wired-lan] [PATCH net-next 2/5] iavf: simplify mutex_trylock+sleep loops Michal Schmidt
2023-10-10 11:30   ` Drewek, Wojciech
2023-10-10 11:57     ` Michal Schmidt
2023-10-10 12:08       ` Drewek, Wojciech
2023-10-18 11:31         ` Romanowski, Rafal
2023-10-10  0:24 ` [Intel-wired-lan] [PATCH net-next 3/5] iavf: in iavf_down, don't queue watchdog_task if comms failed Michal Schmidt
2023-10-10 11:33   ` Drewek, Wojciech
2023-10-18 11:32     ` Romanowski, Rafal
2023-10-10  0:24 ` [Intel-wired-lan] [PATCH net-next 4/5] iavf: in iavf_down, disable queues when removing the driver Michal Schmidt
2023-10-10 11:39   ` Drewek, Wojciech
2023-10-10 12:22     ` Michal Schmidt
2023-10-10 13:56       ` Drewek, Wojciech
2023-10-18 11:32         ` Romanowski, Rafal
2023-10-10  0:24 ` Michal Schmidt [this message]
2023-10-10 11:42   ` [Intel-wired-lan] [PATCH net-next 5/5] iavf: fix the waiting time for initial reset Drewek, Wojciech
2023-10-18 11:33     ` Romanowski, Rafal
2023-10-10 11:38 ` [Intel-wired-lan] [PATCH net-next 0/5] iavf: cleanup, improvements in init and Przemek Kitszel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231010002444.43507-6-mschmidt@redhat.com \
    --to=mschmidt@redhat.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=radoslawx.tyl@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox