From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 13E4768AB for ; Fri, 2 Dec 2016 17:17:54 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 02 Dec 2016 08:17:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,287,1477983600"; d="scan'208";a="12718982" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga002.jf.intel.com with ESMTP; 02 Dec 2016 08:17:52 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX151.ger.corp.intel.com ([169.254.4.16]) with mapi id 14.03.0248.002; Fri, 2 Dec 2016 16:17:52 +0000 From: "Ananyev, Konstantin" To: Olivier Matz CC: Thomas Monjalon , "Kulasek, TomaszX" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation Thread-Index: AQHSRbBXtZ+k3KL6/UOfLLeqKZ5NC6DzVKAAgACPLdCAAHvNgIAAf21A Date: Fri, 2 Dec 2016 16:17:51 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0E3405@irsmsx105.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <1479922585-8640-1-git-send-email-tomaszx.kulasek@intel.com> <1479922585-8640-2-git-send-email-tomaszx.kulasek@intel.com> <7834627.cBDVu3uoNi@xps13> <2601191342CEEE43887BDE71AB9772583F0E2AB0@irsmsx105.ger.corp.intel.com> <20161202092425.13752e2f@platinum> In-Reply-To: <20161202092425.13752e2f@platinum> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation 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: Fri, 02 Dec 2016 16:17:55 -0000 Hi Olivier, > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Friday, December 2, 2016 8:24 AM > To: Ananyev, Konstantin > Cc: Thomas Monjalon ; Kulasek, TomaszX ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation >=20 > Hi Konstantin, >=20 > On Fri, 2 Dec 2016 01:06:30 +0000, "Ananyev, Konstantin" > wrote: > > > > > > 2016-11-23 18:36, Tomasz Kulasek: > > > > +/** > > > > + * Process a burst of output packets on a transmit queue of an > > > > Ethernet device. > > > > + * > > > > + * The rte_eth_tx_prepare() function is invoked to prepare > > > > output packets to be > > > > + * transmitted on the output queue *queue_id* of the Ethernet > > > > device designated > > > > + * by its *port_id*. > > > > + * The *nb_pkts* parameter is the number of packets to be > > > > prepared which are > > > > + * supplied in the *tx_pkts* array of *rte_mbuf* structures, > > > > each of them > > > > + * allocated from a pool created with rte_pktmbuf_pool_create(). > > > > + * For each packet to send, the rte_eth_tx_prepare() function > > > > performs > > > > + * the following operations: > > > > + * > > > > + * - Check if packet meets devices requirements for tx offloads. > > > > + * > > > > + * - Check limitations about number of segments. > > > > + * > > > > + * - Check additional requirements when debug is enabled. > > > > + * > > > > + * - Update and/or reset required checksums when tx offload is > > > > set for packet. > > > > + * > > > > + * Since this function can modify packet data, provided mbufs > > > > must be safely > > > > + * writable (e.g. modified data cannot be in shared segment). > > > > > > I think we will have to remove this limitation in next releases. > > > As we don't know how it could affect the API, I suggest to declare > > > this API EXPERIMENTAL. > > > > While I don't really mind to mart it as experimental, I don't really > > understand the reasoning: Why " this function can modify packet data, > > provided mbufs must be safely writable" suddenly becomes a problem? > > That seems like and obvious limitation to me and let say tx_burst() > > has the same one. Second, I don't see how you are going to remove it > > without introducing a heavy performance impact. Konstantin > > >=20 > About tx_burst(), I don't think we should force the user to provide a > writable mbuf. There are many use cases where passing a clone > already works as of today and it avoids duplicating the mbuf data. For > instance: traffic generator, multicast, bridging/tap, etc... >=20 > Moreover, this requirement would be inconsistent with the model you are > proposing in case of pipeline: > - tx_prepare() on core X, may update the data > - tx_burst() on core Y, should not touch the data to avoid cache misses >=20 Probably I wasn't very clear in my previous mail. I am not saying that we should force the user to pass a writable mbuf. What I am saying that for tx_burst() current expectation is that after mbuf is handled to tx_burst() user shouldn't try to modify its buffer= contents till TX engine is done with the buffer (mbuf_free() is called by TX func fo= r it). For tx_prep(), I think, it is the same though restrictions are a bit more s= trict: user should not try to read/write to the mbuf while tx_prep() is not finish= ed with it. What puzzles me is that why that should be the reason to mark tx_prep() as = experimental.=20 Konstantin