From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id D3D872B88 for ; Fri, 24 Feb 2017 15:00:57 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id t18so8785569wmt.0 for ; Fri, 24 Feb 2017 06:00: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=xSy0V1EnY59dOjQOypGGvVaqcdjzoPtuj5SojVGz1cc=; b=W7ppZOp74kWI8LDNZFFHJGVE98ByKw77rOYLLaNVanItCrEQFBG6ig251Hd72lvfcO 4YQPFsOQgE1jZL+dc5FV2rGdVDxXhT7Ss7p8H9zVPI8trsDRJ0LjZXnOBmw8ifhqBK+M 2vOpN1HxZtr7b34IyhgbT8u/4eCAmYoFD1g5PAmKdomLvIAu+m9JA8LPCqBtngpMqyOo sgJuVb1tVSaHsAvkiz8tM/fR1997KQQNmHgY1zj+bqEk/Oa75sJjDRuCPNGx7dBo/Bij UJea0k0Cpbkv0TEQcCYWOiwb2VPeeiPi+ELQBwu7sFs2YWHc1ZWAbtx0lQxwKH3eHcHu ehTQ== 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=xSy0V1EnY59dOjQOypGGvVaqcdjzoPtuj5SojVGz1cc=; b=b/BeuN2sr+6PFPi2ICnAV7WDF4HayJJj6PmjsvcfvNBj99DQTewGIVSI9ps9AYhkx4 gFRDgYaQ2ZKglELvlVGR9PIP/1oFfc93BC1ckVgYoEN0cNMavDfocUdZUHPiIrrWa7bc 54YfWYFUetY0uConXeB3ObDpGnkdq79Nfnb/nnUkvdZuwGghRpxeh55qJWR2FPrqCQzA mCM3MJTEED4j0ban0HVzhyDxOaAUtcQWOPH/qVo47fygyni7dICA9UFCk1RPQQHDpstv 5wASHuqTwCXcWHBjd4+0sOvt7sao63Gw6CjLK012z6nLvQ1yVv5r8yZyCjQs8uWUYGMh vDeA== X-Gm-Message-State: AMke39k3zHHdidWygqdxdXZ01HvE8BiJr+ODmekkd8rkSBwDQqX7b8TSLHRspdUxNMTjtrhh X-Received: by 10.28.54.139 with SMTP id y11mr1011142wmh.112.1487944857517; Fri, 24 Feb 2017 06:00:57 -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 u40sm10471667wrc.46.2017.02.24.06.00.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 06:00:57 -0800 (PST) Date: Fri, 24 Feb 2017 15:00:53 +0100 From: Olivier Matz To: "Ananyev, Konstantin" Cc: Jan Blunck , "Richardson, Bruce" , "dev@dpdk.org" Message-ID: <20170224150053.279e718d@platinum> In-Reply-To: <2601191342CEEE43887BDE71AB9772583F11B633@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> <2601191342CEEE43887BDE71AB9772583F11B633@irsmsx105.ger.corp.intel.com> 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, 24 Feb 2017 14:00:58 -0000 Hi, On Tue, 21 Feb 2017 20:30:57 +0000, "Ananyev, Konstantin" wrote: > > -----Original Message----- > > From: jblunck@gmail.com [mailto:jblunck@gmail.com] On Behalf Of Jan > > Blunck Sent: Tuesday, February 21, 2017 7:18 PM > > To: Ananyev, Konstantin > > Cc: Richardson, Bruce ; Olivier MATZ > > ; dev@dpdk.org Subject: Re: [dpdk-dev] [RFC > > 0/8] mbuf: structure reorganization > > > > 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. > > Yes, postponing normalization might help a bit (though I don't think > much) in terms of calculations performed inside PMD. > But we still need 8B inside mbuf to store the timestamp value, > either normalized or raw one. > So to clarify where is the disagreement: > 1. timestamp position: > mbufs 1-st cacheline vs 2-nd cacheline In my opinion, if we have the room in the first cache line, we should put it there. The only argument I see against is "we may find something more important in the future, and we won't have room for it in the first cache line". I don't feel we should penalize today's use cases for hypothetic future use cases. > 2. timestamp normalization point > inside PMD RX vs somewhere later as user needs it (extra > function in dev_ops?). This point could be changed. My initial proposition tries to provide a generic API for timestamp. Let me remind it here: a- the timestamp is in nanosecond b- 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. We may remove a-, and just have: - the reference and the unit are 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 and unit, but for 2 different PMDs (or a sw lib), they would not be the same. In both cases, we would need a conversion code (maybe in a library) if the application wants to work with timestamps from several sources. The second solution removes the normalization code in the PMD when not needed, it is probably better. About having the timestamp in the packet data, I don't think it is a good solution for a generic API in DPDK. The timestamp is a metadata, it has to go in the mbuf metadata. The packet data should not be modified when the timestamp is enabled. But this would not prevent to have driver-specific features to do that. In that case, the application will be aware that it is using this specific driver and that it will receive a timestamp in the packet data. To summarize, the generic API could be: - an ethdev API to enable the timestamp in a PMD for received packets - a mbuf flag "timestamp present" - a mbuf 64b field to store the timestamp value Additionally, a driver-specific API can be added for a given PMD. Example: - the generic timestamp ethdev is disabled (or not supported) - a driver-specific feature "put timestamp in packet" is enabled It would have no additional cost compared to what we have today, since the timestamp in mbuf is not read/written. Olivier