From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Thu, 27 Oct 2016 18:02:02 +0200 (CEST) Received: by mail-wm0-f54.google.com with SMTP id n67so54575559wme.1 for ; 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 To: "Ananyev, Konstantin" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.