From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 04D2798 for ; Thu, 22 Dec 2016 15:24:41 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id t79so187808807wmt.0 for ; Thu, 22 Dec 2016 06:24:41 -0800 (PST) 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=bxqzwYLH3QIwzMGNxnQs2F3wuwE964IkMViGhZnHWlU=; b=K0GTwkcw2xJxJ+UNqIR0gcLkG9+2x3UHOY2FChFzEr8hkoK3o/h9rP8mgTvxwAQKmz OB+ozA4Dr3Bb7M1yjsQ2c4wtipZZ4ny4C+tk85ht+C2VRU5Ah0goWdj13iD6+N1JffbF VH6BFt0fRXoVLF6AiN3/0brHz45ranu4WGU/7HjYoH1y0J8nNGsVbUbR+dxDpFY809mL 7+JsA+fJWb9ij1jiChFXk03p2lZz9lYIp3lhqWD5JDXThvgXROI2zOizkxK2iOdoSywK dPqMJQFvklo/UsW0Y3fZ2RA1oW1GYhHzQEKD73o9qWkB43Py0bOIHhYRVinpj7iFpgmC WrqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=bxqzwYLH3QIwzMGNxnQs2F3wuwE964IkMViGhZnHWlU=; b=s4OqYxCrlrOcLfB5XX8+y2qMmxi1TE+/hiKpa/4lOWC1uRHvLKMjFQQEl+danZnpXG rGPNaNVTkKDUXIBlD6hJRAtgaKeMi4Ich25jbUvA4tZNhvSGE5EmGN9Kff5gCHpCyoNn kNhRkaq4Y9ndiDfZzVD07wJB9oRWP/F7mnTuLS700E9HV11GnGzT/jyy4viEzw1Wnrvd EO/Ewp/nddLCrGZkjYgZt1JiLggUYy10uXSgEf4IF84y4q2ueZFLyuEhQdne+Ok2+RG/ ZSqt/pqfOgGCUqqPTBCauhTeb9iwTbhujMf0ITxqZmnm0WRvLfEGKjnaM/Qgx4MqwNdR 8pwg== X-Gm-Message-State: AIkVDXLgmA1KOoRDcf5nvdU//42x6/oUVlr8ytN/nCDhi+btyKfdYekeWWQQdxe0nlSjytKe X-Received: by 10.28.135.3 with SMTP id j3mr9390674wmd.96.1482416681719; Thu, 22 Dec 2016 06:24:41 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id w8sm32310967wmw.4.2016.12.22.06.24.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Dec 2016 06:24:41 -0800 (PST) From: Thomas Monjalon To: Tomasz Kulasek Cc: dev@dpdk.org Date: Thu, 22 Dec 2016 15:24:40 +0100 Message-ID: <5890222.TpSixoQlLd@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1482411919-7620-2-git-send-email-tomaszx.kulasek@intel.com> References: <1481650914-40324-1-git-send-email-tomaszx.kulasek@intel.com> <1482411919-7620-1-git-send-email-tomaszx.kulasek@intel.com> <1482411919-7620-2-git-send-email-tomaszx.kulasek@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v14 1/8] ethdev: add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:24:42 -0000 Hi Tomasz, 2016-12-22 14:05, Tomasz Kulasek: > Added API for `rte_eth_tx_prepare` > > uint16_t rte_eth_tx_prepare(uint8_t port_id, uint16_t queue_id, > struct rte_mbuf **tx_pkts, uint16_t nb_pkts) As discussed earlier and agreed by Konstantin, please mark this API as experimental. We could make some changes in 17.05 to improve error description or add some flags to modify the behaviour. > int rte_net_intel_cksum_prepare(struct rte_mbuf *m) > > to prepare pseudo header checksum for TSO and non-TSO tcp/udp packets > before hardware tx checksum offload. > - for non-TSO tcp/udp packets full pseudo-header checksum is > counted and set. > - for TSO the IP payload length is not included. > > > int > rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags) > > this function uses same logic as rte_net_intel_cksum_prepare, but > allows application to choose which offloads should be taken into > account, if full preparation is not required. How the application knows which offload flag should be taken into account? > # > +# Use real NOOP to turn off TX preparation stage > +# > +# While the behaviour of ``rte_ethdev_tx_prepare`` may change after turning on > +# real NOOP, this configuration shouldn't be never enabled globaly, and can be > +# used in appropriate target configuration file with a following restrictions > +# > +CONFIG_RTE_ETHDEV_TX_PREPARE_NOOP=n As discussed earlier, it would be easier to not call tx_prepare at all. However, this option allows an optimization when compiling DPDK for a known environment without modifying the application. So it is worth to keep it. The text explaining the option should be improved. I suggest this text: # Turn off Tx preparation stage # # Warning: rte_ethdev_tx_prepare() can be safely disabled only if using a # driver which do not implement any Tx preparation. > + uint16_t nb_seg_max; /**< Max number of segments per whole packet. */ > + uint16_t nb_mtu_seg_max; /**< Max number of segments per one MTU */ In another mail, you've added this explanation: * For non-TSO packet, a single transmit packet may span up to "nb_mtu_seg_max" buffers. * For TSO packet the total number of data descriptors is "nb_seg_max", and each segment within the TSO may span up to "nb_mtu_seg_max". Maybe you can try to mix these comments to improve the doxygen.