From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 272363B5 for ; Fri, 17 Feb 2017 15:17:11 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id r141so11146900wmg.1 for ; Fri, 17 Feb 2017 06:17:11 -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=pRP+1fgIVZXTc7aXL1t5Vj19hh7H/jGnWy/NTh3TGlY=; b=vJC1du391iQ25i5X29hhWU1HPoNbeAKPuR5pxXjLd5uqS5hVH2ug5Zten2icJyo7ue ewlDFFkVaKTjkYTAGXpd7x+I9DbzdszBvzt1cpKrPsH5Hj7z/FbQMt2n4UoD0tOTuz5/ 83mH+LgnZfmEyANIHSGRuzRS4uJ4ZWNEvQ080XOxXd3lKYTrkZqrb5eb8kzU/Vo6KC32 MjLSgQ8quw19EDXde6/O1n55lWiqNu0XL79PqTZCYc6eN2NKzacYYFcJj7bFlg4utUeK neVsgMaSCtRkYVrTiEAcDc5Hgu8lSPKnZtjq86tixqWTKkEtyMkfLKezA3LJUa1XwI0+ apvQ== 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=pRP+1fgIVZXTc7aXL1t5Vj19hh7H/jGnWy/NTh3TGlY=; b=obLysEg9wk/4oE0OHzmJKJyXs0mXEAR3MKcgQeokG3P++xBG+2q98rdBAL0AD8zKUV xU56CTqDJtzv0GY7pKdgol686A6ZOX867FmEbpe5Q5ej1iS4CAuAJYdmgqtLItEQVfXG k0rjyC8Dy93wHuVadLvKqyrQZby29zD/AnPcsacA2xoc38dMzkkaIMPkQZnKspFPDR1W DbS3SfVHKZmUKMO3RiexhH5P8ay7Wn75dM6XRRM0o95ybgCEREeOGefCAbpDIp9IVUUc 08YGtN066hdh/EdNB3K5nfitFo/26y4b8rlw2QOwUsO50otQ8vCsFYDNvnI6ZGJxLUJ3 2n9A== X-Gm-Message-State: AMke39mt+myEqw4EcD9BpLNMkVVef2nBoEBrsTQHxL7BfMhaP71MjA40Phn1d//3zXG2myMf X-Received: by 10.28.224.213 with SMTP id x204mr2131212wmg.82.1487341031662; Fri, 17 Feb 2017 06:17:11 -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 b34sm10988736wra.4.2017.02.17.06.17.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Feb 2017 06:17:11 -0800 (PST) Date: Fri, 17 Feb 2017 15:17:08 +0100 From: Olivier Matz To: Jan Blunck Cc: "Ananyev, Konstantin" , "dev@dpdk.org" Message-ID: <20170217151708.20bf4a49@platinum> In-Reply-To: References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@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: 7bit 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 14:17:12 -0000 Hi Jan, On Fri, 17 Feb 2017 14:38:32 +0100, Jan Blunck wrote: > On Fri, Feb 17, 2017 at 11:51 AM, Olivier Matz > wrote: > > 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: > >> >> > > >> >> > 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 > >> >> > >> >> Wonder why it deserves to be in first cache line? > >> >> How it differs from seqn below (pure SW stuff right now). > >> > > >> > 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. > >> > > >> > >> 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. > > > > From 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. > > > > Mellanox NICs use a 48bit cycle counter split into a high and low > part. To convert the cycle values into a timestamp you need to > initialize and maintainer a timecounter that shifts the cycle count > e.g. nanosecs. IIRC Mellanox doesn't generate explicit clock events > but the cycle counter is large enough so that the user can easily > maintain the timecounter by manually updating it. > > >> > >> 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. > > My point is that I still doubt that it belongs into the first > cacheline. It requires accessing other structures for converting into > nanoseconds anyway. Optimally I would like to see this happening on > access instead but if that isn't achievable at least in a second step. Sorry, I don't really get your point. My comprehension of the timestamp usage in a PMD is as following: rx_burst(struct rxq *rxq, ...) { unsigned long factor = rxq->timestamp_factor; unsigned port = rxq->port; for each hw_desc { m = rte_pktmbuf_alloc(rxq->pool); m->len = hw_desc->len; m->port = port; m->ol_flags = ... m->timestamp = hw_desc->timestamp * factor; } ... } In that case, I think it deserves to be in the 1st cache line. Olivier