From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <arybchenko@solarflare.com> Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 0F4712BA4 for <dev@dpdk.org>; Tue, 12 Sep 2017 12:28:08 +0200 (CEST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id AB1086005C; Tue, 12 Sep 2017 10:28:07 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx2-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id E2AA76004F; Tue, 12 Sep 2017 10:28:06 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BB6D480073; Tue, 12 Sep 2017 10:28:06 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 12 Sep 2017 11:28:00 +0100 To: Shahaf Shuler <shahafs@mellanox.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com> CC: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Stephen Hemminger <stephen@networkplumber.org>, Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>, "Zhang, Helin" <helin.zhang@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com> References: <20170911062119.GA9342@jerin> <VI1PR05MB31494668FAE2606997105A91C3680@VI1PR05MB3149.eurprd05.prod.outlook.com> <20170911080621.GA15867@jerin> <VI1PR05MB31490468C3935396E8DA9A0DC3680@VI1PR05MB3149.eurprd05.prod.outlook.com> <20170911090543.GA9965@jerin> <2601191342CEEE43887BDE71AB9772584F2497DC@irsmsx105.ger.corp.intel.com> <20170912040107.GA8081@jerin> <VI1PR05MB3149DA3533771F6CAC410FB7C3690@VI1PR05MB3149.eurprd05.prod.outlook.com> <20170912055137.GA24921@jerin> <VI1PR05MB3149BFE963A2D760B663F926C3690@VI1PR05MB3149.eurprd05.prod.outlook.com> <20170912071735.GA29366@jerin> <VI1PR05MB31495E6EB625CF83FEA40887C3690@VI1PR05MB3149.eurprd05.prod.outlook.com> From: Andrew Rybchenko <arybchenko@solarflare.com> Message-ID: <66688482-9e4e-81d5-195a-6f1a74caca73@solarflare.com> Date: Tue, 12 Sep 2017 13:27:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <VI1PR05MB31495E6EB625CF83FEA40887C3690@VI1PR05MB3149.eurprd05.prod.outlook.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23324.003 X-TM-AS-Result: No--5.237900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1505212087-2y7hZHMIHhCP Subject: Re: [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx queue offloads API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Tue, 12 Sep 2017 10:28:08 -0000 On 09/12/2017 11:03 AM, Shahaf Shuler wrote: > OK, well understood the requirement for such flags. Thanks for your replies. > > I think that for simplicity I will add two more flags on the Tx offloads capabilities: > > DEV_TX_OFFLOADS _MULTI_MEMPOOL <** Device supports transmission of mbufs from multiple mempools. */ > DEV_TX_OFFLOADS_INDIRECT_MBUFS <** Device support transmission of indirect mbufs. */ Indirect mbufs is just an example when reference counters are required. Direct mbufs may use reference counters as well. > Those caps can be reported by the PMD as per-port/per-queue offloads. Application will choose how to set those. When not set - PMD can assume all mbufs has ref_cnt = 1 and the same mempool. > > Any objection?