From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 0F69E2B9D for ; Wed, 20 Jul 2016 17:22:09 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id q128so60754111wma.1 for ; Wed, 20 Jul 2016 08:22:09 -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=tra8i/4QzppcfzEK6uph3NZKnbog9gPHkJyDuwcaZp8=; b=bEhlNYK4FQ2Clj8ZDhWviPIHCJEGnACGpZVd5HCF1Y1Wg4XdUglQQm1so37DFpCB0T FCf+mkGTP8SqvfyuPPQS9URLq3HhzLxrzvKtEWgIFPMBABXtgxkGV2E4KV7FcLVDavkf gK+iGf5+rPs4uwqkx0TaRd3fRDrZT/BhbPw8/gCyHbtCN7kEsVQLxIG9tFcl0cSq4/ZU 79iZTPsuUQOSZuCd4truQ4/vQyi5qHRvT0JNRGdIDXcRSV1E6K/TJarRez5Jkbg3QRVT Zw4dLmTsOiAHFWofPEX2pgKvsYAujRqJ1RuEEJXzNX16hzpVkZiF9DjfPv/As87fFDaq qqIQ== 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=tra8i/4QzppcfzEK6uph3NZKnbog9gPHkJyDuwcaZp8=; b=Ke9QMjVK0/6J/ISEIv/8NmwyR9N+a9iSW8qsN0xmreDCo3E4H/zsFcM4diczX5iGnN z5xJ5m/wglXy/1xpttX1w/+VDoWqyPn9AKvwnNN1/QxYLcbFnt01pNRgYKpeMo3gx7Qi AYBlL1+PHvkMtTg0WP+T9H6euwf9kIiMwLiyj6kVCOjU1s/CUT1ZeJQFaHo7ZESlhU+o wN0fZssh6WCwSRdcFWpNiXkRHPBV/lgdfd5B34xnXW0Ym75Yzz+4WTA9bh8n6v8Dw3bg AYGBVa4hAZ+5+2DkaN0lRjApRfqxuOYVEGz4PxhOPOdrzDRfb5oAa2Zzyb9RuYh/kwLF kJjg== X-Gm-Message-State: ALyK8tKTwU58AE5xL6RxuGTa3pVpGZmzEGOMagdTiCHlc1r4F7qgArORCWBgzerE6RRbp+RB X-Received: by 10.28.156.213 with SMTP id f204mr11488140wme.86.1469028128804; Wed, 20 Jul 2016 08:22:08 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id g2sm1774000wjd.38.2016.07.20.08.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 08:22:08 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: "Kulasek, TomaszX" , dev@dpdk.org Date: Wed, 20 Jul 2016 17:22:07 +0200 Message-ID: <2792307.Hs7AniM9ZW@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB97725836B7FFB6@irsmsx105.ger.corp.intel.com> References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com> <2192482.DY91PqGyRQ@xps13> <2601191342CEEE43887BDE71AB97725836B7FFB6@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Wed, 20 Jul 2016 15:22:09 -0000 2016-07-20 15:13, Ananyev, Konstantin: > Hi Thomas, > > > Hi, > > > > This patch announces an interesting change in the DPDK design. > > > > 2016-07-20 16:24, Tomasz Kulasek: > > > 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. > > > > We cannot acknowledge such notice without a prior design discussion. > > Please explain why you plan to work on this change and give a draft of the new structures (a RFC patch would be ideal). > > I think it is not really a deprecation note, but announce ABI change for rte_ethdev.h structures. An ABI break requires a deprecation notice. So it is :) > The plan is to implement what was proposed & discussed the following thread: > http://dpdk.org/ml/archives/dev/2015-September/023603.html Please could you summarize it here?