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 80B96A04A2; Tue, 5 Nov 2019 15:37:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DE9401BEE0; Tue, 5 Nov 2019 15:37:55 +0100 (CET) Received: from dispatchb-us1.ppe-hosted.com (dispatchb-us1.ppe-hosted.com [148.163.129.53]) by dpdk.org (Postfix) with ESMTP id 11E2B1BEDD for ; Tue, 5 Nov 2019 15:37:55 +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 D7184B4005B; Tue, 5 Nov 2019 14:37:51 +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, 5 Nov 2019 14:37:45 +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 Openpgp: preference=signencrypt Autocrypt: addr=arybchenko@solarflare.com; keydata= mQINBF2681gBEACbdTxu8eLL3UX2oAelsnK9GkeaJeUYSOHPJQpV7RL/iaIskqTwBRnhjXt7 j9UEwGA+omnOmqQMpeQTb/F9Ma2dYE+Hw4/t/1KVjxr3ehFaASvwR4fWJfO4e2l/Rk4rG6Yi 5r6CWU2y8su2654Fr8KFc+cMGOAgKoZTZHZsRy5lHpMlemeF+VZkv8L5sYJWPnsypgqlCG3h v6lbtfZs+QqYbFH6bqoZwBAl5irmxywGR7ZJr1GLUZZ1lfdazSY8r6Vz0/Ip/KVxGu2uxo81 QCsAj0ZsQtwji9Sds/prTiPrIjx8Fc/tfbnAuVuPcnPbczwCJACzQr4q26XATL3kVuZhSBWh 4XfO/EAUuEq5AemUG5DDTM87g7Lp4eT9gMZB6P+rJwWPNWTiV3L7Cn+fO+l9mTPnOqdzBgDe OaulKiNSft1o0DY4bGzOmM2ad2cZt0jfnbMPMTE9zsr6+RFa+M8Ct20o6U1MUE4vP6veErMK of4kZ8PdoMM+Sq1hxMPNtlcVBSP9xMmdSZPlfDYI5VWosOceEcz7XZdjBJKdwKuz70V7eac4 ITSxgNFCTbeJ03zL2MR5s0IvD9ghISAwZ6ieCjU5UATn5+63qpD0nVNLsAdb/UpfvQcKAmvj 0fKlxu/PMVkjBa7/4cfNogYOhWDKUO+1pMaFwvb6/XTo6uMpfQARAQABtCxBbmRyZXcgUnli Y2hlbmtvIDxhcnliY2hlbmtvQHNvbGFyZmxhcmUuY29tPokCVAQTAQoAPhYhBP6NPgcKRj/Y X0yXQahue0sAy4m+BQJduvNYAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKhue0sAy4m+t3gP/j1MNc63CEozZo1IZ2UpVPAVWTYbLdPjIRdFqhlwvZYIgGIgIBk3ezKL K0/oc4ZeIwL6wQ5+V24ahuXvvcxLlKxfbJ6lo2iQGC7GLGhsDG9Y2k6sW13/sTJB/XuR2yov k5FtIgJ+aHa1PDZnepnGGOt9ka9n/Jzrc9WKYapOIIyLRe9U26ikoVgyqsD37PVeq5tLWHHA NGTUKupe9G6DFWidxx0KzyMoWDTbW2AWYcEmV2eQsgRT094AZwLFN5ErfefYzsGdO8TAUU9X YTiQN2MvP1pBxY/r0/5UfwV4UKBcR0S3ZvzyvrPoYER2Kxdf/qurx0Mn7StiCQ/JlNZb/GWQ TQ7huduuZHNQKWm7ufbqvKSfbPYvfl3akj7Wl8/zXhYdLqb5mmK45HXrgYGEqPN53OnK2Ngx IgYKEWr05KNv09097jLT5ONgYvszflqlLIzC4dV245g7ucuf9fYmsvmM1p/gFnOJBJL18YE5 P1fuGYNfLP+qp4WMiDqXlzaJfB4JcinyU49BXUj3Utd6f6sNBsO8YWcLbKBV9WmA324S3+wj f4NPRp3A5E+6OmTVMLWire2ZvnYp3YvifUj1r8lhoZ2B2vKuWwiTlHOKYBEjnOQJQnqYZEF0 JQQ1xzVDBQKE01BPlA3vy6BGWe6I4psBVqMOB9lAev/H+xa4u6Z3uQINBF269JsBEAC2KB3W 8JES/fh74avN7LOSdK4QA7gFIUQ4egVL81KnxquLzzilABuOhmZf3Rq6rMHSM8xmUAWa7Dkt YtzXStjEBI/uF0mAR3mMz1RcL2Wp+WD/15HjVpA7hPjXSEsWY0K2ymPerK4yrLcfFTHdMonY JfuACCC9NtOZxrWHOJoUS+RT7AWk80q/6D2iwQ47/2dBTznVG+gSeHSes9l91TB09w6f9JX/ sT+Ud0NQfm7HJ7t2pmGI9O6Po/NLZsDogmnIpJp/WwYOZN9JK7u2FyX2UyRzR8jK42aJkRsh DXs16Cc2/eYGakjrdO3x9a+RoxN7EuFtYhGR1PzMXdUiB5i+FyddYXkYUyO43QE/3VPA5l1v TUOagzZq6aONsdNonGJkV3TIG3JmUNtM+D/+r6QKzmgoJ8w576JxEZI09I/ZFN+g7BnUmlMx 6Z3IUOXVX/SWfGFga0YajwajHz03IBhChEbYbbqndVhmshu2GFURxrfUPYWdDXEqkh+08a5U Didia9jm2Opv4oE1e1TXAePyYJl/Zyps4Cv00GObAxibvMBQCUZQ+IBnNldRBOwXXRQV2xpx P+9iO1VYA/QXn0KqRK+SH1JGRXbJYi42YFaW1gE0EU0fiR2Wb9pK+doNEjjOhlzUGuvOEAUS +4m0m3dlfEvpCV9GMr7ERRpZzh9QkQARAQABiQI8BBgBCgAmFiEE/o0+BwpGP9hfTJdBqG57 SwDLib4FAl269JsCGwwFCQlmAYAACgkQqG57SwDLib7x6g//e+eCtNnJz7qFGbjWRJYNLCe5 gQwkhdyEGk4omr3VmjGj3z9kNFy/muh4pmHUngSAnnpwZggx14N4hhKf9y8G4Dwvsqa6b1zB Jq/c4t/SBDtGW4M/E331N04PaQZpcrbTfp1KqHNknk2N7yOk4CcoLVuIZmA5tPguASV8aAfz ZwhWAwn6vUEw9552eXEAnGFGDTCbyryNwzB5jtVQOEEDjTxcCkpcXMB45Tb1QUslRTu/sBAe HhPCQSUcJHR+KOq+P6yKICGAr291PZd6Qc7C3UyE+A3pY/UfdEVWj0STBWx1qvYLaHLrI4O9 KXDgh7luLjZZafcueCaPYmNo4V2lmNb3+7S4TvqhoZS+wN+9ldRQ4gH3wmRZybN6Y/ZCqxol RaZpE3AqdWsGvIgAkD0FpmtZNii9s2pnrhw0K6S4t4tYgXGTossxNSJUltfFQZdXM1xkZhtv dBZuUEectbZWuviGvQXahOMuH2pM64mx2hpdZzPcI2beeJNHkAsGT2KcaMETgvtHUBFRlLVB YxsUYz3UZmi2JSua4tbcGd6iWVN90eb8CxszYtivfpz6o2nPSjNwg0NaVGSHXjAK0tdByZ9t SkwjC3tEPljVycRSDpbauogOiAkvjENfaPd/H26V5hY822kaclaKDAW6ZG9UKiMijcAgb9u5 CJoOyqE8aGS5Ag0EXbr1RwEQAMXZHbafqmZiu6Kudp+Filgdkj2/XJva5Elv3fLfpXvhVt0Y if5Rzds3RpffoLQZk9nPwK8TbZFqNXPu7HSgg9AY7UdCM94WRFTkUCGKzbgiqGdXZ7Vyc8cy teGW+BcdfQycDvjfy50T3fO4kJNVp2LDNdknPaZVe8HJ80Od63+9ksB6Ni+EijMkh6Uk3ulB CSLnT4iFV57KgU2IsxOQVLnm+0bcsWMcCnGfphkY0yKP+aJ6MfmZkEeaDa7kf24N14ktg50m vOGDitcxA/+XXQXOsOIDJx1VeidxYsQ2FfsKu1G8+G6ejuaLf4rV5MI/+B/tfLbbOdikM5PF pxZVgTir9q13qHumMxdme7w5c7hybW412yWAe9TsrlXktFmFjRSFzAAxQhQSQxArS6db4oBk yeYJ59mW52i4occkimPWSm/raSgdSM+0P6zdWUlxxj+r1qiLgCYvruzLNtp5Nts5tR/HRQjE /ohQYaWDSVJEsc/4eGmgwzHzmvHtXeKkasn01381A1Lv3xwtpnfwERMAhxBZ8EGKEkc5gNdk vIPhknnGgPXqKmE1aWu8LcHiY+RHAF8gYPCDMuwyzBYnbiosKcicuIUp0Fj8XIaPao6F+WTi In4UOrqrYhsaCUvhVjsTBbNphGih9xbFJ8E+lkTLL8P3umtTcMPnpsB4xqcDABEBAAGJBHIE GAEKACYWIQT+jT4HCkY/2F9Ml0GobntLAMuJvgUCXbr1RwIbAgUJCWYBgAJACRCobntLAMuJ vsF0IAQZAQoAHRYhBNTYjdjWgdaEN5MrAN+9UR5r/4d3BQJduvVHAAoJEN+9UR5r/4d3EiQP /3lyby6v49HTU94Q2Fn2Xat6uifR7kWE5SO/1pUwYzx6v+z5K2jqPgqUYmuNoejcGl0CTNhg LbsxzUmAuf1OTAdE+ZYvOAjjKQhY4haxHc4enby/ltnHfWJYWJZ9UN5SsIQLvITvYu6rqthO CYjpXJhwkj3ODmC9H1TrvjrBGc6i7CTnR8RCjMEwCs2LI2frHa4R6imViEr9ScMfUnzdABMQ B0T5MOg8NX92/FRjTldU2KovG0ML9mSveSvVHAoEBLy4UIs5nEDdNiO1opJgKb5CXvWQugub 7AR52phNdKVdEB0S4tigJT4NalyTaPiUhFEm+CzZpMQDJ5E+/OowaPRfN4HeJX+c8sB+vUAZ mkAaG75N+IEk5JKFK9Z+bBYgPgaBDFZYdWDB/TMH0ANt+KI5uYg0i12TB4M8pwKG1DEPUmWc F2YpvB3jnbwzsOpSFiJOOlSs6nOB0Sb5GRtPOO3h6XGj+6mzQd6tcL63c9TrrUkjq7LDkxCz SJ2hTYRC8WNX8Uw9skWo5728JNrXdazEYCenUWmYiKLNKLslXCFodUCRDh/sUiyqRwS7PHEA LYC/UIWLMomI0Yvju3KA5v3RQVXhL+Gx2CzSj3GDz9xxGhJB2LfRfjzPbTR/Z27UpjCkd8z0 Ro3Ypmi1FLQwnRgoOKDbetTAIhugEShaLTITzJAP/iRDJCQsrZah5tE8oIl81qKEmBJEGcdt HYikbpQe7ydcXhqTj7+IECa3O7azI5OhCxUH2jNyonJ/phUslHH2G1TTBZK8y4Hrx5RpuRNS esn3P9uKu9DHqBAL7DMsCPwb2p1VNnapD72DBmRhzS/e6zS2R4+r9yNv03Hv7VCxKkmtE63H qpS//qpjfrtsIcHAjnKDaDtL1LYCtHoweI+DOpKKULSAYp/JE6F8LNibPQ0/P3S5ZIJNC4QZ uESjFOalJwFIqGQdkQB7ltRNJENLrHc+2jKGOuyFHm/Sbvp5EMGdaeQ0+u8CY0P+y6oXenwx 7WrJz/GvbNoFhJoJ6RzxCMQrFgxrssVZ7w5HcUj94lbnJ6osdYE/WpSd50B6jet6LKh5revg u9XI9CoqsPQ1V4wKYYdllPuogCye7KNYNKuiiuSNpaF4gHq1ZWGArwZtWHjgc2v3LegOpRQF SwOskMKmWsUyHIRMG1p8RpkBQTqY2rGSeUqPSvaqjT0nq+SUEM6qxEXD/2Wqri/X6bamuPDb S0PkBvFD2+0zr5Bc2YkMGPBYPNGZiTp3UjmZlLfn3TiBKIC92jherY563CULjSsiBEJCOSvv 4VPLn5aAcfbCXJnE3IGCp/hPl50iQqu7BPOYBbWXeb9ptDjGCAThNxSz0WAXkmcjAFE8gdE6 Znk9 Message-ID: Date: Tue, 5 Nov 2019 17:37:41 +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" Content-Language: en-GB Content-Transfer-Encoding: 7bit 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-25022.003 X-TM-AS-Result: No-16.783900-8.000000-10 X-TMASE-MatchedRID: yebcs53SkkA9gZmQY0RBhPZvT2zYoYOwC/ExpXrHizzLkl8e9W70i5FS DYziOe5w51GRYHrT8X8zbxRNgA4zXRxaKzlXbEWl6OX7GFz9H1BY1sGlD74jWebnFWpNX1DBkkA Wgtt4yWcJTEag1rO6OXGY8PW7XLnvVByxqzbqctDm96eHJyFxjSIk3dpe5X+hBCzD0Dc8iUuOFV f0NygKIEyesZnme9cfoh17lzBq5crrBxJKZf+ir1HmrymVJ0uQBGvINcfHqhcMrRrnLCZEmqf4O 0AyJYLdQfj3NGNP6usJFc5T3wrsm36MRtImhbIooxjrap5AGQs8y4ak9CnjYjsUTbqaO707G9ld gdPsk0XZfxIlRtpm428qeTGhOotKVV5xchvUVKsFZev51JnVPabsRRaTaNLR+frbXg+Uc4WejEx 8E/02Zc/wEB40STlrPDylddP3mEXFVSBMr2cm9M87s4OnYGuCy0Q+dW8+UWRjOGV4Ao9OZGkh38 w93r3j++l8X+G9XR+DtLFkM4XXH2GN6M1vhJ4HvHKClHGjjr2etXbGdn9vCd9RlPzeVuQQSa4va vKbRAFCWP8xABc3O2ud8TrXyPY9MGg+wgnY/elxoP7A9oFi1q5BoXfdPww+aXMSjtscW85mkX/u CWPt8vSAdN258YvZDCmI0VYWhOOioKUtUDGXZTfu+RTlciXg/yjrMxkSCxjDra5IbmQvVsK0+q2 QMjXtglYZwkabR44EVrPbq5wL5/tIsaxPttTqLIrMljt3adttEwCdRLjQZlmT1oQ//o7X8Y0ikQ kfzq0QlEH4Tm58Pb1Odlcux5HWTX7PJ/OU3vKDGx/OQ1GV8pPNXDv0GgtYJdW0GbI6Iq6OhzOa6 g8KrY56fN3HwpzILAe/w8uLln3AStAQEb7P7Kuiho23cDvPoncOeKBgF5U= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--16.783900-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25022.003 X-MDID: 1572964674-cvrZXxWeUiD7 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/5/19 5:05 PM, Matan Azrad wrote: > From: Andrew Rybchenko >> On 11/3/19 6:16 PM, Matan Azrad wrote >>> From: Andrew Rybchenko >>>> 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. >>> >>> So, are you agree It should not be checked globally for all the offloads in >> ethdev layer? >> >> If offload is not requested, but enabled (since PMD cannot disable it), right >> not it will not fail configure, but warn about it in logs. >> > > In this case warning print is not enough since it can be critical for the application for some offloads. > It can be very weird for the application to see that some offload are on while the application doesn't expect them to be on. > it even can cause app crash(at least for the RX offload I wrote above). The patch improves the situation. Earlier it was silent, now it will be at least visible. I'm afraid that in 19.11 release cycle we cannot change it to fail dev_configure. I think it will be too destructive. Future improvement should be discussed separately. >>> It even be more problematic if the dynamic offload field in mbuf is not exist at all. > > Any answer here? Please, clarify the question. >>>> >>>>> 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. >>> >>> yes, you right, In TX it looks less critical (for now). >>> >>>> >>>>>> 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. >>> >>> Sorry, I don't understand your use case here. >> >> If application wants to try code path without, for example, Rx checksum >> offload, it could be insufficient to disable the offload right now, but also >> required to cleanup offload results flags in each mbuf (if PMD does not >> support the offload disabling). > > What is "right now"? Configuration time? Right now is the current state of some drivers in DPDK tree. > If application will know that PMD cannot disable the rx-checksum in configuration time, > It can plan to not clean this flag in mbuf for each rx mbuf. Yes and application has a way to know it - take a look at dev->data->dev_conf.rxmode.offloads. > It looks me like PMD limitation which can be solved by 2 options: > 1. Capability information which say to the app what offload may not be disabled. > 2. Add limitation in the PMD documentation and print warning\error massage from the PMD. Yes, right now we are going way (2). >>>>> 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 >>> >