From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 19A4B106A for ; Thu, 8 Dec 2016 12:02:19 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 08 Dec 2016 03:02:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,319,1477983600"; d="scan'208";a="910038472" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga003.jf.intel.com with ESMTP; 08 Dec 2016 03:02:17 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.79]) by IRSMSX104.ger.corp.intel.com ([169.254.5.52]) with mapi id 14.03.0248.002; Thu, 8 Dec 2016 11:02:17 +0000 From: "Van Haaren, Harry" To: Jerin Jacob CC: "dev@dpdk.org" , "thomas.monjalon@6wind.com" , "Richardson, Bruce" , "hemant.agrawal@nxp.com" , "Eads, Gage" Thread-Topic: [dpdk-dev] [PATCH v2 1/6] eventdev: introduce event driven programming model Thread-Index: AQHST3Q6miHoZHXUrUSff5InwKg5VKD8TjTAgAD2dQCAAJkcYA== Date: Thu, 8 Dec 2016 11:02:16 +0000 Message-ID: References: <1479447902-3700-2-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-1-git-send-email-jerin.jacob@caviumnetworks.com> <1480996340-29871-2-git-send-email-jerin.jacob@caviumnetworks.com> <20161208012413.GA22031@svelivela-lt.caveonetworks.com> In-Reply-To: <20161208012413.GA22031@svelivela-lt.caveonetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjJlOGRlMDktN2EzOC00Y2YxLWFlMmUtZjcyNjJhY2Y3NDRhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlnYlFsQzMzdlJzSUVMUVFjZ1RzVDY4VE1melhXY1dmYndoMnNWZTl0ckE9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/6] eventdev: introduce event driven programming model 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: Thu, 08 Dec 2016 11:02:20 -0000 > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Thursday, December 8, 2016 1:24 AM > To: Van Haaren, Harry > > * Operation and sched_type *increased* to 4 bits each (from previous va= lue of 2) to > allow future expansion without ABI changes >=20 > Anyway it will break ABI if we add new operation. I would propose to keep= 4bit > reserved and add it when required. Ok sounds good. I'll suggest to move it to the middle between operation or = sched type, which would allow expanding operation without ABI breaks. On ex= panding the field would remain in the same place with the same bits availab= le in that place (no ABI break), but new bits can be added into the current= ly reserved space. > > * Restore flow_id to 24 bits of a 32 bit int (previous size was 20 bits= ) > > * sub-event-type reduced to 4 bits (previous value was 8 bits). Can we = think of > situations where 16 values for application specified identifiers of each = event-type is > genuinely not enough? > One packet will not go beyond 16 stages but an application may have more = stages and > each packet may go mutually exclusive stages. For example, >=20 > packet 0: stagex_0 ->stagex_1 > packet 1: stagey_0 ->stagey_1 >=20 > In that sense, IMO, more than 16 is required.(AFIAK, VPP has any much lar= ger limit on > number of stages) My understanding was that stages are linked to event queues, so the applica= tion can determine the stage the packet comes from by reading queue_id? I'm not opposed to having an 8 bit sub_event_type, but it seems unnecessari= ly large from my point of view. If you have a use for it, I'm ok with 8 bit= s. > > In my opinion this structure layout is more balanced, and will perform = better due to > less loads that will need masking to access the required value. > OK. Considering more balanced layout and above points. I propose followin= g scheme(based on > your input) >=20 > union { > uint64_t event; > struct { > uint32_t flow_id: 20; > uint32_t sub_event_type : 8; > uint32_t event_type : 4; >=20 > uint8_t rsvd: 4; /* for future additions */ > uint8_t operation : 2; /* new fwd drop */ > uint8_t sched_type : 2; >=20 > uint8_t queue_id; > uint8_t priority; > uint8_t impl_opaque; > }; > }; >=20 > Feedback and improvements welcomed, So incorporating my latest suggestions on moving fields around, excluding s= ub_event_type *size* changes: union { uint64_t event; struct { uint32_t flow_id: 20; uint32_t event_type : 4; uint32_t sub_event_type : 8; /* 8 bits now naturally aligned */ uint8_t operation : 2; /* new fwd drop */ uint8_t rsvd: 4; /* for future additions, can be expanded into without AB= I break */ uint8_t sched_type : 2; uint8_t queue_id; uint8_t priority; uint8_t impl_opaque; }; }; -Harry