From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 7B57D590E for ; Tue, 25 Oct 2016 14:05:42 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP; 25 Oct 2016 05:05:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,545,1473145200"; d="scan'208";a="23468311" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.210.150]) by orsmga005.jf.intel.com with SMTP; 25 Oct 2016 05:05:38 -0700 Received: by (sSMTP sendmail emulation); Tue, 25 Oct 2016 13:05:38 +0100 Date: Tue, 25 Oct 2016 13:05:38 +0100 From: Bruce Richardson To: Shreyansh Jain Cc: "Wiles, Keith" , Morten =?iso-8859-1?Q?Br=F8rup?= , "dev@dpdk.org" , Olivier Matz , alejandro.lucero@netronome.com Message-ID: <20161025120537.GA56680@bricha3-MOBL3.ger.corp.intel.com> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <7910CF2F-7087-4307-A9AC-DE0287104185@intel.com> <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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.1 (2016-10-04) Subject: Re: [dpdk-dev] mbuf changes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2016 12:05:43 -0000 On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote: > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote: > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote: > > > > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup wrote: > > > > > > > > First of all: Thanks for a great DPDK Userspace 2016! > > > > > > > > > > > > > > > > Continuing the Userspace discussion about Olivier Matz’s proposed mbuf changes... > > > > Thanks for keeping the discussion going! > > > > > > > > > > > > > > > > 1. > > > > > > > > Stephen Hemminger had a noteworthy general comment about keeping metadata for the NIC in the appropriate section of the mbuf: Metadata generated by the NIC’s RX handler belongs in the first cache line, and metadata required by the NIC’s TX handler belongs in the second cache line. This also means that touching the second cache line on ingress should be avoided if possible; and Bruce Richardson mentioned that for this reason m->next was zeroed on free(). > > > > > > Thinking about it, I suspect there are more fields we can reset on free > > to save time on alloc. Refcnt, as discussed below is one of them, but so > > too could be the nb_segs field and possibly others. > > > > > > > > > > > > > > 2. > > > > > > > > There seemed to be consensus that the size of m->refcnt should match the size of m->port because a packet could be duplicated on all physical ports for L3 multicast and L2 flooding. > > > > > > > > Furthermore, although a single physical machine (i.e. a single server) with 255 physical ports probably doesn’t exist, it might contain more than 255 virtual machines with a virtual port each, so it makes sense extending these mbuf fields from 8 to 16 bits. > > > > > > I thought we also talked about removing the m->port from the mbuf as it is not really needed. > > > > > Yes, this was mentioned, and also the option of moving the port value to > > the second cacheline, but it appears that NXP are using the port value > > in their NIC drivers for passing in metadata, so we'd need their > > agreement on any move (or removal). > > I am not sure where NXP's NIC came into picture on this, but now that it is > highlighted, this field is required for libevent implementation [1]. > > A scheduler sending an event, which can be a packet, would only have > information of a flow_id. From this matching it back to a port, without > mbuf->port, would be very difficult (costly). There may be way around this > but at least in current proposal I think port would be important to have - > even if in second cache line. > > But, off the top of my head, as of now it is not being used for any specific > purpose in NXP's PMD implementation. > > Even the SoC patches don't necessarily rely on it except using it because it > is available. > > @Bruce: where did you get the NXP context here from? > Oh, I'm just mis-remembering. :-( It was someone else who was looking for this - Netronome, perhaps? CC'ing Alejandro in the hope I'm remembering correctly second time round! /Bruce