From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 3460A37AA for ; Fri, 24 Feb 2017 15:11:56 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id v186so15506685wmd.0 for ; Fri, 24 Feb 2017 06:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=iYtv8Xi060WqIds8etv1mHCYyMjyhknsXF3HMkilpLo=; b=bSM0c5btYWHmLV6PWi2orZgvmiTyjnniVpc2ALi8PZC50dmFvWQCeLEXNB7l0S7d6f g4/grIqNmIMIa8+9xHipuWv12wgGndrmM7L8Yl5dBCKpC67WJcMI45zGR02PlGTlkE+2 fnf4W3W8y8a6aGfYsL+hBAg3gtX6vg8GbzshNeU8MK25AZUjMVNx79mIcQTUbNhnVbUU mmf/SlwIe2aCm3y1LWNCY6f9aP4Pz0/ES32WVZu1DaJYq/xSTS2Gqh9U51GBShhc2bTi Q5TDIHLj94qniWRYL/952LVOo1QQ+pHS2Z7HGfwTu9GKkIKe0bO0+qMU4G9O/8DVLOg6 sYMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iYtv8Xi060WqIds8etv1mHCYyMjyhknsXF3HMkilpLo=; b=p7x33IiAkMT2Zn1eka4KWzmBYiYgKzdztFUuKAGIN+YNo+Di8qyAkEl2saOvFCeOdP iWP1pN5GPUmcbLQ7Oq+dA9yLB8ZbFLWeRwAiWUStwp2/gQfT0NMRUZ2Oki6DCF4arihb AVTUrsJjcZEJTt5fQTgYI39j//tbx+wn3oRxHsdMYPCY0iqUDczuygR9cdu0OktaQZNJ Zq6ie8/kaVYRqnsjD4w2QjNOJRbRA0gna7y1pFeBj+JlMzXOW33ejvt7uyRkhOZiIXZh +3kxF49c5RzXPEsbZ3UFswnNwKP/43PklAelNLKIIrv/v9+y30a0Wx0lpr+dNMF8n4O9 9BhQ== X-Gm-Message-State: AMke39kLHoR5V2muFrCFzdZ9UUk49nGkfOtqmMEcIaTcA6SJl4WKeSbXtFZJDjY24ahgVxu6 X-Received: by 10.28.61.84 with SMTP id k81mr2791292wma.27.1487945516605; Fri, 24 Feb 2017 06:11:56 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id 73sm2496328wml.19.2017.02.24.06.11.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 06:11:56 -0800 (PST) Date: Fri, 24 Feb 2017 15:11:54 +0100 From: Olivier Matz To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "Ananyev, Konstantin" , "Jan Blunck" , "Richardson, Bruce" , Message-ID: <20170224151154.016df2cd@platinum> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EAD15@smartserver.smartshare.dk> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@platinum> <20170217151708.20bf4a49@platinum> <20170221105400.2eba4747@glumotte.dev.6wind.com> <20170221163808.GA213576@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F11B4CC@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F11B633@irsmsx105.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC359EAD15@smartserver.smartshare.dk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization 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: , X-List-Received-Date: Fri, 24 Feb 2017 14:11:57 -0000 On Tue, 21 Feb 2017 22:51:00 +0100, Morten Br=C3=B8rup wrote: > Regarding m->timestamp I have previously argued for keeping it NIC > specific, and not normalizing it. But I have changed my mind: > Normalizing it makes gives the user the ability to transparently swap > out a NIC from one vendor with one from another vendor. And with a > hardware timestamp from the NIC, the normalization only involves > multiplying by a constant factor, as Olivier pointed out previously. > So if the resolution is high enough, a normalized value is > preferable. 1 ns is roughly 10 bytes at 100 Gbit/s, so I suppose a > resolution of 1 ns suffices. >=20 > But how about NICs without hardware timestamps... >=20 > 1. Are their PMDs supposed to set the timestamp or not, and are they > supposed to ensure that two packets received by the same port do not > carry the same timestamp? The timestamp would only be set if the user asks for it through an ethdev API. For NICs that do not support timestamps, the PMD can either not support it, or implement it in software. I don't think they should ensure that two packets do not carry the same timestamp. It depends on the unit, and on the precision of the measure. > 2. And if the CPU clock frequency is not constant, normalizing a > software generated timestamp is not just a matter of multiplying the > CPU's cycle counter with a constant factor - which could be important > if the timestamps are used for some sort of metrics analysis. (I have > no knowledge about such use cases, I'm just mentioning potential > pitfalls here.) Since timestamp is a time reference, its unit has to be a constant clock. On the CPUs I know, even when the internal frequency is not constant, there is a also time reference with a constant clock (ex: the tsc on Intel). >=20 > I guess a lot of NICs aren't configured to provide packet timestamps, > so in order to avoid code duplication in a bunch of PMDs, a software > timestamping library (or common set of helper functions) might be > handy for the PMDs. Yes > Furthermore, the timers on separate NICs will be unsynchronized > anyway (regardless if the timestamps are generated by hardware or > software), so the timestamps are out of order when considering > multiple ingress ports anyway. >=20 > Generally, I support the idea of making the somewhat exotic features > compile time optional. In that context, it is a question of defining > what is common, and what is exotic. But +1 to Jan's suggestion about > making it compile time optional for the PMDs to set the m->timestamp, > since they are probably not used by typical data plane packet > forwarding applications, and they cost a few instruction cycles for > each packet. Even though this cost is small, adding a more such > exotic features with small individual costs will eventually make > their total cost significant. I don't agree. Having compile-time options is something we should try to avoid (knowing the DPDK is also a set of libraries provided by distros). If the timestamp can be enabled/disabled at port initialization, I think the cost of the feature will be negligible (it can be one test for a bulk of packets). Olivier