From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B17FBA04FA; Wed, 5 Feb 2020 22:29:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1D5FF1C2B8; Wed, 5 Feb 2020 22:29:41 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id CE3E61C2B7 for ; Wed, 5 Feb 2020 22:29:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580938178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sDRJxF/C8X/bD8f/DeCXFWJ40NEQPMRRMOJfaqrDPd4=; b=Oz8sEr0FRfcuelOa8KZ2BmAlNj1PtbtrYUoauduVkbHAlNWfWFllGyIfFPEGllTYGnG+mE 2OyxvFTTQB9+vo2G562K8oZfqI+puo8ieh+2GrsFy0FcOhWdhkYuTjPAHQHw3fwL4h5iP0 fOinwIjLgaOgIQBt7lcqckWa4eviEMU= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-120-452NsFnxMxit3ov5FQb5nQ-1; Wed, 05 Feb 2020 16:29:34 -0500 Received: by mail-ua1-f72.google.com with SMTP id 71so985872uae.22 for ; Wed, 05 Feb 2020 13:29:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5UWb0QZM23KmFxTLUnCOUkeNm4UEdub13RwpbEY847M=; b=B1xPOvZqBxZNfNL0LOsKZ2zkduu5/l1kqR7cdSAVs3DTnLb7oG1a1GqJnAAMXW7cSo xxvNGi2G0t7LkvOE2G3AY/D3NTToiy1tQ2uZPK/k6QdRks4p60EAl1xXw0GmmClIeZe2 XkIcT74caFcj0PnOgugLE6nLwFCYvMLiiQ9W9ZMCzNNGeaNM9i2u1yDkVrGy+CLdN4du Pc8K04uYh0xNPtdbW3gZRLmkKmOHyZqoObl9o+uMdKjzx19r38OV60Z6fa7gZd7k4b/z ylOC67EsFn21YC9umcqRGS2KT+btpc/D53OaIEGLRFzwSvhU5H2mrXxJ6Vu/z+kNJE38 6jxw== X-Gm-Message-State: APjAAAW7etxS8bECDxIhUATvEPwO4mh4uz0To8f3jzelNAhI6gNjCXnV RQ0JohYjstvt2oJIGNaFzxsyz4beKSEa1MOonHnSjh+Dyuo9pmH7EwJw6HsQdcduQKLErF47sQ4 WoeX4eTZFpHdULTJZ6lU= X-Received: by 2002:ab0:488b:: with SMTP id x11mr21903635uac.86.1580938173692; Wed, 05 Feb 2020 13:29:33 -0800 (PST) X-Google-Smtp-Source: APXvYqxyIfEpOnvNl6x1NGQILlqeDxGf8JcfsXNykKvyCjgnck7T7aVTNjRtO88kjQRzeh7uKvLvsrwdGCWmzbc1Bb8= X-Received: by 2002:ab0:488b:: with SMTP id x11mr21903612uac.86.1580938173371; Wed, 05 Feb 2020 13:29:33 -0800 (PST) MIME-Version: 1.0 References: <20200128210233.691-1-thinhtr@linux.vnet.ibm.com> <20200131220336.103874-1-thinhtr@linux.vnet.ibm.com> In-Reply-To: <20200131220336.103874-1-thinhtr@linux.vnet.ibm.com> From: David Marchand Date: Wed, 5 Feb 2020 22:29:22 +0100 Message-ID: To: Thinh Tran Cc: dev , David Christensen X-MC-Unique: 452NsFnxMxit3ov5FQb5nQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2] eal/ppc64: improve rte_rdtsc with ppc_get_timebase X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jan 31, 2020 at 11:04 PM Thinh Tran wr= ote: > > __ppc_get_timebase() is GNU extension and is more efficient The commit title and log are quite short and give little idea on what this is about. I had a look at this glibc helper: /* Read the Time Base Register. */ static __inline__ uint64_t __ppc_get_timebase (void) { #if __GNUC_PREREQ (4, 8) return __builtin_ppc_get_timebase (); #else # ifdef __powerpc64__ uint64_t __tb; /* "volatile" is necessary here, because the user expects this assembly isn't moved after an optimization. */ __asm__ volatile ("mfspr %0, 268" : "=3Dr" (__tb)); return __tb; # else /* not __powerpc64__ */ uint32_t __tbu, __tbl, __tmp; \ __asm__ volatile ("0:\n\t" "mftbu %0\n\t" "mftbl %1\n\t" "mftbu %2\n\t" "cmpw %0, %2\n\t" "bne- 0b" : "=3Dr" (__tbu), "=3Dr" (__tbl), "=3Dr" (__tmp)); return (((uint64_t) __tbu << 32) | __tbl); # endif /* not __powerpc64__ */ #endif } The last block is exactly the code we had in dpdk. So I suppose we are trying to use mfspr for register 268 which seems linked to timebase (looking at the linux kernel sources). Please, confirm this is an enhancement (and how this improves current ppc support). Thanks. --=20 David Marchand