From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 0F0F72A5E for ; Tue, 28 Feb 2017 09:55:58 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id r18so1199965wmd.3 for ; Tue, 28 Feb 2017 00:55:58 -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=xRNYPyUm44gBZwtlB/8CDaw9kd2C7iqAtkF0l/5T8g0=; b=HfWw/sWM6KtX5RSDx7+CBTrUxDKVci/CiRkGhLsgPTbzgY3coHnC7Ql3uS50SSmpUS pjyjx7M6Q+5+9ns6HMgvFogpchb/YudLCzQtaxquF9EsbivzHmUAzV72yyznfmd4C945 wBNs0045swKrPQbdwma6ER2Y9IVUlr23RFT7QsSGX5WrOFrHtowSHS8xJrpzduk7CPCC 7vb+32pMWi1hDaCtpf3BfXi5/5knKwxA6uTB5qKcMtUavF5BhSMPaAHt4Q233UlKxBab dsNlknhpY0jl47zizYHL1rberdehfRiM0VB2v9YK+STARHgumyGvkmsBPf5MCZz+S+g8 ci8w== 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=xRNYPyUm44gBZwtlB/8CDaw9kd2C7iqAtkF0l/5T8g0=; b=snbBYsKavoPpb92Lc/4dWHILmuGnAQ/4OVXVc30IQk/J/N+stmhRHqz4iW5Ru/5pyY 6nHVXeESxbNWaDh5R5eEudfScfV9NPDJl8Ata4FuC519b0w8uDhzfM7R3Sam4Q2Ju7lb iSKdMhWHiw9HW/VGv3c8r+vI4rmZ0zoAwdoVhwQNcC0OOUkrYJmff1X3yz1TLEIoN/pm hdEkZ+WhzOTPOXZ/OuyXJkuqVJqzsE7DBM4gLF/3D9gIXfEE06srwbPmlLqKLmB904xW 14X2isMzdcCu11Bf7bXURC++z7lbciSx4KVcKRyPsEfNJt5gtgOX44B3BqUZDTp8fS7+ eakA== X-Gm-Message-State: AMke39mcNkOMDPd4ffyki1c2uGuc0FWkZVNbMgu47zPeYTi3HKsuGZ1yfONSUELHwpS7Ku50zCYvShuF1WYHBg== X-Received: by 10.28.183.4 with SMTP id h4mr4674793wmf.140.1488272158728; Tue, 28 Feb 2017 00:55:58 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Tue, 28 Feb 2017 00:55:57 -0800 (PST) In-Reply-To: <20170224150053.279e718d@platinum> 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> <20170224150053.279e718d@platinum> From: Jan Blunck Date: Tue, 28 Feb 2017 09:55:57 +0100 X-Google-Sender-Auth: _ZaBRxXx7R06MZNT2KC70LcXmTI Message-ID: To: Olivier Matz Cc: "Ananyev, Konstantin" , "Richardson, Bruce" , "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, 28 Feb 2017 08:55:59 -0000 On Fri, Feb 24, 2017 at 3:00 PM, Olivier Matz wrote: > > 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. I agree. > > 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. Good NICs already do that based on the packet type (e.g. NTP/PTP packets). > > 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. > Thanks for the writeup. This sounds like a reasonable approach to me. Do you still want to call the 64bit field "timestamp" or rename it to something neutral and document that it is used together with the mbuf flags?