From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 96FEAA328D for ; Tue, 22 Oct 2019 14:56:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 16EF51BED7; Tue, 22 Oct 2019 14:56:26 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 4A5DA1BED5 for ; Tue, 22 Oct 2019 14:56:24 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id CF3DFB80069; Tue, 22 Oct 2019 12:56:22 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 22 Oct 2019 13:56:16 +0100 To: Ferruh Yigit , Thomas Monjalon , Matan Azrad CC: "dev@dpdk.org" , Konstantin Ananyev , Olivier Matz References: <1567064832-22457-1-git-send-email-matan@mellanox.com> <20689129.oFjp0lEai2@xps> From: Andrew Rybchenko Message-ID: <4c207d28-a873-ac42-9daf-0655cd6280a3@solarflare.com> Date: Tue, 22 Oct 2019 15:56:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24994.003 X-TM-AS-Result: No-5.765900-8.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1hr2bIFd4uhtPZvT2zYoYOwofZV/2Xa0cJRnaQSGsK/JJWi xnDxF7NQmdbjPRpbe23A7V1UWABhggtgJ854eHwOUeavKZUnS5Cb6i6a65DFtpGhAvBSa2i/MJa nXwc+hbxcgiulxglfmiRNyKgx6iJUcJsCSs5qF7zylEfNwb6iLTAuMzu3eJGjAqmSGaN08VAnui +WQ9elLUbDlVa5CA1BVoMV+94UBNO2blHvx2C+qoicBKfMHlV8K1zvw58EectPvOpmjDN2kk06v Y7ZUz/nS37ylPfL+Exv7fBaGURqDjUZn1MYzuPI2fov7TwhL8mi7zn2xJwhipm3TxN83Lo4YNbW kXAVzLoOuRvQ0s5Wu+xsL9XDoOGTTX7PJ/OU3vKDGx/OQ1GV8rHlqZYrZqdI+gtHj7OwNO1/FUQ jcNJIg1D1iAI1JaGLssIpNk3poQgnrvTHRP1UT64tv6KqdLhL/EyqZvzx+eXEWuZZluX1jEnJfu XdNHundYQH3KkUxO9w3sqB5d6YFVHTb2Y4zo/QutwTzHK3ELl3mFldkWgHw/FbH3cFJjLJwL6Sx Ppr1/I= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--5.765900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24994.003 X-MDID: 1571748983-q6xBCIAd4zA8 Subject: Re: [dpdk-dev] [RFC] ethdev: add new fields for max LRO session size 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/18/19 7:35 PM, Ferruh Yigit wrote: > On 10/2/2019 2:58 PM, Thomas Monjalon wrote: >> 24/09/2019 14:03, Matan Azrad: >>> From: Ferruh Yigit >>>> On 9/15/2019 8:48 AM, Matan Azrad wrote: >>>>> Hi Ferruh >>>>> >>>>> From: Ferruh Yigit >>>>>> On 8/29/2019 8:47 AM, Matan Azrad wrote: >>>>>>> It may be needed by the user to limit the LRO session packet size. >>>>>>> In order to allow the above limitation, add new Rx configuration for >>>>>>> the maximum LRO session size. >>>>>>> >>>>>>> In addition, Add a new capability to expose the maximum LRO session >>>>>>> size supported by the port. >>>>>>> >>>>>>> Signed-off-by: Matan Azrad >>>>>> Hi Matan, >>>>>> >>>>>> Is there any existing user of this new field? >>>>> All the LRO users need it due to the next reasons: >>>>> >>>>> 1. If scatter is enabled - The dpdk user can limit the LRO session size created >>>> by the HW by this field, if no field like that - there is no way to limit it. >>>>> 2. No scatter - the dpdk user may want to limit the LRO packet size in order >>>> to save enough tail-room in the mbuf for its own usage. >>>>> 3. The limitation of max_rx_pkt_len is not enough - doesn't make sense to >>>> limit LRO traffic as single packet. >>>> So should there be more complement patches to this RFC? To update the >>>> users of the field with the new field. >>> >>> We already exposed it as ABI breakage in the last deprecation notice. >>> We probably cannot complete it for 19.11 version, hopefully for 20.02 it will be completed. >> We won't break the ABI in 20.02. >> What should be done in 19.11? >> > The ask was to add code that uses new added fields, this patch only adds new > field to two public ethdev struct. > > @Thomas, @Andrew, if this patch doesn't goes it on this release it will have to > wait a year. I would like to see the implementation but it is not there, what is > your comment? I don't mind to accept it in 19.11 modulo better description of what is LRO session length/size.