From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <olivier.matz@6wind.com> Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 788013DC for <dev@dpdk.org>; Fri, 2 Dec 2016 09:24:28 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id f82so8752852wmf.1 for <dev@dpdk.org>; Fri, 02 Dec 2016 00:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oekcxE9efhmRPXFho3vMkvYqrc2UO2tj44kLGLLCVHg=; b=UGEOFB+x7yiq8YIBAmn6+HZP8VIrdxQU5tWzVqHViAD2yNVR1DebEFijaKNc7rciKG cI8Fo+W4UGWmL6oPuQjuUJKGzhHIabZ8tHL6OfTVAD3dfCuDKGLTA+8dzwpAD22uZrMQ oRZAUsbCMO4KhZ0aiCP9MBvihSQGJujm9UI7spPHSO/eeHunl4qvpRzh8MVulSTzuxbP QLW1YiQ9Skiq1uduhbkK43NJ9UYJqMRRyKkzRFfOO/YwyN61AHTSxkhXZ8J0zjoIinQ+ svrFAwY1TAlRTbavGFag5GZPqxmHzTVp/9jSawWl4TDrppZGHK1Xcm41le59fT+quC72 gkag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oekcxE9efhmRPXFho3vMkvYqrc2UO2tj44kLGLLCVHg=; b=exQwHuK41woInkOTx+WSnDxIYtPv7C1xQ9GvEl6oSFZCy8sHfEz2MindBHfbNQylpN 96fYDFszbbG14IAQc4LhKO3CKpA8yQwsUHYOu5RuJCfdf/qhe0BQsRVEmr+k5U1+5kWL wLKXvFGrJHSvvPZEJeF905inoivjaTjyMH1sqvxdNTIjhhQ5ra+kmYZb6WORd7MgZbSL RI09kOkHY8nGH08lSLLZHOMIJT6v5voBJ4JWQn/x2zJp+Xgr8UndGWFQ9OBuJKNjNIjo FpE6kfkbwlc+3pUUepEUyzvkfeeZgVt56qcyOCXEse5qXQHO/fZvd2Ts+PPuJECdPzKc d/0Q== X-Gm-Message-State: AKaTC02W7j8WWriePsWCE80YLA5bva7xqr4MrOcUXz6FsHQ1tIpX3Ci24PrtwZ9IaS5Yicz3 X-Received: by 10.28.134.204 with SMTP id i195mr1607544wmd.77.1480667068437; Fri, 02 Dec 2016 00:24:28 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id f10sm4278889wjl.28.2016.12.02.00.24.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Dec 2016 00:24:28 -0800 (PST) Date: Fri, 2 Dec 2016 09:24:25 +0100 From: Olivier Matz <olivier.matz@6wind.com> To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <20161202092425.13752e2f@platinum> In-Reply-To: <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> <2601191342CEEE43887BDE71AB9772583F0E2AB0@irsmsx105.ger.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 <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: Fri, 02 Dec 2016 08:24:29 -0000 Hi Konstantin, On Fri, 2 Dec 2016 01:06:30 +0000, "Ananyev, Konstantin" <konstantin.ananyev@intel.com> 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 > 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... 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 Regards, Olivier