From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) by dpdk.org (Postfix) with ESMTP id E9F532C23 for ; Tue, 28 Feb 2017 10:24:02 +0100 (CET) Received: by mail-wr0-f177.google.com with SMTP id l37so4474321wrc.1 for ; Tue, 28 Feb 2017 01:24:02 -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=YatZt+ouFqvZOxjIeG5T43BtI+e5sDMUU/34lgQwnTU=; b=x7i4Ko5GHPcHtqj7begt715JNjc9L0O2EuBWtPhh5QKsdBfhd9aV6DOK2o0P1Tbp0A LvBXf4rsjouYgDS9JPsPnoE/brh8UjRTJ6oBXhQ7fatk5xjYGMIVW4WJLmYoEiU6XbOb sWscstHyD/Op5UrX/EPBB/9SU6g6Vfs6IR6cTIV31AkW8k642OE0Or2EFt1mO07MpYHW QJE8k0cpSxVZcd4sEebTdACCDRMlqGYcXBOnmfTsdhmORtOiLEGs8t6mBz92h1NwgT7e PgJoqlGU78QQXUQID4wWyqd5Z99W1kItAVXRtiEwi96ujYijC+AFJ408duDE0MsGveaI P0eQ== 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=YatZt+ouFqvZOxjIeG5T43BtI+e5sDMUU/34lgQwnTU=; b=BwU2NODeux76jemtKSRYwxhycs0kcBgusBZGvwIvpie4S9OZ8Z9zS3As6TYQas9kMi 8t8H4Q4YuFxcR8YpiM98OFhmgs1Bd7FMi8KG5bvS5QABGIKEkRZ6Ut6MkcGl6jeLNjdn /5mTPoyK6s/sA1XiuuwcRqWCk0MFt9mNENME6HSzeuIVO58soC0z+zuolymMzq0u3Wdr I5ma6twOkZuwU3jH8f7MfY9xA2njrKTmLy5WNEFxGp37NijwptdRnnzzTjvImRFbygz8 lclSvPu5G6E/H0MGTvJffYBIBlF1Y3GnkyoEU1zgLA1QV1u3iA5NJ5Neb8C79lMEsoez IsYA== X-Gm-Message-State: AMke39kPti4vucVPu4zuKeISpHJb4IuxfethR9WT3KwpihetJs1/1yb9LmWA5vppGZ+R3Dk+ X-Received: by 10.223.176.143 with SMTP id i15mr1380636wra.136.1488273842587; Tue, 28 Feb 2017 01:24:02 -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 m201sm1815340wmd.19.2017.02.28.01.24.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 28 Feb 2017 01:24:02 -0800 (PST) Date: Tue, 28 Feb 2017 10:23:59 +0100 From: Olivier Matz To: "Ananyev, Konstantin" Cc: Jan Blunck , "Richardson, Bruce" , "dev@dpdk.org" Message-ID: <20170228102359.5d601797@platinum> In-Reply-To: <2601191342CEEE43887BDE71AB9772583F11E992@irsmsx105.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <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> <2601191342CEEE43887BDE71AB9772583F11E992@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: Tue, 28 Feb 2017 09:24:03 -0000 Hi, On Tue, 28 Feb 2017 09:05:07 +0000, "Ananyev, Konstantin" wrote: > Hi everyone, > > > > > > > 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. > > One question - does that mean that application would need to > keep a track from what PMD each particular packet came to do the > normalization? Konstantin I'd say yes. It does not look very difficult to do, since the mbuf contains the input port id. > > > 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? I think timestamp is a good name. In the current RFC patchset, we have this comment: /** Valid if PKT_RX_TIMESTAMP is set. The unit is nanoseconds */ uint64_t timestamp; We could change it to something like: /** Valid if PKT_RX_TIMESTAMP is set. The unit and time * reference are not normalized but are always the same * for a given port. */ uint64_t timestamp; Regards, Olivier