From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by dpdk.org (Postfix) with ESMTP id 187AF5323 for ; Tue, 28 Jan 2014 02:15:45 +0100 (CET) Received: from mail-ve0-f170.google.com ([209.85.128.170]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (auth plain:sangjin@berkeley.edu) (envelope-from ) id 1W7xIS-0005qM-BN for dev@dpdk.org; Mon, 27 Jan 2014 17:17:01 -0800 Received: by mail-ve0-f170.google.com with SMTP id cz12so4031345veb.29 for ; Mon, 27 Jan 2014 17:16:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ABjt7VMEiLP1NaXKGBfN6D9c3xlf/PBuVztXrnQlQLE=; b=bjNL21eb+EdYnTfyhCwaRxlgL1/5tSBo1bszGPzoFPGDJ+qMq8wTqZniemXFte4EBk LpmA6GOcZeHlBWy2tlG3Znqm8Lnap9mZllm8YN0HJ6WTav9Le2Tmf776kLLcbVlaW9pj U4HBdWIevycHfoj3ai8EK4sGin9TF2SYRmj5YxCBNjCGG8SzJkDUWl66iQ48T4BrjZmQ sSKe+tJ9eicLtm0bo+qjN6hbQbVpsxFUJ9zkbxlAdPx/lwD+wmD6bIJRt9veKCynzwg1 7PfWOQjZSZe3YNzkP6QkmOIf86S+qENRaN8e5M7rWVIbRCN5EkOWWMkeI0A+bxRfYo+/ xCwA== MIME-Version: 1.0 X-Received: by 10.52.106.107 with SMTP id gt11mr138070vdb.7.1390871819503; Mon, 27 Jan 2014 17:16:59 -0800 (PST) Received: by 10.220.73.137 with HTTP; Mon, 27 Jan 2014 17:16:59 -0800 (PST) In-Reply-To: <201401271019.00293.thomas.monjalon@6wind.com> References: <201401271019.00293.thomas.monjalon@6wind.com> Date: Mon, 27 Jan 2014 17:16:59 -0800 Message-ID: From: Sangjin Han To: Thomas Monjalon Content-Type: text/plain; charset=ISO-8859-1 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 01:15:45 -0000 Hi, >> 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. Reasonably new Intel CPUs (including Nehalem) has a constant TSC rate, regardless of the current P/C-state (constant_tsc and nonstop_tsc flags in /proc/cpuinfo). So TSC calibration is unnecessary even with variable clock frequency on those CPUs. Also, it seems that there is no guarantee that the TSC rate is identical to the CPU max clock frequency. While it happens to be true for Intel CPUs, this article from AMD says, (https://lkml.org/lkml/2005/11/4/173) "The rate of the invariant TSC is implementation-dependent and will likely *not* be the frequency of the processor core [...]" It would be great if someone can actually measure TSC rate on AMD processors to verify this. 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. --- 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. Sangjin