From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgw.gov.kz (mgw.gov.kz [195.12.113.254]) by dpdk.org (Postfix) with ESMTP id 244B45911 for ; Mon, 30 Jan 2017 06:42:57 +0100 (CET) Received: from sts.kz (mail.sts.kz [178.89.4.9]) by mgw.gov.kz with ESMTP id v0U5gutY008464-v0U5guta008464 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 30 Jan 2017 11:42:56 +0600 Received: from [172.20.19.221] (unknown [178.89.4.11]) by sts.kz (Postfix) with ESMTPA id 8E72E1006 for ; Mon, 30 Jan 2017 11:42:56 +0600 (+06) DKIM-Filter: OpenDKIM Filter v2.10.3 sts.kz 8E72E1006 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sts.kz; s=mail; t=1485754976; bh=S8Ix5vzvDtFfGzW+qt1xrY0U1+tk9T4Af7l50VIKgLI=; h=To:From:Subject:Date:From; b=DvO5VzDQBAXMvzWN+FjHSlI+x1+PirjsxWYWf1z69ehAifRngIf5O8y90J3qCW9Ti 0Wj67dOdTznGI3k1aCoQnyuHO7Co+vE0wpyZ4to5K1AF+/Cgrou9Yixt0wJXiqcxye /xDfhYYJ/amB4bnRER2vqW/2ewIl1UdEKPM3NM+4= To: "dev@dpdk.org" From: Yerden Zhumabekov Message-ID: <428d5e1d-8a34-bae1-0a4c-238269435903@sts.kz> Date: Mon, 30 Jan 2017 11:42:56 +0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] rte_port_ring and SP/MP, SC/MC flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 05:42:58 -0000 Hello, I'd like to use rte_port_ring abstract in my application and I'm a little confused about how it treats underlying ring flags. According to DPDK API reference, when creating a ring (via rte_ring_create()/rte_ring_init()), RING_F_SP_ENQ/RING_F_SC_DEQ may be specified. These flags affect the choice of MP/SP, MC/SC operation when using 'default' ring enq/deq API, i.e. rte_ring_enqueue()/rte_ring_dequeue(), rte_ring_enqueue_bulk()/rte_ring_dequeue_bulk(), rte_ring_enqueue_burst()/rte_ring_dequeue_burst(). These API then choose which version of enq/deq to use considering the flags. If you use designated API straightforward, those API (*_mp_*, *_sc_* etc.) don't care about these flags and perform required operations right away. When I use rte_port_ring abstraction, '.f_create()' functions check for flags which were used when creating an underlying ring (see lib/librte_port/rte_port_ring.c:75). But then different call tables use designated ring API which makes checking flags pointless. I find it confusing to be forced to choose between SP/MP, SC/MC twice, when creating ring at first and creating abstraction afterwards. And I see no point in checking for ring flags when creating abstraction because it really does not affect the operation of this abstraction anyway. Is this behaviour anyhow justified? -- Yerden Zhumabekov