From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <kannan.babu.ramia@intel.com> Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id B63C6968 for <dev@dpdk.org>; Tue, 25 Oct 2016 15:04:56 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 25 Oct 2016 06:04:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,545,1473145200"; d="scan'208,217";a="23779537" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 25 Oct 2016 06:04:51 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 25 Oct 2016 06:04:51 -0700 Received: from bgsmsx105.gar.corp.intel.com (10.223.43.197) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 25 Oct 2016 06:04:51 -0700 Received: from bgsmsx102.gar.corp.intel.com ([169.254.2.202]) by BGSMSX105.gar.corp.intel.com ([169.254.3.189]) with mapi id 14.03.0248.002; Tue, 25 Oct 2016 18:34:47 +0530 From: "Ramia, Kannan Babu" <kannan.babu.ramia@intel.com> To: Olivier Matz <olivier.matz@6wind.com>, =?Windows-1252?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com> CC: "Wiles, Keith" <keith.wiles@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [dpdk-dev] mbuf changes Thread-Index: AdIuDi107p4k5g0aQEmWpCYJ+64TpwAPchyA//8yYwCAAFndAIAAukEAgAATP4CAAAVugIAALESAgABdW+Q= Date: Tue, 25 Oct 2016 13:04:47 +0000 Message-ID: <5wj6euqlvai26vmpn4dcfe4p.1477400683290@email.android.com> References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk> <7910CF2F-7087-4307-A9AC-DE0287104185@intel.com> <20161024162538.GA34988@bricha3-MOBL3.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC359EA8B2@smartserver.smartshare.dk> <20161025085353.GA33668@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F0CC6A7@irsmsx105.ger.corp.intel.com> <98CBD80474FA8B44BF855DF32C47DC359EA8B8@smartserver.smartshare.dk>, <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> In-Reply-To: <39b70924-0e66-478c-36ea-dd18d27ed8a6@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Tue, 25 Oct 2016 13:04:57 -0000 Port filed is important meta information for the application use like CGNAT= vEPC functions etc. I strongly recommend to keep the field in mind meta. Sent from my ASUS -------- Original Message -------- From:Olivier Matz Sent:Tue, 25 Oct 2016 18:31:36 +0530 To:Morten Br=F8rup ,"Ananyev, Konstantin" ,"Richardson, Bruce" Cc:"Wiles, Keith" ,dev@dpdk.org Subject:Re: [dpdk-dev] mbuf changes Hi, On 10/25/2016 12:22 PM, Morten Br=F8rup wrote: > Comments inline (at the end). > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, >> Konstantin >> Sent: Tuesday, October 25, 2016 12:03 PM >> To: Richardson, Bruce; Morten Br=F8rup >> Cc: Wiles, Keith; dev@dpdk.org; Olivier Matz >> Subject: Re: [dpdk-dev] mbuf changes >> >> Hi everyone, >> >>> -----Original Message----- >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson >>> Sent: Tuesday, October 25, 2016 9:54 AM >>> To: Morten Br=F8rup <mb@smartsharesystems.com> >>> Cc: Wiles, Keith <keith.wiles@intel.com>; dev@dpdk.org; Olivier Matz >>> <olivier.matz@6wind.com> >>> Subject: Re: [dpdk-dev] mbuf changes >>> >>> On Mon, Oct 24, 2016 at 11:47:16PM +0200, Morten Br=F8rup wrote: >>>> Comments inline. >>>> >>>> Med venlig hilsen / kind regards >>>> - Morten Br=F8rup >>>> >>>>> -----Original Message----- >>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce >>>>> Richardson >>>>> Sent: Monday, October 24, 2016 6:26 PM >>>>> To: Wiles, Keith >>>>> Cc: Morten Br=F8rup; dev@dpdk.org; Olivier Matz >>>>> Subject: Re: [dpdk-dev] mbuf changes >>>>> >>>>> On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote: >>>>>> >>>>>>> On Oct 24, 2016, at 10:49 AM, Morten Br=F8rup >>>>>>> <mb@smartsharesystems.com> >>>>> wrote: >>>>>>> >>>>>>> 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=92t 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). >>>>> >>>> If a single driver instance services multiple ports, so the ports >>>> are not polled individually, the m->port member will be required to >>>> identify >>> the port. In that case, it might also used elsewhere in the ingress >> path, and thus appropriate having in the first cache line. >> >> Ok, but these days most of devices have multiple rx queues. >> So identify the RX source properly you need not only port, but >> port+queue (at least 3 bytes). >> But I suppose better to wait for NXP input here. >> >>> So yes, this needs >>> further discussion with NXP. > > It seems that this concept might be somewhat similar to the Flow Director= information, which already has plenty of bits in the first cache line. You= should consider if this can be somehow folded into the m->hash union. I'll tend to agree with Morten. First, I think that having more than 255 virtual links is possible, so increasing the port size to 16 bits is not a bad idea. I think the port information is more useful for a network stack than the queue_id, but it may not be the case for all applications. On the other hand, the queue_id (or something else providing the same level of information) could led in the flow director structure. Now, the question is: do we really need the port to be inside the mbuf? Indeed, the application can already associate a bulk of packet with a port id. The reason why I'll prefer to keep it is because I'm pretty sure that some applications use it. At least in the examples/ directory, we can find distributor, dpdk_qat, ipv4_multicast, load_balancer, packet_ordering. I did not check these apps in detail, but it makes me feel that other external applications could make use of the port field. Regards, Olivier