From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id C40C598 for ; Tue, 21 Feb 2017 17:38:12 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 21 Feb 2017 08:38:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,190,1484035200"; d="scan'208";a="68429328" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by fmsmga006.fm.intel.com with SMTP; 21 Feb 2017 08:38:09 -0800 Received: by (sSMTP sendmail emulation); Tue, 21 Feb 2017 16:38:09 +0000 Date: Tue, 21 Feb 2017 16:38:09 +0000 From: Bruce Richardson To: Jan Blunck Cc: Olivier MATZ , "Ananyev, Konstantin" , "dev@dpdk.org" Message-ID: <20170221163808.GA213576@bricha3-MOBL3.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.2 (2016-11-26) 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 16:38:13 -0000 On Tue, Feb 21, 2017 at 05:12:12PM +0100, Jan Blunck wrote: > On Tue, Feb 21, 2017 at 10:54 AM, Olivier MATZ wrote: > > Hi Jan, > > > > On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck > > wrote: > >> On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz > >> wrote: > >> > > >> > Sorry, I don't really get your point. My comprehension of the > >> > timestamp usage in a PMD is as following: > >> > > >> > rx_burst(struct rxq *rxq, ...) > >> > { > >> > unsigned long factor = rxq->timestamp_factor; > >> > unsigned port = rxq->port; > >> > > >> > for each hw_desc { > >> > m = rte_pktmbuf_alloc(rxq->pool); > >> > m->len = hw_desc->len; > >> > m->port = port; > >> > m->ol_flags = > >> > ... > >> > m->timestamp = hw_desc->timestamp * factor; > >> > } > >> > ... > >> > } > >> > > >> > In that case, I think it deserves to be in the 1st cache line. > >> > > >> > >> Timestamps are non-functional data. I believe they don't deserve to be > >> data normalized. > > > > I don't really see why timestamp is non-functional, compared to rss > > hash, flow director id, packet type, seqn, ... > > > > One doesn't drop, forward, reorder or decrypt packets based on the > timestamp value. > > Common use cases for timestamps are analytics applications or circuit > breakers where you want to ensure that your algos don't act upon stale > data. This is more application layer / slow path work. > > > I think the goal of DPDK is to provide a generic/normalized API for > > such features (like for offload), so it can be used by an application > > whatever the underlying driver. > > > > I believe there is a difference between dataplane relevant > functionally and non-functional features. If you structurally > normalize the later you will end up making everyone pay for a feature > that is only relevant to a particular group of users. In that case I > would at least expect that the support for timestamps can get selected > at compile time. > > >> > >> It would be beneficial to normalize the access of non-functional data. > >> That would require some kind of extension or feature flags, e.g. like > >> some uverb structures support extensions. This would allow the NICs > >> that support timestamps to do the minimal amount of work during burst > >> and defer data normalization to the time of access. That would also > >> safe everyone from wasting 64bit in the first cacheline in case > >> timestamps are not supported or unused. > > > > I agree that we could start to think about "extensible" mbufs. In few > > words, I think we could have: > > - only general fields are static > > - the application registers room in mbuf structure for all features it > > will use > > It would rationalize the room used in mbuf, at the cost of a more > > complex/slow access to the data in PMDs and application, since the > > offset won't be static. > > > > 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. /Bruce