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 4BBA1A04B3; Mon, 16 Dec 2019 11:02:26 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 67B421BFAB; Mon, 16 Dec 2019 11:02:25 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 8485C1BFA2 for ; Mon, 16 Dec 2019 11:02:23 +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-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 555FCA8005A; Mon, 16 Dec 2019 10:02:20 +0000 (UTC) Received: from [192.168.38.17] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 16 Dec 2019 10:02:11 +0000 To: Jerin Jacob CC: Thomas Monjalon , Ferruh Yigit , Pavan Nikhilesh , "Neil Horman" , John McNamara , Marko Kovacevic , dpdk-dev , Ori Kam , David Marchand , "Olivier Matz" , "Ananyev, Konstantin" References: <1574165145-23960-1-git-send-email-arybchenko@solarflare.com> <1788171.neaCWyZYis@xps> <1832509.BOePYM8p3J@xps> <12030c31-8a03-ca14-272f-e3bc01652721@solarflare.com> From: Andrew Rybchenko 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: <05551069-2352-127b-19e6-6b1dee4ca697@solarflare.com> Date: Mon, 16 Dec 2019 13:02:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.10.39] 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-25106.003 X-TM-AS-Result: No-11.804300-8.000000-10 X-TMASE-MatchedRID: CxmI61mtwh/4ECMHJTM/ufZvT2zYoYOwC/ExpXrHizw/hcT28SJs8syu 4+f3m+vl4ACCZKxQxm1g2TjPfw834+4oGFq8y69jMpVOsYwN78NwRrWVhCqQ6Xc925yOJXmFlpU RWYIlgV7kt0mEkp3KHhPLKLQZGRcht+m1lNsVVIpmPsTq8ee41hfbPFE2GHrVeuOjdf174McRhl avr61wtDde18o1cvwhwQljsXcMoS1HSegabJM0yyqRJ4M9q7OvUg5zxCPHJW3ieGQLRIaTJABJD O15WqH4MOPRZfc0gUkrjfnCM3b8RZPyJ1YfvGX+HC7hAz/oKnKuPZ71srL6JGiXUImMt4izvOvH E94gdo9pO0vcZvB8h58J44C21mk5FQ1mDTKIoFG7335YZAh4Cy9Xl/s/QdUMy5JfHvVu9Is48Hu 1yQGFD0o7hMXrpRda0hgZetLwd4PWmyDk+eNZHxbwCXv1ucAPZAGtCJE23Yhn4oVvIVnpkMEYHn JZxFh9UDYGlQbJDZZepifkDLjmwxYs5jizXQV0fzgVmnL/olW+PlVZvoI2ZRQUOSCpbPwOQlfmK k5XlH1O9oIUGo137GL3Sk7wzVRmMDvZPMbvTD5xfpld8usylJhMhys3ONi8n70FvgYA38mVKkRe E4K0FOIaDjtPnxyoUryNtsGmsn7WOupE2o8yKubYQfV8R6TbvvsJC2qWnXc/axbZ2VgIHwra6As /+dS3pIa5O4GntwDKcrEu6wvFbTguGA/eFbnAJNzc11O35noYgyDj5TiRtalTFDGZMPhCVua0Gc Q2u2PNntR+R/2HYlyRaLcCbplugsynPf9nqvSeAiCmPx4NwLTrdaH1ZWqC1B0Hk1Q1KyJHtBsf5 /UXJbVQu1GNZ+si4kYXbobxJbKl/MtrTwS4UOh5bHdupcjXJfkUUVhEHBUDwm7UeQgxQ4bNW7OY ljYmdASQGzjCXvA= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--11.804300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-25106.003 X-MDID: 1576490542-NlJYc4qVes0p Subject: Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice 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 12/16/19 10:38 AM, Jerin Jacob wrote: > On Mon, Dec 9, 2019 at 2:47 PM Andrew Rybchenko > wrote: >> >> On 12/5/19 11:12 AM, Jerin Jacob wrote: >>> On Mon, Dec 2, 2019 at 5:27 PM Andrew Rybchenko >>> wrote: >>>> >>>>>> >>>>> Ack. >>>> >>>> Yes, I agree as well, but in general we already have an >>>> exception MBUF_FAST_FREE which is just a nice wrap for >>>> enabled by default support for mbufs from different >>>> mempools and support for mbuf reference counters. >>>> I don't suggest to change it. Just want to highlight >>>> that we already have exceptions (nicely wrapped). >>>> That's why I would not touch packet type parsing >>>> "offload". Packet type parsing is not just on/off and >>>> adding on/off in addition to existing API looks overkill. >>>> Yes, it is one more exception, but nicely wrapped as well. >>> >>> I am all for making offloads disabled by default. >>> >>>> >>>>>>> And what would be DEFAULT behavior for the mbuf MARK updation feature? >>>>>>> (That's where this thread started). >>>>>> >>>>>> As all other features, mark is disabled by default. >>>>>> Using a rte_flow rule, it can be enabled. >>>>>> No need to pre-enable it. >>>>> >>>>> Ok. >>>> >>>> But it returns us to the point where we started [1]: >>>> >>>> The problem: >>>> ~~~~~~~~~~~~ >>>> PMD wants to know before port start if application wants to >>>> to use flow MARK/FLAG in the future. It is required because: >>>> >>>> 1. HW may be configured in a different way to reserve resources >>>> for MARK/FLAG delivery. >>>> >>>> 2. Datapath implementation choice may depend on it (e.g. vPMD >>>> is faster, but does not support MARK). >>>> >>>> opt-in/opt-out solution has drawbacks mentioned above. >>>> Also I'm not sure if opt-in/opt-out is per-queue or per-port. >>>> (Offloads may be naturally per-queue and it is a big advantage). >>>> >>>> IMHO feature which should be opt-out is almost equivalent to >>>> offload enabled by default. It has the same negative properties >>>> as enabled by default offloads. >>>> >>>> Am I missing something again? >>>> >>>> From my point of view I see no problem in necessity to say >>>> in advance (before device start) that application would like >>>> to use some features at run time. >>> >>> I agree with your problem definition and solution as offload. >>> >>> I think, our constraint is, we can not change functional ABI behavior >>> for the next year. i.e The existing application should work for the >>> next year without >>> changing the code. >>> >>> I think, it all boiling down to adhere to that constraint or not for >>> this specific case. >> >> May be the escape is to avoid consistency checks in generic >> code (not sure that such checks are doable/required in this >> case, but anyway) and make the behaviour change vendor/driver- >> specific. I understand that it is far from ideal solution. >> >> May be offload should be combined with opt-out as a way to >> disable. I.e. offload is positive (not negative), but enabled >> by default (i.e. automatically added to offloads as we do >> for RSS_HASH) with an experimental opt-out to disable it. >> >> As the result: >> 1. There is no changes in behaviour from application point of >> view. >> 2. Application which care about performance and ready to use >> experimental opt-out to optimize performance can do it. >> (i.e. use opt-out to avoid the offload enabled by default). >> 3. Later when window to normalize behaviour opens, opt-out >> becomes NOP (i.e. it still could be preserved for some >> time to simplify transition). >> 4. The offload is enabled by default during transition >> period only since it represents a feature which had >> no offload flag before and was always enabled before. >> 5. As an offload the feature may be controlled per-device >> and per-queue natively. > > Looks good to me. > It makes sense to have a generic opt API to have for year ABI, > which works on > > - per queue/per port > - Enable by default to keep backward compatible. > - Have a generic signature to allow probe() all the enabled opt-in features > and then disable if required by the application. I'd like to clarify to be sure that we're on the same page: 1. Add DEV_RX_OFFLOAD_FLOW_MARK offload: - enabled by default till 20.11 to preserve behaviour - applications may migrate and explicitly enable - disabled by default since 20.11 to switch to generic policy which require offloads to be disabled by default 2. Add experimental opt-out which allow to disable the offload to optimize performance for applications which would like to care about it early - opt-out remains but becomes NOP in 20.11 > - I think, rte_eth_dev_set_ptypes() needs to change to generic API as > it comes under opt-in/out scheme. I'm not sure that I understand how it should look like for ptypes. >> >> It still does not sort out "necessity to enable twice" >> concern which for specified above "the problem", IMO, >> contradicts to "disabled by default offloads" (I read >> it as "the best performance" by default). >> >>> Once that is decided, we can wrap it in offload flags vs opt scheme >>> (by default enabled scheme). >> >> Yes. May be I don't understand all the details of the opt >> scheme right now, but I don't like what I can imagine as >> described above. >> >>>> >>>> Yes, all features which may be controlled at run-time are >>>> headache for optimizations (VLAN offloads). >>>> >>>> [1] >>>> http://inbox.dpdk.org/dev/f170105b-9c60-1b04-cb18-52e0951ddcdb@solarflare.com/ >>