From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 4C178A0471 for ; Fri, 21 Jun 2019 09:40:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D4AE21D548; Fri, 21 Jun 2019 09:40:08 +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 557FB1D542 for ; Fri, 21 Jun 2019 09:40:07 +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-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BA26E280057; Fri, 21 Jun 2019 07:40:05 +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; Fri, 21 Jun 2019 08:40:00 +0100 To: "Wang, Haiyue" , "dev@dpdk.org" CC: "Yigit, Ferruh" , Thomas Monjalon References: <1561015552-37671-1-git-send-email-haiyue.wang@intel.com> <41d93d60-9097-48a4-6a26-8ebd0cfb4b39@solarflare.com> <3500154e-74e5-d4f7-6606-ad1fea300f0e@solarflare.com> From: Andrew Rybchenko Message-ID: <8751ae1d-a912-5716-59d4-3afbeb89a057@solarflare.com> Date: Fri, 21 Jun 2019 10:39:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: 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-24700.000 X-TM-AS-Result: No-18.514100-8.000000-10 X-TMASE-MatchedRID: JQSF04SbSlQQo9nihO6svo+jnIR/zCDxQtntDL6PCaihGGri4vovWPHk pkyUphL9AZn/4A9db2RLxCuBTCXaKgVo0F7Vwe/OPvrS9fsPUJtaHQACyuJADs+D6Af5OJeTlVH M/F6YkvQ4aqCddpoaJ9EsTITobgNEFPuahfa4tRUaoao+iSXkcRn04dPgZKeAx07MR/s5Q+SjuI lLojrNoUloPruIq9jTabJxhiIFjJmvbWyVhvZLwKEZNPBB8pBRQJq9Lk29DSwBm1BZMJ5EIm6yf YFZzrGdaPUJ2CQlYPJBbp4JobErAqC46wpoC9j1+NAMkh+2KQ+nhIHSnJCHA5VvPoxSj5rmIwk7 p1qp3JbdYVrFVbszaKTEIOgFcjqDKA9FtxgpcbssVfBcf0Z2z5OGnh8ob1fCBBja7g4HU82/W88 A/PbYWR50fE5Jh+oKfkiy7TTogYYqv09cRjfT0b42s5T04guOne5o1ye7TJPOPx8/F/+WJIS/TV 9k6ppAGrSmht4ssAfXLRpcXl5f6H2c4QF6Y/C8QOOLVXP+lL3iYkW/GVrVBKuK6f8YXGKxaDgPZ BX/bMuuiAW0p38/t8eILR3BvknvUdfEKc10rU79hat6Mb3lf+6i+CFG0PeWYcjDoVD2e568yvUR lYGCIVNYbkWQyPvq1xLW0OKX8iPIeAQugZMNBFtyNHRhmjtfAllRMNbKfG3a8AiR/nR5gzE06wH A1+f+AcGk+q40InQXM2Z1UyweuBgD5tyRPQ2aps3lfGert5fkDSnQ4pt5DR9Y4JKAR7G8ZjQijg rFvzqGUvn89UwyEr69Io9xnAWW2PCdE+jq61Pi8zVgXoAltkWL4rBlm20v+dkjd91LgAAelJ9Tf lOPDQQGgUpfrVIXhUfR2rvBju7jwPARt2x+XGetzc4D6q1J9c0CtVKmWO3nGFUsw5nMnbhhwJKY EUffhKm3aBoHea76l4XWLW+zgYnWb4esMmakZ/+41dK/7N3K65bTVG1mFQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.514100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24700.000 X-MDID: 1561102806-Xi7wME97AVME Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch 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 6/21/19 10:37 AM, Wang, Haiyue wrote: > > Then this is not so generic if a workaround is needed. In other words, > no one is so perfect. J > Yes, it is a bug. No one is perfect. > BR, > > Haiyue > > *From:*Andrew Rybchenko [mailto:arybchenko@solarflare.com] > *Sent:* Friday, June 21, 2019 15:34 > *To:* Wang, Haiyue ; dev@dpdk.org > *Cc:* Yigit, Ferruh ; Thomas Monjalon > > *Subject:* Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload > most-significant bits for PMD scartch > > On 6/21/19 4:12 AM, Wang, Haiyue wrote: > > Not so frightening in real world for an application to be aware of > its NICs: > > https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_ethdev.c#L387 > > > > > > In this particular case it is just a workaround for bonding and bnxt. > Driver name is provided and sufficient to make it possible when > absolutely required. > > > > Yes, we need to avoid this kind of design. > > BR, > > Haiyue > > *From:*Andrew Rybchenko [mailto:arybchenko@solarflare.com] > *Sent:* Friday, June 21, 2019 02:30 > *To:* Wang, Haiyue > ; dev@dpdk.org > *Cc:* Yigit, Ferruh > ; Thomas Monjalon > > *Subject:* Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload > most-significant bits for PMD scartch > > CC ethdev maintainers > > On 6/20/19 10:25 AM, Haiyue Wang wrote: > > Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities > > of a device is one-bit field definition, it has 64 different values at > > most. > > > > Nowdays the receiving queue of NIC has rich features not just checksum > > offload, like it can extract the network protocol header fields to its > > RX descriptors for quickly handling. But this kind of feature is not so > > common, and it is hardware related. Normally, this can be done through > > rte_devargs driver parameters, but the scope is per device. This is not > > so nice for per queue design. > > > > The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct > > rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping > > the ethdev API & ABI compatibility, and the application can make good > > use of the NIC's specific features, reserving the most-significant bits > > of RX offload seems an compromise method. > > > > Then the PMDs redefine these bits as they want, all PMDs share the same > > bit positions and expose their new definitions with the header file. > > > > The experimental reserved bits number is 6 currently. Tt can be one-bit > > for each features up to the the maximum number 6. It can also be some > > bits encoding: e.g, 6 bits can stand for 63 maximum number of features. > > > > We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left > > unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) = > > 39. > > > > This is not so nice for applications, they need to check PMD's driver > > name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it > > is good for the applications to make use of the hardware compatibility. > > > > Signed-off-by: Haiyue Wang > > > I would say that it very bad for applications. It sounds like > reserved bits > in registers which have meaning in fact and sometimes different > meaning. > Of course, it is not that bad when rules are defined, but such kind of > features tend to spread and clutter up interfaces. IMHO, the > feature is > really frightening. >