From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
by dpdk.org (Postfix) with ESMTP id BFA4728FD
for <dev@dpdk.org>; Thu, 27 Oct 2016 18:02:02 +0200 (CEST)
Received: by mail-wm0-f54.google.com with SMTP id n67so54575559wme.1
for <dev@dpdk.org>; Thu, 27 Oct 2016 09:02:02 -0700 (PDT)
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=oEh54KQBTx8zzxmjhHU1gB9IeV1XnDBSSHE2Z0dEtzU=;
b=SOegSlVwVL9zd5REqW38zfnpqCjdl7z7fRZCJ5U34vicjY2P9F9mJt4PHeRuKphw7z
xxneEssvbqEkyYv0d4vw/xZXzKKfUzf2Mxxukup4tFCKlG0+93h1tBzBRtgmhvGJA3TJ
PU8RShsZNSHR6awSaAVdqmudIpSaZ4ZJO4nEO3n2dbR2MqAoJqeFsEvRG+pLLqp8CP4B
aIvH9m8cZV3zPPmIOLZGCF8dTw5ICBRGeHK4fN6CVGu7AjiDIhpfocKcH9550gie/Ys1
vvfSbdKWV3hUuoaIleJBSyzIkbztbTyMsc8rS8r9Q91TDH3HRcCb3ywKh6cAfNwoDpH4
sOgQ==
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=oEh54KQBTx8zzxmjhHU1gB9IeV1XnDBSSHE2Z0dEtzU=;
b=EmNDdLW5KD8sOtQ1aSWUa2qg/57hrlVD1HegeAgzhu4oE5gwodmViODC1XbZuIMneq
RZ5QdbWwqpn8yBlDr3MHNf057gQgrCQrRpvadqi6/cvVdfo6RWkEPfXjVu3NI11l9kJI
V9WSGc+zwKJhbnw0P4ElpYEp5nbRp7pXRUEvsaxkRg7nGB7CyT7NU2/y3NpSqpvXP2ns
XzF9NJG+VuKHAFfr4p/j6+veFThDFUFT2/Fkz+G3R0ZbtXc0ykhpfPuyIl7lf1uuKhpe
WIqY3+SrykHc4zF97OvClEEAkEX7rS3zDJ6uStdkFcpimewWbcv9sA8eABvbbWn1L+wZ
X8/A==
X-Gm-Message-State: ABUngvfl6jLdtimYNJ3Dw3XUlMDE1madbrxSaGIE3Ro7OmIfyL80RsExdfdA6ulYFqsJAyCK
X-Received: by 10.28.98.67 with SMTP id w64mr13599211wmb.50.1477584122500;
Thu, 27 Oct 2016 09:02:02 -0700 (PDT)
Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184])
by smtp.gmail.com with ESMTPSA id n6sm9197987wjg.30.2016.10.27.09.02.01
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 27 Oct 2016 09:02:01 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Date: Thu, 27 Oct 2016 18:02:01 +0200
Message-ID: <2078955.d1Aiqtukxu@xps13>
User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; )
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CD83D@irsmsx105.ger.corp.intel.com>
References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com>
<1499338.8Le0ABsxDG@xps13>
<2601191342CEEE43887BDE71AB9772583F0CD83D@irsmsx105.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v11 1/6] ethdev: add Tx preparation
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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: Thu, 27 Oct 2016 16:02:03 -0000
2016-10-27 15:52, Ananyev, Konstantin:
>
> >
> > Hi Tomasz,
> >
> > This is a major new function in the API and I still have some comments.
> >
> > 2016-10-26 14:56, Tomasz Kulasek:
> > > --- a/config/common_base
> > > +++ b/config/common_base
> > > +CONFIG_RTE_ETHDEV_TX_PREP=y
> >
> > We cannot enable it until it is implemented in every drivers.
>
> Not sure why?
> If tx_pkt_prep == NULL, then rte_eth_tx_prep() would just act as noop.
> Right now it is not mandatory for the PMD to implement it.
If it is not implemented, the application must do the preparation by itself.
>>From patch 6:
"
Removed pseudo header calculation for udp/tcp/tso packets from
application and used Tx preparation API for packet preparation and
verification.
"
So how does it behave with other drivers?
> > > struct rte_eth_dev {
> > > eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
> > > eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
> > > + eth_tx_prep_t tx_pkt_prep; /**< Pointer to PMD transmit prepare function. */
> > > struct rte_eth_dev_data *data; /**< Pointer to device data */
> > > const struct eth_driver *driver;/**< Driver for this device */
> > > const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
> >
> > Could you confirm why tx_pkt_prep is not in dev_ops?
> > I guess we want to have several implementations?
>
> Yes, it depends on configuration options, same as tx_pkt_burst.
>
> >
> > Shouldn't we have a const struct control_dev_ops and a struct datapath_dev_ops?
>
> That's probably a good idea, but I suppose it is out of scope for that patch.
No it's not out of scope.
It answers to the question "why is it added in this structure and not dev_ops".
We won't do this change when nothing else is changed in the struct.