From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <vincent.jardin@6wind.com>
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 <dev@dpdk.org>; Wed, 26 Oct 2016 20:37:08 +0200 (CEST)
Received: by mail-wm0-f50.google.com with SMTP id b80so240502977wme.1
for <dev@dpdk.org>; Wed, 26 Oct 2016 11:37:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=6wind-com.20150623.gappssmtp.com; s=20150623;
h=from:to:cc:date:message-id:in-reply-to:references:user-agent
:subject:mime-version:content-transfer-encoding;
bh=1NiH3bY2vQ4/l0uOXfa8fi7CuyFZ2okY5mL0EgQzUiM=;
b=BPelc3FpyOAv51UBa1M+/HK826fETwmRmNO0jI5FsPVaD63PP9BSLWI4mtrEM95DFC
990QL5xN33ttb6urTzZpDPFPjEvaop7MeB7VDb4bE99J/kYctukOryH+nvqBRtpX8m7j
KeKqkIN1S1s1GxZOxoht1oi95dmJIP+JmMW+OGtjSKxP8Ec6pcx2vA8TPHMZIjhpE5Ky
NonHCbeNXsUmRJdEN9pi38XZrO6LZJkzp1M5mc63sArzJYlemhMy4vXT2pMVWiDzYOXn
nO5uvOLX0XUD1VckTp//YYy9akiOZvK/NAyqcVHucNc+vSNNcUCOHSCY5wN4JhqU0deO
0Riw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:to:cc:date:message-id:in-reply-to
:references:user-agent:subject:mime-version
:content-transfer-encoding;
bh=1NiH3bY2vQ4/l0uOXfa8fi7CuyFZ2okY5mL0EgQzUiM=;
b=TxIpg3i3ejtGys/yqhLcRg4jaePCg6Vpq8aGEsp9W1wbC00OqZ25e5nku1hY6juYEm
sGZFQBgpECyNYzP//E5JO7YK8mKqvHT2Ar2RfMTLky/lBHAFuQsA4m3c3v+QzZz3bHKT
W3zLr73qQiUyCkAXinPb5VWrY1qJ47o9uTpgm47h+qhVVl4D8FMbo6A+9wOyeRi6peHH
amEu8+kPTTJC9QOuTy78nSzTG3MM5AcgltlUEktio67s+VQMMJCgqB3imtJqN4x+SeOV
1aaLAgZZuacTSfcn11j7epk+RY/leC5O5WszMfbN0hrdinaDqcsbWWdtxYM1+YygHK7q
+2Fg==
X-Gm-Message-State: ABUngvfNPDT82oE6zwmgb0lVnf1o6dx8LrB3IQCojFrUdDKQkMbk3CrJZKFbdzdBWC3yO7W9
X-Received: by 10.28.217.139 with SMTP id q133mr4185938wmg.17.1477507028604;
Wed, 26 Oct 2016 11:37:08 -0700 (PDT)
Received: from [100.86.167.14] ([80.215.107.103])
by smtp.gmail.com with ESMTPSA id a2sm4060564wjn.10.2016.10.26.11.37.06
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 26 Oct 2016 11:37:07 -0700 (PDT)
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>
Date: Wed, 26 Oct 2016 20:37:05 +0200
Message-ID: <15802480868.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com>
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>
References: <20161005072451.GA2358@localhost.localdomain>
<1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
<20161025174904.GA18333@localhost.localdomain>
<E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>
User-Agent: AquaMail/1.6.2.9 (build: 27000209)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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
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: Wed, 26 Oct 2016 18:37:09 -0000
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