From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 75FB1378B for ; Thu, 28 Jul 2016 14:07:30 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id q128so249094526wma.1 for ; Thu, 28 Jul 2016 05:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=e3drJ3gPgN8l0EDhmav+8B266DZnFLAo8RmZbZtIWCg=; b=T4mOmBa/AMtC7Oe5tEkkimcIuNZeP2ELC4o80AojgWGxUr8IGyzfzJ5FMU+REza+O1 CHzbYDa81F7cYPia1luZ4aXI6pi0NCToUoi15C0w0hXe+Lh5iNJgx8uZr+dbC9+iULG9 bANQgxYnRrF3q1wVZcqjM91tYPDMa8cZjKkptDyYB1J+mMDZFs37yfNfTs4zZMOw4yBZ Ln/0uYoaF1mIiLhUs90l0J0jAaxPWtdx6z+/8WZukPyq5GFRHg9ZsK0X0Gih4FZYN5L3 D/RShrBUf0JxY2DUNwr+n6FlhnEvez+F39s6QRbuWGwBpZT0lxmx2ZKEWQMp7y3/29Tp cN6Q== 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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=e3drJ3gPgN8l0EDhmav+8B266DZnFLAo8RmZbZtIWCg=; b=cYyvGDW8bShindD1ilSE/daJKw1hpfRYJKx7iS0idw8LNL/zoXtnpOEdF2vFP9Yksv rYOWL6bSt9atJrJVsUF720ecWIyayHvpWc1lDJzZhLDUtZhyFKrw7DVC02MFhgiAR7hH W+/FS0KCt6gEE13RYN1lEjbbo9KWjgN17UW+iJL3TyOCkE7bEtSArsMUn8sO67eTxm5T cxPWnIHMFwIcI4W2cA50G7via1krp8R/ZcMwqDBubgip2IVRzqH3MJXeaeW1eo00u5zP +owtBRDjy5sTqE870raODOk6w63zYSRRtUqFe+DUpL/1+Ql4zwC14qgRLfRVJNbDBwGh 7jVw== X-Gm-Message-State: AEkoouu+Ku0kC2R+PsnUQaJ3tgLUwbyP3wUnxFmxBBwzk/ZvjbOpb44MmkZj0LxJ5ZwCMA== X-Received: by 10.194.78.74 with SMTP id z10mr36327389wjw.68.1469707650102; Thu, 28 Jul 2016 05:07:30 -0700 (PDT) Received: from avi.cloudius-systems.com ([37.142.229.250]) by smtp.gmail.com with ESMTPSA id e10sm11239649wjc.21.2016.07.28.05.07.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jul 2016 05:07:28 -0700 (PDT) To: Jerin Jacob , "Ananyev, Konstantin" References: <1469024691-58750-1-git-send-email-tomaszx.kulasek@intel.com> <1469114659-66063-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB97725836B80AD8@irsmsx105.ger.corp.intel.com> <2146153.nVzdynOqdk@xps13> <20160727171043.GA22116@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B8884E@irsmsx105.ger.corp.intel.com> <20160727174133.GA22895@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B88894@irsmsx105.ger.corp.intel.com> <20160728021345.GA3617@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B8AA48@irsmsx105.ger.corp.intel.com> <20160728113853.GA14755@localhost.localdomain> Cc: Thomas Monjalon , "dev@dpdk.org" From: Avi Kivity Organization: ScyllaDB Message-ID: Date: Thu, 28 Jul 2016 15:07:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160728113853.GA14755@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] 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: Thu, 28 Jul 2016 12:07:30 -0000 On 07/28/2016 02:38 PM, Jerin Jacob wrote: > On Thu, Jul 28, 2016 at 10:36:07AM +0000, Ananyev, Konstantin wrote: >>> If it does not cope up then it can skip tx'ing in the actual tx burst >>> itself and move the "skipped" tx packets to end of the list in the tx >>> burst so that application can take the action on "skipped" packet after >>> the tx burst >> Sorry, that's too cryptic for me. >> Can you reword it somehow? > OK. > 1) lets say application requests 32 packets to send it using tx_burst. > 2) packets are from p0 to p31 > 3) in driver due to some reason, it is not able to send the packets due to some > constraints in the driver(say expect p2 and p16 everything else sent > successfully by the driver) > 4) driver can move p2 and p16 at pkt[0] and pkt[1] on tx_burst and > return 30 > 5) application can take action on p2 and p16 based the return value of > 30(ie 32-30 = 2 packets needs to handle at pkt[0] and pkt[1] That can cause reordering; while it is legal, it reduces tcp performance. Better to preserve the application-provided order. > >>> >>>> Instead it just setups the ol_flags, fills tx_offload fields and calls tx_prep(). >>>> Please read the original Tomasz's patch, I think he explained possible use-cases >>>> with lot of details. >>> Sorry, it is not very clear in terms of use cases. >> Ok, what I meant to say: >> Right now, if user wants to use HW TX cksum/TSO offloads he might have to: >> - setup ipv4 header cksum field. >> - calculate the pseudo header checksum >> - setup tcp/udp cksum field. >> >> Rules how these calculations need to be done and which fields need to be updated, >> may vary depending on HW underneath and requested offloads. >> tx_prep() - supposed to hide all these nuances from user and allow him to use TX HW offloads >> in a transparent way. > Not sure I understand it completely. Bit contradicting with below > statement > |We would document what tx_prep() supposed to do, and in what cases user > |don't need it. > > How about introducing a new ethdev generic eal command-line mode OR > new ethdev_configure hint that PMD driver is in "tx_prep->tx_burst" mode > instead of just tx_burst? That way no fast-path performance degradation > for the PMD that does not need it > > >> Another main purpose of tx_prep(): for multi-segment packets is to check >> that number of segments doesn't exceed HW limit. >> Again right now users have to do that on their own. >> >>> In HW perspective, It it tries to avoid the illegal state. But not sure >>> calling "back to back" tx prepare and then tx burst how does it improve the >>> situation as the check illegal state check introduce in actual tx burst >>> it self. >>> >>> In SW perspective, its try to avoid sending malformed packets. In my >>> view the same can achieved with existing tx burst it self as PMD is the >>> one finally send the packets on the wire. >> Ok, so your question is: why not to put that functionality into >> tx_burst() itself, right? >> For few reasons: >> 1. putting that functionality into tx_burst() would introduce unnecessary >> slowdown for cases when that functionality is not needed >> (one segment per packet, no HW offloads). > These parameters can be configured on init time > >> 2. User might don't want to use tx_prep() - he/she might have its >> own analog, which he/she belives is faster/smarter,etc. > That's the current mode. Right? >> 3. Having it a s separate function would allow user control when/where >> to call it, let say only for some packets, or probably call tx_prep() >> on one core, and do actual tx_burst() for these packets on the other. > Why to process it under tx_prep() as application can always process the > packet in one core > >>> proposal quote: >>> >>> 1. 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. >>> >>> >>>>> and what if the PMD does not implement that callback then it is of waste cycles. Right? >>>> If you refer as lost cycles here something like: >>>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_prep, -ENOTSUP); >>>> then yes. >>>> Though comparing to actual work need to be done for most HW TX offloads, >>>> I think it is neglectable. >>> Not sure. >>> >>>> Again, as I said before, it is totally voluntary for the application. >>> Not according to proposal. It can't be too as application has no idea >>> what PMD driver does with "prep" what is the implication on a HW if >>> application does not >> Why application writer wouldn't have an idea? >> We would document what tx_prep() supposed to do, and in what cases user don't need it. > But how he/she detect that on that run-time ? > >> Then it would be up to the user: >> - not to use it at all (one segment per packet, no HW TX offloads) > We already have TX flags for that > >> - not to use tx_prep(), and make necessary preparations himself, >> that what people have to do now. >> - use tx_prep() >> >> Konstantin >>