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 03C692BD3 for ; Sun, 31 Jul 2016 10:10:28 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id i5so203665639wmg.0 for ; Sun, 31 Jul 2016 01:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudius-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=A9QxTojKIXe7vX8gWMdTm9pb0tVa1BLpgIU65jOC8bU=; b=x451AjsJaXRpwQHe9xIdClpjNNLw3PzSqPFcbXYkly5U2kqffjB4dxM/v/Qs8JTaQf FhhliiAdxVyt2ioVSwWx/G5zHnbU63r6/Fd1J1Q9x28iGBpnIQaV4cBHuRFvcFqbAPDl pwnM7qtofasfAgHDeKyS+C3Yq4QKkHBr0zdjM+xeZd88gRD3Nk0n+HTpFGKG1jFbNLrE SJGQDYfS22r1L0hMPEKXsF1lFWLbCqUS8zXbPVw1X19t3k2RTYoGFgAnMIJxzbn26+cK sBzGJq5+OaePSIlTc/p5yqaYx+hambst4QC8ZQwa7lFnLbVmmPT67OFLOC3bLaY3sQm7 7SQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=A9QxTojKIXe7vX8gWMdTm9pb0tVa1BLpgIU65jOC8bU=; b=d5SjSn8Ig3Vck7+tzG+7fP5VuCIaXbNItPrdQGHloiw+H0jI8veFrcykUX6sPUeYOm 8gCVGLhlmG1EgIM81g1LRYWbecskjo5HqfC+BSUEg/KHhH308ZDgh3zL7OH22mnZnsIf XXewNds3yvkJ8Css8rRf+m53pNgElbhNM6I5AFVMirx/Mor3cdJh9KLPpgyz/ofUBLdq QPhR3XMcCZeAdRZ2/ZA/lB6mnIxEM68097FanhUGPhQSnmt/IDt4QP98OC3fnf1bmvzF yBTnTI/ajIE4gy337/5Ym9b8qYhr9/kJoU9W15LuB/n6myZpVBM2GaOOZMBBzcH4ixLG ihHw== X-Gm-Message-State: AEkoouswr2B3YCWM/JHDHiqJNnjqthdn05DvzL22aQOBA7++oxn3+7mSsyIlqyFqZJ5Hxw== X-Received: by 10.194.175.170 with SMTP id cb10mr15824504wjc.17.1469952627702; Sun, 31 Jul 2016 01:10:27 -0700 (PDT) Received: from [10.0.0.172] ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id c13sm24605118wjx.12.2016.07.31.01.10.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jul 2016 01:10:26 -0700 (PDT) To: Tomasz Kulasek , dev@dpdk.org References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com> From: Vlad Zolotarov Message-ID: Date: Sun, 31 Jul 2016 11:10:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte_eth_dev structure 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: Sun, 31 Jul 2016 08:10:28 -0000 On 07/31/2016 10:46 AM, Vlad Zolotarov wrote: > > > On 07/20/2016 05:24 PM, Tomasz Kulasek wrote: >> This is an ABI deprecation notice for DPDK 16.11 in librte_ether about >> changes in rte_eth_dev and rte_eth_desc_lim structures. >> >> In 16.11, we plan to introduce rte_eth_tx_prep() function to do >> necessary preparations of packet burst to be safely transmitted on >> device for desired HW offloads (set/reset checksum field according to >> the hardware requirements) and check HW constraints (number of segments >> per packet, etc). >> >> While the limitations and requirements may differ for devices, it >> requires to extend rte_eth_dev structure with new function pointer >> "tx_pkt_prep" which can be implemented in the driver to prepare and >> verify packets, in devices specific way, before burst, what should to >> prevent application to send malformed packets. >> >> Also new fields will be introduced in rte_eth_desc_lim: nb_seg_max and >> nb_mtu_seg_max, providing an information about max segments in TSO and >> non TSO packets acceptable by device. >> >> Signed-off-by: Tomasz Kulasek > > Acked-by: Vlad Zolotarov One small comment however. Although this function is a must we need a way to clearly understand which one the clusters are malformed since dropping the whole bulk is usually not an option and sending the malformed packets anyway may cause a HW hang, thus not an option as well. Another thing - I've pulled the current master and I couldn't find the way an application may query the mentioned Tx offload HW limitation, e.g. maximum number of segments. Knowing this limitation would avoid extra liniarization. thanks, vlad > >> --- >> doc/guides/rel_notes/deprecation.rst | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index f502f86..485aacb 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -41,3 +41,10 @@ Deprecation Notices >> * The mempool functions for single/multi producer/consumer are >> deprecated and >> will be removed in 16.11. >> It is replaced by rte_mempool_generic_get/put functions. >> + >> +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure >> will be >> + extended with new function pointer ``tx_pkt_prep`` allowing >> verification >> + and processing of packet burst to meet HW specific requirements >> before >> + transmit. Also new fields will be added to the >> ``rte_eth_desc_lim`` structure: >> + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information about >> number of >> + segments limit to be transmitted by device for TSO/non-TSO packets. >