From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id D02FA2E41 for ; Thu, 27 Oct 2016 18:39:12 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id n67so57595342wme.1 for ; Thu, 27 Oct 2016 09:39:12 -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=7+cojCYyl926s2uL/GimZMvHS1tkZMQZxKN8Qea5FjA=; b=HFaunYGr4uHr+Plks/GZVwW9baPGFsUjFadOTtdtyLtLr/tjhbkl+b8z9RbsmA5VLT uUbd9Vrw2e2ppQCHn+2LW3v0yr4otZCJi+DBvofoh/8QYhyddQjESxWoq+WAd9egdCpq w94ntaWbKE6J+OuC+AjZ7hvMXjk0mYjG7FhjkIUwyQRDIbX3LlNRkIrVtvn9BuYxN6fT q1eHOgSi5CMLRiNn/u+FVerjpLi2RpcLcdqiGNU8B4nAdSMexj+mbR86HuyqZ8nNINUc /o00RsrR6EXcc7eCTtbH2yvY7UUzhLZ0/71+OQ6vAHkyP8psj+lt7rX1QQJuXB1+r4Qx kN3A== 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=7+cojCYyl926s2uL/GimZMvHS1tkZMQZxKN8Qea5FjA=; b=iCdqkE2bSbfnlX8jadpJM9oXseDbX6reBx+hT87O+cEw5mWyOvrRZ0RbNkgk23LuIo GXQtzEBClnPG8zzbGU78iH2sN8blK+GKP1+QHOc1CBcK3uWx5RiOQpL1chmNHVY2se4O sFTTZmVUbL2ZZ2lw7+VTxPPLOdzO2u5GbvIDYw2CVcUTeX0oN3kPrOJs0NFrwzgd7nOD BA7WOyHXl7aSnapRLNaqPry631B1Zz8F0n0wwLMfDwP99mGgjzviNft9qSFLSpZab/QP X2KqQgbalDRj/jvS1CiekwfCVCvLtWQqaPk/vu+sMRUs1oAhc5RYC0miNq4hTQvPChzv Y+uA== X-Gm-Message-State: ABUngvcoKP8N0xKJ7YE8dD4wHW1XykvBbeWYXq6oxejzxmgIODx5JaXSk9h/s18hJy85ZMHh X-Received: by 10.28.23.199 with SMTP id 190mr8349553wmx.107.1477586352500; Thu, 27 Oct 2016 09:39:12 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id v3sm9428624wjm.4.2016.10.27.09.39.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2016 09:39:11 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Date: Thu, 27 Oct 2016 18:39:11 +0200 Message-ID: <2500924.jYNDaNt7Th@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CE8E3@irsmsx105.ger.corp.intel.com> References: <1477327917-18564-1-git-send-email-tomaszx.kulasek@intel.com> <2078955.d1Aiqtukxu@xps13> <2601191342CEEE43887BDE71AB9772583F0CE8E3@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:39:13 -0000 2016-10-27 16:24, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 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? > > Hmm so it seems that we broke testpmd csumonly mode for non-intel drivers.. > My bad, missed that part completely. > Yes, then I suppose for now we'll need to support both (with and without) code paths for testpmd. > Probably a new fwd mode or just extra parameter for the existing one? > Any other suggestions? Please think how we can use it in every applications. It is not ready. Either we introduce the API without enabling it, or we implement it in every 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. > > Not sure I understood you here: > Are you saying datapath_dev_ops/controlpath_dev_ops have to be introduced as part of that patch? > But that's a lot of changes all over rte_ethdev.[h,c]. > It definitely worse a separate patch (might be some discussion) for me. Yes it could be a separate patch in the same patchset.