DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vincent Jardin <vincent.jardin@6wind.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>, <dev@dpdk.org>
Cc: "Eads, Gage" <gage.eads@intel.com>,
	"Vangati, Narender" <narender.vangati@intel.com>,
	thomas.monjalon@6wind.com
Subject: Re: [dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
Date: Wed, 26 Oct 2016 20:37:05 +0200	[thread overview]
Message-ID: <15802480868.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>



Le 26 octobre 2016 2:11:26 PM "Van Haaren, Harry" 
<harry.van.haaren@intel.com> 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

  parent reply	other threads:[~2016-10-26 18:37 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 21:49 [dpdk-dev] [RFC] " Vangati, Narender
2016-10-05  7:24 ` Jerin Jacob
2016-10-07 10:40   ` Hemant Agrawal
2016-10-09  8:27     ` Jerin Jacob
2016-10-11 19:30   ` [dpdk-dev] [RFC] [PATCH v2] " Jerin Jacob
2016-10-14  4:14     ` Bill Fischofer
2016-10-14  9:26       ` Jerin Jacob
2016-10-14 10:30         ` Hemant Agrawal
2016-10-14 12:52           ` Jerin Jacob
2016-10-14 15:00     ` Eads, Gage
2016-10-17  4:18       ` Jerin Jacob
2016-10-17 20:26         ` Eads, Gage
2016-10-18 11:19           ` Jerin Jacob
2016-10-14 16:02     ` Bruce Richardson
2016-10-17  5:10       ` Jerin Jacob
2016-10-25 17:49     ` Jerin Jacob
2016-10-26 12:11       ` Van Haaren, Harry
2016-10-26 12:24         ` Jerin Jacob
2016-10-26 12:54           ` Bruce Richardson
2016-10-28  3:01             ` Jerin Jacob
2016-10-28  8:36               ` Bruce Richardson
2016-10-28  9:06                 ` Jerin Jacob
2016-11-02 11:25                   ` Jerin Jacob
2016-11-02 11:35                     ` Bruce Richardson
2016-11-02 13:09                       ` Jerin Jacob
2016-11-02 13:56                         ` Bruce Richardson
2016-11-02 14:54                           ` Jerin Jacob
2016-10-26 18:37         ` Vincent Jardin [this message]
2016-10-28 13:10           ` Van Haaren, Harry
2016-11-02 10:47         ` Jerin Jacob
2016-11-02 11:45           ` Bruce Richardson
2016-11-02 12:34             ` Jerin Jacob
2016-10-26 12:43       ` Bruce Richardson
2016-10-26 17:30         ` Jerin Jacob
2016-10-28 13:48       ` Van Haaren, Harry
2016-10-28 14:16         ` Bruce Richardson
2016-11-02  8:59           ` Jerin Jacob
2016-11-02  8:06         ` Jerin Jacob
2016-11-02 11:48           ` Bruce Richardson
2016-11-02 12:57             ` Jerin Jacob
2016-10-14 15:00 Francois Ozog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15802480868.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com \
    --to=vincent.jardin@6wind.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=narender.vangati@intel.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).