From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 3B85368F2 for ; Tue, 28 Jan 2014 17:22:06 +0100 (CET) Received: by mail-wg0-f48.google.com with SMTP id x13so1229008wgg.27 for ; Tue, 28 Jan 2014 08:23:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:organization:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=3BpwoD3lUkGzHYt8vnTJhp1wAOIBaWK8XO/iTPVUg0w=; b=aphu41A0mMI1npjyQ79++H/A3tnoc05WOgd3LCMjw5Ntdwc90jQk4Ffx3PBh35I91t X6I20RH46wAoQy7lofdKg3iiX3+AfL04JlZ89KwhdwdJVrux/a2fDLoTMfemZOIJFjgH s3tljZf3gQIBvQMGk7TahFfW6gitrtrDt6Dv7kqTh99vJsactiaXeId/bF2+CgIZCXnp VWHJ40yUAjYE9Mn73LKKfxSYKqO9C4Jq3qntTGffWwa+7wG8aNbTj1m+ximsSZe2uMx/ Ye52RmbBViIWusNpuWY1qJsc6Uhhj09/n8+wkC9wULGOmwsUTqE/+bJdrhLHacwphyLa HjCA== X-Gm-Message-State: ALoCoQnmwOfxPmEI2Sd7InraW5p6YvOC+UiyexIzaxYsOdo5pY9cqVKwqizqFmUkBJ8UesN/tpHw X-Received: by 10.180.218.171 with SMTP id ph11mr16020379wic.7.1390926204691; Tue, 28 Jan 2014 08:23:24 -0800 (PST) Received: from angus.localnet (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id t6sm452888wix.4.2014.01.28.08.23.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jan 2014 08:23:23 -0800 (PST) From: Thomas Monjalon Organization: 6WIND To: Sangjin Han Date: Tue, 28 Jan 2014 17:23:22 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) References: <201401271019.00293.thomas.monjalon@6wind.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201401281723.22155.thomas.monjalon@6wind.com> Cc: dev@dpdk.org Subject: Re: [dpdk-dev] "No probed ethernet devices" caused by inaccurate msec_delay() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:22:06 -0000 28/01/2014 02:16, Sangjin Han: > >> It would be nice if I can bypass set_tsc_freq_from_cpuinfo() in > >> set_tsc_freq(). > > > > I think it would not solve the problem because your clock is varying and > > the TSC calibration must be updated accordingly with different values by > > core. [...] > Also, it seems that there is no guarantee that the TSC rate is > identical to the CPU max clock frequency. So you may submit a revert of the commit a46154b9c6bc (timer: get TSC frequency from /proc/cpuinfo) > I would like to suggest two possible options: > > 1. If we can assume that the TSC rate always equals to the max clock > frequency, then we can use > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq instead of > /proc/cpuinfo (which reflects cpuinfo_cur_freq). > > 2. If we can't (AMD?), we can simply get rid of > set_tsc_freq_from_cpuinfo() and fall back to set_tsc_freq_from_clock() > or set_tsc_freq_ballback() instead. I always get reasonably good > accuracy with those two functions -- the only drawback is that it > takes 0.5 - 1 second for applications to boot up. Not sure if it is a > big deal or not, though. Maybe that you can choose between these two methods with a runtime option. > Besides the TSC frequency, the 4ms * 10 delay in > ixgbe_reset_pipeline_82599() seems too tight. On my system, it > succeeds only after 7 (or so) iterations with correct msec_delay(). > The per-iteration delay (4ms; in the kernel ixgbe driver, it is set to > be 4-8ms) and/or the number of iterations (10) should be increased, I > suppose. Feel free to submit a patch. -- Thomas