From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by dpdk.org (Postfix) with ESMTP id 47ABB2A5D for ; Sat, 18 Feb 2017 06:49:00 +0100 (CET) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id c40e7a85.2b6306616940.4775064.00-2464.10034975.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 18 Feb 2017 05:49:00 +0000 (UTC) X-MXL-Hash: 58a7e04c1a3fe467-4e44cef393b1f9b4d71850b45e4e1eaaf940ba1f Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo03.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 940e7a85.0.4775062.00-2308.10034962.nbfkord-smmo03.seg.att.com (envelope-from ); Sat, 18 Feb 2017 05:48:59 +0000 (UTC) X-MXL-Hash: 58a7e04b0aae1ac6-6a884ad8c706bf4120e291611bad8f707bb8db80 Received: from [192.168.38.17] (84.52.89.52) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sat, 18 Feb 2017 05:48:51 +0000 To: Jan Blunck , =?UTF-8?Q?N=c3=a9lio_Laranjeiro?= References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@platinum> <20170217124954.GO23344@autoinstall.dev.6wind.com> CC: Olivier Matz , "Ananyev, Konstantin" , "dev@dpdk.org" From: Andrew Rybchenko Message-ID: <7ec3bc4f-ba95-7611-73c1-5b07f5af0f8b@solarflare.com> Date: Sat, 18 Feb 2017 08:48:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-22892.003 X-TM-AS-Result: No--4.591000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=HuVwbhnS c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=RB3BGLmKESwA:10 a=IkcTkHD0fZMA:10 a=n2v9WMKugxEA:10 ] X-AnalysisOut: [a=4YC7WVefAAAA:8 a=JfrnYn6hAAAA:8 a=Vq5Vs9clWGeyBf8MjZwA:9] X-AnalysisOut: [ a=QEXdDO2ut3YA:10 a=tPzOKt3quolVTVSLigK1:22 a=1CNFftbPRP8] X-AnalysisOut: [L7MoqJWF3:22] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] 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: Sat, 18 Feb 2017 05:49:00 -0000 On 02/17/2017 04:51 PM, Jan Blunck wrote: > On Fri, Feb 17, 2017 at 1:49 PM, Nélio Laranjeiro > wrote: >> Hi Olivier, Jan, >> >> On Fri, Feb 17, 2017 at 11:51:53AM +0100, Olivier Matz wrote: >>> Hi Jan, >>> >>> On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck >>> wrote: >>>> 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. >> Olivier is right, this timestamp information is returned by the hardware >> as the other fields describing the Rx packet (length, RSS hash, checksum >> ...). The PMD only copy it into the Mbuf. >> > Indeed, for Mellanox the timestamp is stored in the CQ entry. > Solarflares write it relative to the packet header. Confirmed. We have pseudo-header just before the packet itself and timestamp is put to pseudo-header by the HW.