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 21025A0352; Sun, 3 Nov 2019 13:12:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 91E3B1D447; Sun, 3 Nov 2019 13:12:42 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id CA1A91D421 for ; Sun, 3 Nov 2019 13:12:41 +0100 (CET) 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 869BFB80070; Sun, 3 Nov 2019 12:12:40 +0000 (UTC) Received: from [192.168.1.192] (188.242.181.57) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 3 Nov 2019 12:12:33 +0000 To: Matan Azrad , Pavan Nikhilesh Bhagavatula , "ferruh.yigit@intel.com" , Jerin Jacob Kollanukkaran , Thomas Monjalon CC: "dev@dpdk.org" References: <20191029050312.2715-1-pbhagavatula@marvell.com> <20191029153722.4547-1-pbhagavatula@marvell.com> <20191029153722.4547-4-pbhagavatula@marvell.com> <0547e0a0-1ccd-84ee-46f1-5b35e1d25680@solarflare.com> From: Andrew Rybchenko Message-ID: Date: Sun, 3 Nov 2019 15:12:25 +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-US X-Originating-IP: [188.242.181.57] 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-25018.003 X-TM-AS-Result: No-12.444300-8.000000-10 X-TMASE-MatchedRID: Jm7Yxmmj9Ok9gZmQY0RBhPZvT2zYoYOwC/ExpXrHizzLkl8e9W70i5FS DYziOe5w51GRYHrT8X8zbxRNgA4zXRxaKzlXbEWl6OX7GFz9H1BY1sGlD74jWebnFWpNX1DBkkA Wgtt4yWcJTEag1rO6OXGY8PW7XLnvVByxqzbqctDm96eHJyFxjSIk3dpe5X+hBCzD0Dc8iUuOFV f0NygKIEyesZnme9cfoh17lzBq5crrBxJKZf+ir1HmrymVJ0uQBGvINcfHqhcMrRrnLCZEmqf4O 0AyJYLdQfj3NGNP6usJFc5T3wrsm36MRtImhbIooxjrap5AGQs8y4ak9CnjYjsUTbqaO707G9ld gdPsk0XDeL2cMmsYk7ModMinzqmk6L7dbFpNDm8vLP1C8DIeOjyW+6AAWIU/DpCUEeEFm7BqOmk OtBFAiPNF5KLxDtQCLsYvVCvFQ3lpokC3EjW38N3tFiKyU7Vfer1wlVoR6TQoFW8VuxQzlVjliz Jai/d7wP4lJVAHLnxV+9a+ZVGpWU1+zyfzlN7ygxsfzkNRlfKx5amWK2anSPoLR4+zsDTtX28xN pU0U3PwPpkq2hlAX8lBIcsFDRtx1E7EjT3Pc6Vhv8dWErJ1pA== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--12.444300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25018.003 X-MDID: 1572783161-wbqMzx5_r757 Subject: Re: [dpdk-dev] [PATCH v15 3/7] ethdev: add validation to offloads set by PMD 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 11/3/19 9:57 AM, Matan Azrad wrote: > Hi > > From: Andrew Rybchenko >> On 10/31/19 7:33 PM, Pavan Nikhilesh Bhagavatula wrote: >>>> From: Pavan Nikhilesh Bhagavatula >>>>> Hi Matan, >>>>> >>>>>> Hi Pavan >>>>>> >>>>>> From: Pavan Nikhilesh >>>>>>> Some PMDs cannot work when certain offloads are enable/disabled, >>>>>>> as a workaround PMDs auto enable/disable offloads internally and >>>>>>> expose it through dev->data->dev_conf.rxmode.offloads. >>>>>>> >>>>>>> After device specific dev_configure is called compare the >>>>>>> requested offloads to the offloads exposed by the PMD and, if the >>>>>>> PMD failed to enable a given offload then log it and return >>>>>>> -EINVAL from rte_eth_dev_configure, else if the PMD failed to >>>>>>> disable a given offload log and continue with rte_eth_dev_configure. >>>>>>> >>>>>> rte_eth_dev_configure can be called more than 1 time in the device >>>>>> life time, How can you know what is the minimum offload >>>>>> configurations required by the port after the first call? >>>>>> Maybe putting it in dev info is better, what do you think? >>>>>> >>>>> We only return -EINVAL in the case where we enable an offload >>>>> advertised by dev_info and the port still fails to enable it. >>>> Are you sure it is ok that devices may disable\enable offloads under >>>> the hood without user notification? >>> Some devices already do it. The above check adds validation for the same. >> The problem is that some offloads cannot be disabled. > Yes, I understand it. > >> If application does not request Rx checksum offload since it does use it, it is >> not a problem to report it. > Yes, for RX checksum I tend to agree that application doesn't care if the PMD will calculate the checksum in spite of the offload is disabled. > > But what's about other offloads: > For example in RX: LRO, CRC_KEEP, VLAN_STRIP, JUMBO > If the PMD will stay them on while the app is disabling it, It can cause a problems to the application (affects the packet length). Yes, I agree that some offloads are critical to be disabled, but RSS_HASH discussed in the changeset is not critical. > For example in TX: TSO, VLAN, MULTI_SEG..... Tx is not that critical since application should not request these offloads per-packet. Tx offloads are mainly required to ensure that application may request the offload per packet and it will be done. >> Of course, it could be a problem if the offload is >> used, but application wants to disable it, for example, for debugging >> purposes. >> In this case, the solution is to mask offloads on application level, which is not >> ideal as well. > Why not ideal? It eats CPU cycles. > If application can know the limitation of offloads disabling (for example to read capability on it) > The application has all information to take decisions. > >> Anyway, the patch just tries to highlight difference of applied from >> requested. So, it is a step forward. >> Also, the patch will fail configure if an offload is requested, but not enabled. >> >>>> Can't it break applications? >>>> Why does the device expose unsupported offloads in dev info? >>>> Does it update the running offload usynchronically? Race? >>>> Can you explain also your specific use case? >>>> >>>> >>>>>> Matan