From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 104F22A5D for ; Fri, 17 Feb 2017 11:51:57 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id v77so7335908wmv.0 for ; Fri, 17 Feb 2017 02:51:57 -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=BiehDa0Tpin0IWukYI4rQ0tWoMqKw9EcmTAhs0D/zD8=; b=IgDpQ1vC2UyiFN7PZW93EXefaC/Ub7q9xc8BHG5uKWbC2RfSTo/pF1oCr2c+AgRQNu kVQnQ83FEE8xnBhH4CI7kCOXHDRMxKv2qvjx0jqf2VMEwpkfXGdcoPTA+ycmxWjGpiC/ HrkRQstRqCn9HuvDqv7dqzWayn93akbSSq+9N6cSSsgO572/8XH+BspIwz95h/cHZJ0a 9dzaCezlkN7BSNxdxwNfIUqeqRYfC4Ea3qGAW4aPyR0w+SSV0Nd2BZwcRBxlxHIsVoHs DPuh/wwYih2zAnJ5fxwuINt9tvUVeuCzWnNkz50JSz7c+PshMTs21y2xRzX2daJbXN+E iuHw== 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=BiehDa0Tpin0IWukYI4rQ0tWoMqKw9EcmTAhs0D/zD8=; b=Wmnrw/zvIax/PNlKF8bgLbLe6vIje1dRuXGDw5svY0GbQR34fl5Wa+ccz42GIa5LEk aByzzK5XHLUd/x4sSznYwP+6tujGFvppeePGRq5V5v6r+bD0dQIHLmVr47Kz1zaTy/oH 2sYvA7S3TE0Rn5F3bUtqPQQxeQSnfVDwywI6EcQJJUOaYSxUvDJGb2TRwrsQI6WRiIye Zv8rtFrSWMKCY+k8G2zt0D4RBzNofT9Ydx9rsjes3tQ3B7BB6Vyzp3Z6s6aJBcmbdSAn pdQhHUtuokjlTSfv1mo+Md/4IdmlE1zLWcF6/jHAXgMFe6+2EIsteyDnyIkM7HUw7yTo eF/A== X-Gm-Message-State: AMke39mFqu6IkAP7moIln3oqWPIu0r8R987Z56U5W2jbHq8XB6wgR7yN1Sj/avzowMhTFzVp X-Received: by 10.28.35.142 with SMTP id j136mr2620190wmj.11.1487328716796; Fri, 17 Feb 2017 02:51: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 c9sm1218258wmf.18.2017.02.17.02.51.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Feb 2017 02:51:56 -0800 (PST) Date: Fri, 17 Feb 2017 11:51:53 +0100 From: Olivier Matz To: Jan Blunck Cc: "Ananyev, Konstantin" , "dev@dpdk.org" Message-ID: <20170217115153.0afeb061@platinum> In-Reply-To: References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> 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=US-ASCII 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, 17 Feb 2017 10:51:57 -0000 Hi Jan, On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck wrote: > On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz > wrote: > > On Mon, 6 Feb 2017 18:41:27 +0000, "Ananyev, Konstantin" > > wrote: =20 > >> > > >> > The main changes are: > >> > - reorder structure to increase vector performance on some non-ia > >> > platforms. > >> > - add a 64bits timestamp field in the 1st cache line =20 > >> > >> Wonder why it deserves to be in first cache line? > >> How it differs from seqn below (pure SW stuff right now). =20 > > > > In case the timestamp is set from a NIC value, it is set in the Rx > > path. So that's why I think it deserve to be located in the 1st > > cache line. > > > > As you said, the seqn is a pure sw stuff right: it is set in a lib, > > not in a PMD rx path. > > =20 >=20 > If we talk about setting the timestamp value in the RX path this > implicitly means software timestamps. Hardware timestamping usually > works by letting the hardware inject sync events for coarse time > tracking and additionally injecting fine granular per-packet ticks at > a specific offset in the packet. Out of performance reasons I don't > think it makes sense to extract this during the burst and write it > into the mbuf again. =46rom what I've understand, at least it does not work like this for mellanox NICs: timestamp is a metadata attached to a rx packet. But maybe they (and other NIC vendors interrested in the feature) can confirm or not. >=20 > The problem with timestamps is to get the abstraction right wrt the > correction factors and the size of the tick vs. the timestamp in the > events injected. From my perspective it would be better to extract the > handling of timestamp data into a library with PMD specific > implementation of the conversions. That way the normalized timestamp > values can get extracted if they are present. The mbuf itself would > only indicate the presence of timestamp metadata in that case. I agree however that we need to properly define the meaning of this field. My idea is: - the timestamp is in nanosecond - the reference is always the same for a given path: if the timestamp is set in a PMD, all the packets for this PMD will have the same reference, but for 2 different PMDs (or a sw lib), the reference would not be the same. I think it's enough for many use cases. We can later add helpers to compare timestamps with different references. Regards, Olivier