From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 718522A5B for ; Tue, 24 Jan 2017 16:59:12 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP; 24 Jan 2017 07:59:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,278,1477983600"; d="scan'208";a="51961277" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.61]) by orsmga004.jf.intel.com with SMTP; 24 Jan 2017 07:59:09 -0800 Received: by (sSMTP sendmail emulation); Tue, 24 Jan 2017 15:59:08 +0000 Date: Tue, 24 Jan 2017 15:59:08 +0000 From: Bruce Richardson To: Olivier Matz Cc: dev@dpdk.org Message-ID: <20170124155908.GB172024@bricha3-MOBL3.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) 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, 24 Jan 2017 15:59:12 -0000 On Tue, Jan 24, 2017 at 04:19:25PM +0100, Olivier Matz wrote: > Based on discussion done in [1], this patchset reorganizes the mbuf. > Hi Olivier, thanks for all the work on this. From a quick scan of the patches, and the description below, it looks like a good set of changes. Comments below to see about kick-starting some further discussion about some of the other changes you propose. > The main changes are: > - reorder structure to increase vector performance on some non-ia > platforms. > - add a 64bits timestamp field in the 1st cache line > - m->next, m->nb_segs, and m->refcnt are always initialized for mbufs > in the pool, avoiding the need of setting m->next (located in the > 2nd cache line) in the Rx path for mono-segment packets. > - change port and nb_segs to 16 bits > - move seqn in the 2nd cache line > > Things discussed but not done in the patchset: > - move refcnt and nb_segs to the 2nd cache line: many drivers sets > them in the Rx path, so it could introduce a performance regression, or > it would require to change all the drivers, which is not an easy task. But if we do make this change and update the drivers, some of them should perform a little better, since they do fewer writes. I don't think the fastest vector drivers will be affected, since they already coalesce the writes to these fields with other writes, but others drivers may well be improved by the change. > - remove the m->port field: too much impact on many examples and libraries, > and some people highlighted they are using it. > - moving m->next in the 1st cache line: there is not enough room, and having > it set to NULL for unused mbuf should remove the need for it. I agree. > - merge seqn and timestamp together in a union: we could imagine use cases > were both are activated. There is no flag indicating the presence of seqn, > so it looks preferable to keep them separated for now. What were the use-cases? If we have a timestamp, surely sequence can be determined from that? Even if you use the TSC as a timestamp per burst, you can still sequence the packets cheaply by just adding 1 to each subsequent value. /Bruce