From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0087.outbound.protection.outlook.com [104.47.41.87]) by dpdk.org (Postfix) with ESMTP id C554F378B for ; Thu, 28 Jul 2016 04:13:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wohSovlovyMrU2GERbTSIKB5pTeJGfpyaw5xditWVyo=; b=M8HtDDntAnxKTw9vUp5JonWKQDhEmUdO3nyLTr29Eh7vhN0uWFl/xjq8n/KVDfTNH0y+V8Zn8Houn4kkkBwD50g/3odz8CPuI6lbNm/mf5Um/2gJwKqRL7asT5CpqDSbU306XGkK6WaPiCIFUTTQFuTh00FCegNMgBeMbokZyIE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (12.108.191.226) by BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 28 Jul 2016 02:13:53 +0000 Date: Thu, 28 Jul 2016 07:43:46 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" CC: Thomas Monjalon , "dev@dpdk.org" Message-ID: <20160728021345.GA3617@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725836B88894@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [12.108.191.226] X-ClientProxiedBy: BN1PR08CA0045.namprd08.prod.outlook.com (10.242.217.173) To BN3PR0701MB1720.namprd07.prod.outlook.com (10.163.39.19) X-MS-Office365-Filtering-Correlation-Id: c777ccc6-532d-414c-a75c-08d3b68cd3b3 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 2:0Rz9qSj2QhAkCPeOGKDW/ZcQwoQ8LICdCm5ko0TeAypk3aAWzYhwBc/NFFj95iO1sqFZ4+m1VjQdWjAC548aiKt4EZ7+b7vQmRScn8xpCGFB+o4zaPaGspH9L+eym73L9mmp0HXweufCH8K0XTleGlETh7mxQE2xpBsf64gYwMcFTDlQSxPs6DzLeDFZ0Rod; 3:RTMuTUfS2skKaaaWtJsTfEbBsRpRt7HWEJntZzN3Zls2od2Ew8hHNTSOZucCmjvpnVl9MxpuqFE3+oG8nLR1jKIizq7OHW3et4V0BLgVMD0b7DFHI55uv7ku6W5VkgdL; 25:M5lKwXqNDAWU0onKicdh/olI/RbHroH7csZ+EZmq/hTWCFj1svCzmf0qtQFz/VLPSf63Vm1X+Aee02fVoHRYGONUNADXGL3QRnRsy59mzCgarj9pp6pkSeu7X0wvKbI0qMWzC7BQvpETn9YoWgj4ScVxeQ4s296MGcjosBERV9erpmhIyirgogGgKAns9t1BFunNt0edMpZ8SAjtA8cDLnbJd2UquPbptDu57mgoLUeOZRSu1HbTXJg9Ajd5RBmTAdESWHyCKjPCdbkR0+mguikdgvWpK/0BSguy+5WiZzsc2mJ2dssdeAIamKgExSYwE/17NJHBasJYVx8RV/8FtN612tZADiJ9ZDyfdZxwfoCSFAyHodX+MF14g2vFrxet5s4w3CdCFdmWZw+iiCfyW1m6H7xMTma+KKrcaKhiN2c= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 31:okDtv6f6pGLJQeBEg00LI+8b0vTX/IWPKvudVheWtNT4zru+wOt1IH3VXBgvuocgP9xvWcammEl4pf/injA46WUxdFZzAL5/3klXQ13zpi0WAMDTPPtnq8pqiWI6TMbbUTrqL8PTCEBoLajdA9v0EQN7QXzx5hcZ9Mq9FO3LF/hmP5hm4CJHxrnEa8fSqDgFkCaQg9mDvvfm7tvy8A5BmA==; 20:XOkVcfD8hpqv3BpDpxnuXtGJyFZL6qfTuvp5cQ1debT6Vau7QlOv3H0Yf6Wi8nxQSaCLTNmye3ao4NJCZnbPRIv3UpImLlhy0nvHFEK4JK/YfMCl3tqWfdBRemsR8nKGXa4+jhYApBBLTDU/BnXF2FskNJbcfOjBJ/viBVRB428j1TEHtmypKIkUIc+7gUFqFp4iGd6DD+DfqIJVFNn2Nenv7FR9sWOKMtqH6xC0xbkv/VAvIqLOEAtn0NX/q597CRrKEHOnGMhaQyNFA/qp5bI0Nx0/c4zqp2iJtXO6tPyzm9JxD9GGfhsNuwrbHjWhy+4uBi2GkH2Db+omRI/pavXEyqrFJcYQbFwS7JDaDzFXqX1gaz+MuGgPKjoP+bd50sLd/ZXNh4+oUjMt+PjjUmcmGYTbzl1ERyRNVmu9BlK2tifEccETMNLhrFatlp02N/uado8GXQii9flXzUxA8YecaPP34zYWwWBylA0qN3U6eaVnOm4XUEI3ZNU9D9QDixlBl8yEPjjbM/38HDTKaFiJ86uxESyrIviwv1IIg+azA8omHNeoggF641UpjAykzxSXXOpRFeqBTV8V/otGunVooYBWmrcaGo5+Fv8MIho= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0701MB1720; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1720; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 4:oCusCli05841Jz4lla6DCaPEP7mSdn/Hh6DVxnaJkVrv2ivd1NC8Y/uLmnrb2JtnlgA/v2wZwAQrH6lKnArvYolA3djStSyvjpaw9Tpplb13dVceoj9HPHVwWrLpr/XhocnGPvCK6YF/7RHuZPjqfF04UVKqB+lpvOcaL+2BNQcIIWttULv6bxCElIsukaaJKkG/1jyDq2JsbgsI/3fppdAGCedP2eodq2NQZEjWrDgbfpU1SlO7lf/Rjq4emTjWjfMWOr1JED1R4OLuFOhLkfVWpcwQbQ7RQ5EQcKT48hH7hfzGrC7iEBz7KAvCHESg/GQY2mSDU6xjtCFloVPmddjmK3j2Gb1Dq+P055eHnQqhM44KN6s+qGVrvn/oOEhnU+YX4JVAu5cW2PdXMhrbYiQZlalpK2jVnpnCHphTKxDyrc6mbs0wbebFIG1J1PCcgqzkLJ0wPPJWIWDvdf5lig== X-Forefront-PRVS: 00179089FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(13464003)(189002)(377454003)(199003)(24454002)(81166006)(110136002)(42186005)(8676002)(61506002)(9686002)(81156014)(68736007)(106356001)(7846002)(66066001)(561944003)(97736004)(97756001)(92566002)(47776003)(105586002)(4001350100001)(101416001)(54356999)(93886004)(50466002)(2906002)(19580395003)(83506001)(19580405001)(77096005)(189998001)(50986999)(3846002)(586003)(305945005)(2950100001)(4326007)(7736002)(76176999)(6116002)(23726003)(33656002)(46406003)(1076002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1720; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0701MB1720; 23:Uqh/PEAgQxetsFS8zb9nXrsDQCJIfVrQwqKeZO5?= =?us-ascii?Q?4CuQPpq0uL7z8ckMwMhkK2Ss237u1BVvCQD5MWk/7934n4uMG/ZaCE8soB53?= =?us-ascii?Q?6wXpI4NZ7t6oemYw8NU2W74Wp9L6IpRm7ENk699ACT1vdB3o20B4vCkaaby1?= =?us-ascii?Q?XrczbFN5V7TPG0eSEzmWfAXQDLMQxD+8vEf4pbZKrCM15SeaFCSFGmKGa+Rh?= =?us-ascii?Q?nUYIUfcD1VoQxPSw40jYh2gB5NBIJyk6mRDnWgirW0ARGo76i8wE8Vn2+EeS?= =?us-ascii?Q?XHrVq4zGvaPNlBOkxsP7kMW3TamnLGi3OcaxU7YB8O/w0jplxKv1RzxJL/Vt?= =?us-ascii?Q?0chVBGgM5QKUEKAq65l+PB/6/JN39N+7nl+JvHDfzNiXEKUYReo8laggjc0H?= =?us-ascii?Q?lQ7YgVX9Xo0tsDhy1vLw/0+YfPJhdas4NjaJYbHymon3/v5Q5ydxr/SaH9mh?= =?us-ascii?Q?ciDHrkjAawgxM3kBMpAOGYDU/s68jtCC4XmbIZTMrfZ3LOPDN1o3JJxyxjOI?= =?us-ascii?Q?U7JsLhv1NnmW+dS+sAYxzIp46OlGRSSP2S5GBw5FgV/OGk88YdJvXK0h8euf?= =?us-ascii?Q?8H4e4Zrufoj23LOYYIG52HZNeKf0x3bNDwa2n9PH0yYebl8kuzH4GxLAtofV?= =?us-ascii?Q?t5P7r+CKrQMEe3YFtH7KVmZkrvM7fQIwbWvkcnpZMnIVhJzvxBYHvZ811oEB?= =?us-ascii?Q?pKBaJn7h7bbm3k1QAshlJl3CtRnVwcR1bHGKpMEEWU1zEa76zG1p5JnyZ8Ba?= =?us-ascii?Q?8yGelGQMJMqUqZvJu9jn+tjILlZTckpphsn9GDjndIxUJx6M5zSBIxS255CN?= =?us-ascii?Q?B234xvcAhlIXC4AXdTEsK48pJNd1DzNcaiaI0jQN1BWWrr38rq72O/4+dTUZ?= =?us-ascii?Q?Ip12BPkQo2eCCj3yE44MnoN4sayKUfxm7lCYZSiyWBTRhjfFcu2xlKi4Ui3a?= =?us-ascii?Q?ALTJwFT2xFgz9BAzimreqBiPo4uBwrtP9NhPYlPAe6y2SrhHTKbbwkITP2lr?= =?us-ascii?Q?XCVwYEv6jf8H0aJQdHl0eFuqC+FfD965/0Gwkq2QbLeEqy4lneaQMtgiL6es?= =?us-ascii?Q?rZVsA1srSoJvBgRUC5zQdFYab5pM6lbJhKTd2eW5rIdhFu8v5H4AwfZ8OYdh?= =?us-ascii?Q?L0Hdaai7GBripceC4ZOwfhXLhf2B5/eSCVZKlS6sjN7W00wI3OZZK8jGMnW1?= =?us-ascii?Q?YBiSjYvPxk/kQ/q4pIN5KeXXzcd7WCe+Jbxjs3tdh8Vdd1DkxBfhZFGmJu6b?= =?us-ascii?Q?6XdemEiaUEx7LBo0vJ+O0Nq3XBW1XhHUOJi3ix4rt?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1720; 6:pPwgTcqAd53sOYAUyO5ZoCUUt3eL5GAV5eJ9B7jGEsvN1TaGLZ1+/rKj/fkyX2px7xoNXAZl6YuSR5adNLrHMI8OHxnI93Ra65vO/FZ5T7BYTPfrrv9BFT2ETFAUP4oO/cajEa1Iwg/YTrdr0NeW7ptFdRLkt9Ihfp4wKIaC9A7pvADehIZST5XHAEt3tqJ1n2gUyGVHFKVyNl2w1GgU0QVFM9HiSzfL/xvFTQ6Q9ZcWWIOHYZkNV1t70Mce7KjXQ1Ld8vMUbGv9sJR6a6sL+FwytMk4SBoEd74LsQDJB6A=; 5:OL2fnIOPmXqtxt8MtgbXd3i07BT5+HFi6dGfldzQ4mGNrDDhI0tt8EEt+LNJiAUDxdHYKE85sH20srhz+zS9FdF36C+e4PHIIVNZZoXrXPppCTL2vphEWfNuxh2yhyiyJcb/6g6MlST2V6ME8sthtg==; 24:3ZcH91HEyHPexa2BFYJ+G6MHNDc+zXSCGJMBKWoVnD5kPiQKYo8n9mkPsJJigLyoWTAjUP/KxBvWsjtrejjP+C27AlDdFit96+CgnGVlkHY=; 7:u2wZLSBU5QUV9fLssgS/1zAXuTVpqALDTFCI6kY29mu6FGDydaU9gyGAtD7pORjP8dcspSkRRcVoHav5GBmaMQg1hCo+thGmmOYY/BoFlNLMcEK3r6S2NI7vKnOJ4XL4LNuvl/m6PvsvdY10JOR6CbXIyfkJFEN/eGnBejznT/zNkk1yp+X5wEdcGq+xRGz8GqbBreef0z3L19E7ufSaUXUhOXEWdOhu6ya+tIQgzbJ3T9ReGdDkKEclxbjY8bC1 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2016 02:13:53.2238 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1720 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 02:13:59 -0000 On Wed, Jul 27, 2016 at 08:51:09PM +0000, Ananyev, Konstantin wrote: > > > > > On Wed, Jul 27, 2016 at 05:33:01PM +0000, Ananyev, Konstantin wrote: > > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Wednesday, July 27, 2016 6:11 PM > > > > To: Thomas Monjalon > > > > Cc: Kulasek, TomaszX ; dev@dpdk.org; > > > > Ananyev, Konstantin > > > > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for > > > > rte_eth_dev structure > > > > > > > > On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > > > > > Signed-off-by: Tomasz Kulasek > > > > > > > --- > > > > > > > +* 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. > > > > > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > I think I understand you want to split the TX processing: > > > > > 1/ modify/write in mbufs > > > > > 2/ write in HW > > > > > and let application decide: > > > > > - where the TX prep is done (which core) > > > > > > > > In what basics applications knows when and where to call tx_pkt_prep in fast path. > > > > if all the time it needs to call before tx_burst then the PMD won't > > > > have/don't need this callback waste cycles in fast path.Is this the expected behavior ? > > > > Anything think it as compile time to make other PMDs wont suffer because of this change. > > > > > > Not sure what suffering you are talking about... > > > Current model - i.e. when application does preparations (or doesn't if > > > none is required) on its own and just call tx_burst() would still be there. > > > If the app doesn't want to use tx_prep() by some reason - that still > > > ok, and decision is up to the particular app. > > > > So my question is in what basics application decides to call the preparation. > > Can you tell me the use case in application perspective? > > I suppose one most common use-case when application uses HW TX offloads, > and don't' to cope on its own which L3/L4 header fields need to be filled > for that particular dev_type/hw_offload combination. 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 > 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. 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. 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 Jerin > Konstantin > > > > > Jerin > > > > > > > Konstantin > > > > > > > > > > > > > > > > - what to do if the TX prep fail > > > > > So adding some processing in this first part becomes "not too > > > > > expensive" or "manageable" from the application point of view. > > > > > > > > > > If I well understand the intent, > > > > > > > > > > Acked-by: Thomas Monjalon (except > > > > > typos ;)