From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Jardin Subject: Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK Date: Wed, 26 Oct 2016 20:37:05 +0200 Message-ID: <15802480868.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> References: <20161005072451.GA2358@localhost.localdomain> <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161025174904.GA18333@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: "Eads, Gage" , "Vangati, Narender" , thomas.monjalon@6wind.com To: "Van Haaren, Harry" , Jerin Jacob , Return-path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id DDA5A133F for ; Wed, 26 Oct 2016 20:37:08 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id b80so240502977wme.1 for ; Wed, 26 Oct 2016 11:37:08 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Le 26 octobre 2016 2:11:26 PM "Van Haaren, Harry" a écrit : >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob >> >> So far, I have received constructive feedback from Intel, NXP and Linaro folks. >> Let me know, if anyone else interested in contributing to the definition of >> eventdev? >> >> If there are no major issues in proposed spec, then Cavium would like work on >> implementing and up-streaming the common code(lib/librte_eventdev/) and >> an associated HW driver.(Requested minor changes of v2 will be addressed >> in next version). > > Hi All, > > I will propose a minor change to the rte_event struct, allowing some bits > to be implementation specific. Currently the rte_event struct has no space > to allow an implementation store any metadata about the event. For software > performance it would be really helpful if there are some bits available for > the implementation to keep some flags about each event. > > I suggest to rework the struct as below which opens 6 bits that were > otherwise wasted, and define them as implementation specific. By > implementation specific it is understood that the implementation can > overwrite any information stored in those bits, and the application must > not expect the data to remain after the event is scheduled. > > OLD: > struct rte_event { > uint32_t flow_id:24; > uint32_t queue_id:8; > uint8_t sched_type; /* Note only 2 bits of 8 are required */ > > NEW: > struct rte_event { > uint32_t flow_id:24; > uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the > enqueue types Ordered,Atomic,Parallel.*/ > uint32_t implementation:6; /* available for implementation specific > metadata */ > uint8_t queue_id; /* still 8 bits as before */ Bitfileds are efficients on Octeon. What's about other CPUs you have in mind? x86 is not as efficient. > > > Thoughts? -Harry