From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com [209.85.215.67]) by dpdk.org (Postfix) with ESMTP id EC44A2142 for ; Thu, 20 Oct 2016 12:57:22 +0200 (CEST) Received: by mail-lf0-f67.google.com with SMTP id b75so6945361lfg.3 for ; Thu, 20 Oct 2016 03:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=oDobqRuMwXoJgl3VkoonwdklWP1/0VpHunANaVrpvW8=; b=LU4hyt+T84hEVd8cdjMNWyITGiiY/0jXExCgbIBCYau+uqwmebJ0rhxepNbRXjaL7V IklVagBGUEqQD1Jnvecl+39i6jq37+pActGQ+CZc4MaSFawRXSw8033B6+FaxgvnWYTe ix8/qNluzSmR0VjNkSs28pTjkTv3BEZLqKN6iaN0EEJeEsRxpd3q56K+tr/fs3f0gy/C Le736Uhdq6ndkchy7d3GpiwJF9w5WndF9e0ulCwUlg8HjdUX1nCaxZbY0Q6w2Wc4MI+S qqXxN5GjXryPmf7W6PKxYfzGlH8nfQRtepdoiBq3TMwFPJAQiPA6ra9wgJerCvVmulVR PR/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=oDobqRuMwXoJgl3VkoonwdklWP1/0VpHunANaVrpvW8=; b=a9U9d7wxRDTsTzWjBliHN7Ra/QE2uoH5eDfofmHJHRDV3uxqeVfK8BYnSzr6vb8nsR dFWxU1IZv192YTUmEHDCdQTomcCWpqi9QI8gnLsL6cEI2GfoU5Qwjkw4uCbgK/eqZTcp ZmP+H2B0Sj7m60VL6kBw/PyywnTcfaBfHWd8JfJDHhWLCX7sYFv3qLp388zIsalE5Ja7 LR2mgumIwTEboHekoG+2N67gZDCr56Kq7jRLynAy7hD+w1W5Pad3yHQyLKvDk8hLgsYH bfDGrnf1W3eUVaELxIfpBskQAf8tV4ijmaghVm2H7RJOvqiKGaC2k2v+WXt/CtYxDKgR ffmQ== X-Gm-Message-State: AA6/9Rn6sMv/ECv7O7WruI3L3RiHbtBoRUF8fIr6CFWHcG94sB0Sm/QhgURHX403LxrYtu9ryvqhHi13THiCig== X-Received: by 10.28.140.129 with SMTP id o123mr25389wmd.51.1476961042420; Thu, 20 Oct 2016 03:57:22 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.216.195 with HTTP; Thu, 20 Oct 2016 03:57:21 -0700 (PDT) In-Reply-To: References: <1476369308-17021-1-git-send-email-olegk@mellanox.com> <1476369308-17021-2-git-send-email-olegk@mellanox.com> <2601191342CEEE43887BDE71AB9772583F0C3319@irsmsx105.ger.corp.intel.com> From: Jan Blunck Date: Thu, 20 Oct 2016 06:57:21 -0400 X-Google-Sender-Auth: _L1zo3WqKBePdFHRIv3jzCSCEq8 Message-ID: To: Oleg Kuporosov Cc: "Ananyev, Konstantin" , Olivier Matz , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the packet X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 10:57:23 -0000 On Thu, Oct 20, 2016 at 4:03 AM, Oleg Kuporosov wrote: > Hello Konstantin, > >> >> My vote also would be to have timestamp in the second cache line. >> About moving seqn to the 2-nd cache line too - that's probably a fair point. > > It may impact throughput till ~6% for applications required such embedded > Timestamps. > >> About the rest of the patch: >> Do you really need to put that code into the PMDs itself? >> Can't the same result be achieved by using RX callbacks? >> Again that approach would work with any PMD and there would be no need >> to modify PMD code itself. > > Correct, the approach with using callbacs (rte_eth_timesync_read_[r|t]x_timestamp()) > Has also some Cons for this use case: > - FSI needs the most accurate stamping as possible by reasons were described in > Cover letter >>From my experience this is only true if there is near-zero performance impact. From my perspective this is only relevant if the used hardware supports offloading of writing the timestamps. Everything else is a huge impact if its unconditionally enabled. The regulatory requirements are already covered by the exchange protocols which means that timestamps are already present in the network packet payload (generated by the exchange trading system and/or the trading application itself). In the end it is the exchange itself and its members that are regulated. I can see that this might be interesting for exchange members allowing sponsored naked access (for non-exchange members) to generate data that they are not front-running their clients. I doubt that this non-functional requirement is important enough to sacrifice the functional requirement of supporting QinQ. > - callback will be called from user app and so you have to take into account > Difference between time when packet was released by NIC and callback call Have you looked at using dedicated preallocated trace buffers that are filled with timestamps values? This should work fine for getting some inside into the latency between application readiness and the actual time the burst happened. Thanks, Jan > - such difference is not easy to estimate correctly due to dependency on CPU type, > Its frequency and current load conditions > - even estimated it would be hard without additional performance penalty to align > Packet with timestamp, taking account that call may actually placed from > Different thread or even process. > > It looks the least impacting and correct way is to have timestamp in rte_mbuf and fill > It in Rx burst procedure. > >> Another thing, that I am in doubt why to use system time? >> Wouldn't raw HW TSC value (rte_rdtsc()) do here? > > System time is being used for periodic clock synchronization between wall > clock and NIC to estimate NIC clock deviation. It is in assumption the system itself is > synchronized by PTP from master clock. It is run on context of control thread. > > Thanks, > Oleg.