From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id C660558C8 for ; Thu, 1 Dec 2016 17:28:54 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id f82so253680778wmf.1 for ; Thu, 01 Dec 2016 08:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=4ZGJKjpdTD64zJNCfR7FwCWYdsqTPdkaOmaGxTyTHUA=; b=ILFKACKk8VZyeYmcGHXUzay/2r9eHJkzCNazgkI3lqNi/M8RNA6abfvjkKcJmcqDj1 VNXDidEeGOHM3BlmYxd3YyS2nO5/8Wm9vvBntQ8eQ4/Ob0b4PrBBgGL3oxNdmHoaQjQ8 nwPj7MD4OhvFbny/lygP2UMK71poXXMWcmGiBPHpOSpqdrra/oi39LivVdTIkSTxAsnb WrwiQqwJdsr4rEhUCoHhRcx+d1SsHWTj6WjlAL8mqCWD+8UO/U0hdxYdniK+Qd85Utti eA/RCjn4AVuHTABLiZFxWGVfETQ9cXzWnkapB4B+VXVFM2CsVKk4c3UUlNhfCeZOCawk JEFg== 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:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=4ZGJKjpdTD64zJNCfR7FwCWYdsqTPdkaOmaGxTyTHUA=; b=PYazrHBOs43XQV4I/LIKhaCBLSljdQVe4cGFT9QJJNL6gzCAKxlKWYuV8WOffAMkOw k+TtuDfiPYSo4dOpnvjBtvRCE5MmNSa2Mq2RtHCWakqxA3ZWoFs8lsXL83rMSrRbkRiC ObbnfEooTQ/hjL7SzCEoX0Ihi4UzKnVhuGTtKjYtkhWWrwOcCXCc44ozhzaiPWgVLAXb piywQwmnrSlNtaS+KCBa0UIqAtcOFUYDYGBLKfEFo8qnkmY0ejk0IG3CMRJ9yDRU+VU9 +osoas1cXprkWbec27/jRc9XxIxjy8ODaV3I2mAqVCF/A+qeuQAZHpsJ2O0EVKHa9fYl xm7g== X-Gm-Message-State: AKaTC03VTntYFy1Wx0T+klFWlpR2OrKG1+adr3HSjv5YeUFPohG4ifP4CC40fZPsVlrkCA/T X-Received: by 10.28.132.201 with SMTP id g192mr35211664wmd.134.1480609734397; Thu, 01 Dec 2016 08:28:54 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id p144sm1659357wme.23.2016.12.01.08.28.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 08:28:53 -0800 (PST) From: Thomas Monjalon To: Tomasz Kulasek Cc: dev@dpdk.org, konstantin.ananyev@intel.com, olivier.matz@6wind.com Date: Thu, 01 Dec 2016 17:28:52 +0100 Message-ID: <7834627.cBDVu3uoNi@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1479922585-8640-2-git-send-email-tomaszx.kulasek@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Thu, 01 Dec 2016 16:28:54 -0000 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.