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

> From: Vincent Jardin [mailto:vincent.jardin@6wind.com]
> Sent: Wednesday, October 26, 2016 7:37 PM
> 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.

Given the rte_event struct is 16 bytes and there's no free space to use, I see no alternative than using bitfields in this case. Wecloming suggestions of a better way to layout the structure to avoid the bitfield.

Regards, -Harry

  reply	other threads:[~2016-10-28 13:10 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
2016-10-28 13:10           ` Van Haaren, Harry [this message]
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=E923DB57A917B54B9182A2E928D00FA6129ADFC9@IRSMSX102.ger.corp.intel.com \
    --to=harry.van.haaren@intel.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=narender.vangati@intel.com \
    --cc=thomas.monjalon@6wind.com \
    --cc=vincent.jardin@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).