From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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 To: "Van Haaren, Harry" , Jerin Jacob , Date: Wed, 26 Oct 2016 20:37:05 +0200 Message-ID: <15802480868.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> In-Reply-To: References: <20161005072451.GA2358@localhost.localdomain> <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161025174904.GA18333@localhost.localdomain> 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" , "Vangati, Narender" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2016 18:37:09 -0000 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