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