From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 5C4BE2A5E for ; Tue, 21 Feb 2017 20:17:43 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id u63so21345486wmu.2 for ; Tue, 21 Feb 2017 11:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cO9gnb7prxkfrCakT94+09ZZl3PxL3DNZQHLNGrbhr8=; b=La4eRk1majbvibK2w7pgy95lPLL4sZgP44sWIPkpHYcrzilyePjoqfkdctb4p7hhCK DLn5Yos/tjiCm/IliSQb2jBFdLTqkb1RYXxorycXujK5q5SZRrEfz1ZW+N8WnIAAzt9K kcDPV8z04K12yZgEYNlMipxoeau8CnRpycrDs0bfPgEoi5w77LBuvx4m9a1ERFEUZ6PB Ax2+V79aR8ta5LO+hPlmovmDzE6S6brwqTurRpCO91Gtsk0jzyynJOYDZDnydcowOCrA S8zumDTSm+dvv/PG9fy8aObh+7E49dCdBjCoGfHQSjrKs/kaTQUQV+FkEzLvzJIKs0X8 FCtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cO9gnb7prxkfrCakT94+09ZZl3PxL3DNZQHLNGrbhr8=; b=rYxmRlWFBaXHCBkpnQHhFKdEpQrggboZH3VbXY8YGEeEUoslaQOtx1BStNvPsggQmQ S5IwYEktxj1wu+o/bOhqhpNTWaEQnwBgnJB5fPCIQeXVelqJNGaoViSVkBr/R1Og4/GY +cssoq47o2AiNVK8L9PtSrdfpprDCqwwP/7qdFsUq1luZfrgoFtOlIbUdywcU8Vb+9CO cRIZ6KtAkenOTXRqMHnjC15soaXylwcCOgMssgeq53FrOPi8sGhNu86FJTSpTdTzYENN mw5X9IVDrCzHII93Bww/Kyyms2viVnHnL09jsr/lFr1+9iFwE3cSN1+U6Wd/A+mTwHZQ 80dA== X-Gm-Message-State: AMke39kb/k6wIxV+siSLuwMOwluTArCW8eGqRxGyT+KZrCLNH2qo66LHChiXvlu97lbzfYsRTMikIEA2Jl22cA== X-Received: by 10.28.131.72 with SMTP id f69mr16612273wmd.140.1487704663148; Tue, 21 Feb 2017 11:17:43 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Tue, 21 Feb 2017 11:17:42 -0800 (PST) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F11B4CC@irsmsx105.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.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> From: Jan Blunck Date: Tue, 21 Feb 2017 20:17:42 +0100 X-Google-Sender-Auth: hNW_anY1lSfxcDbCGLIbVAg5aro Message-ID: To: "Ananyev, Konstantin" Cc: "Richardson, Bruce" , Olivier MATZ , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 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: Tue, 21 Feb 2017 19:17:43 -0000 On Tue, Feb 21, 2017 at 6:26 PM, Ananyev, Konstantin wrote: > Hi Jan, > >> -----Original Message----- >> From: jblunck@gmail.com [mailto:jblunck@gmail.com] On Behalf Of Jan Blunck >> Sent: Tuesday, February 21, 2017 5:05 PM >> To: Richardson, Bruce >> Cc: Olivier MATZ ; Ananyev, Konstantin ; dev@dpdk.org >> Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization >> >> On Tue, Feb 21, 2017 at 5:38 PM, Bruce Richardson >> wrote: >> > On Tue, Feb 21, 2017 at 05:12:12PM +0100, Jan Blunck wrote: >> >> >> >> Access through PMD specific function pointers should be relatively >> >> fast on access. Modern architecture optimize that use case well >> >> enough. >> >> >> > The cost of doing a function call per packet to access data starts to >> > add up very, very fast. For the app, once the data is written to the >> > mbuf, it should be in the L1 cache, giving very fast access to it in a >> > few cycles. However, if a function call has to be made in order to do >> > the read, that makes the read of that field many times more expensive. >> > >> >> Exactly. Right now the timestamp normalization is done before writing >> to each mbuf. Timestamps are usually read at most once ... if at all. > > Well we don't know for sure right? > Someone can argue that there are plenty of scenarios when > other fields might also never be used/updated (rss, vlan, etc). > > So, are you suggesting to do normalization later? > If so, then what would be the benefit (data still need to be in mbuf)? Yes, postponing normalization prevents you from doing unnecessary work upfront. AFAIK not all NICs store timestamp data OOB, e.g. in CQ. > >> If you look at the analysis use cases they are read to be written to >> persistent storage. > > Probably, or some statistic calculations, I guess. > Or might be someone would use it to reorder packets before sending > them out based on the timestamp, or might be something else. Those timestamps are generated at arrival in the hardware. So that order would be relative to the point of reception and in case you want to resync flows that doesn't help much. For statistics calculation and the resync use case you also might want the raw timestamp (not normalized to nsec) and offload the normalization out of band to reduce overall latency. > It really hard to predict what use cases would come up (at least for me). > Indeed. I also just have the limited view of what I used timestamps for so far. Who knows what use cases other people come up with in the future.