From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 1CEA558C5 for ; Fri, 2 Dec 2016 02:06:32 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP; 01 Dec 2016 17:06:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,284,1477983600"; d="scan'208";a="793271141" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by FMSMGA003.fm.intel.com with ESMTP; 01 Dec 2016 17:06:30 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.43]) by IRSMSX103.ger.corp.intel.com ([169.254.3.91]) with mapi id 14.03.0248.002; Fri, 2 Dec 2016 01:06:30 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , "Kulasek, TomaszX" CC: "dev@dpdk.org" , "olivier.matz@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v12 1/6] ethdev: add Tx preparation Thread-Index: AQHSRbBXtZ+k3KL6/UOfLLeqKZ5NC6DzVKAAgACPLdA= Date: Fri, 2 Dec 2016 01:06:30 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F0E2AB0@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> In-Reply-To: <7834627.cBDVu3uoNi@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] 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 01:06:33 -0000 >=20 > 2016-11-23 18:36, Tomasz Kulasek: > > +/** > > + * Process a burst of output packets on a transmit queue of an Etherne= t device. > > + * > > + * The rte_eth_tx_prepare() function is invoked to prepare output pack= ets to be > > + * transmitted on the output queue *queue_id* of the Ethernet device d= esignated > > + * by its *port_id*. > > + * The *nb_pkts* parameter is the number of packets to be prepared whi= ch are > > + * supplied in the *tx_pkts* array of *rte_mbuf* structures, each of t= hem > > + * 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). >=20 > 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 unders= tand the reasoning: Why " this function can modify packet data, provided mbufs must be safely w= ritable" 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 he= avy performance impact. Konstantin =20