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 83012A0471 for ; Fri, 21 Jun 2019 09:34:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 531511D53D; Fri, 21 Jun 2019 09:34:09 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 2201D1D539 for ; Fri, 21 Jun 2019 09:34: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-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id A28DC100079; Fri, 21 Jun 2019 07:34: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:33:59 +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> From: Andrew Rybchenko Message-ID: <3500154e-74e5-d4f7-6606-ad1fea300f0e@solarflare.com> Date: Fri, 21 Jun 2019 10:33:55 +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.614100-8.000000-10 X-TMASE-MatchedRID: TxtdI7DxMqoQo9nihO6svo+jnIR/zCDxQtntDL6PCaihGGri4vovWPHk pkyUphL9+x2wjX2uD+gR34ro7k23ndXXTaumdzZnIgLJkPcdn3I/eSO9VD0pDrT0jVEXWzBwJEF MYGmfGMc5iooXtStiHtDxDdXabYEQRr7gV267sGLBzxrXE/7X6L1dDbimwU7m8oWuLhK0Tf3OdA xriBMZPUqAhuLHn5fEl23GX7Au7dTGXu5QNPXrbnfZv4XeDjIYL7ClGYGIt7ldPa2QGGaXztUcS ZdVkdtzsyIH/9rq5xaynk7TnYzMuqHDMThyZnbzr8+IB7pb9CDHvq2Bdba2gN831hseXGPhWHGJ Y8KbuMRMQIu8ZJ3FKucJOFqc/+CEXa9+3ZJzfMK649DRgh7feUMe6XhX1PXhgUs6XLP3taFStWL DoBpPUY8ZcR5uOw868CWGWvy/Nx31WUYGMIOdyNEqxAMPnMdOy/DEtyo6oUr7zwy3HB5+4jjO57 N1IAWNBGvINcfHqhd+lv4iHMG8GbbE3ByWTBPiM09jtX62KLPhhLoXIby/KBWVVkGuW6JrIj0zF I5DoJKCQxfA+iO7F6zG9MIKeG/Ghf3lQuFtLYCbuQcHZubU2u3OpvA0OqzctAnihQXnq+iBFNZJ /RfzGY7P8sslRxoeyaqtcUsWOxbppfxNgiuPW6QIIX0yMgHykUz3rsvl+Dd5ZRJeWUSRoamGTQy tjAwlqAn+yHbzwCdxQ4FG27mw25XeCA0YmI86ErSm9YbglBG97bcj1t+gHq3czi5f92v9nTqdU4 w65WkcDDLReGt4PfmUDxpFogQXo8WMkQWv6iUD0yuKrQIMCIGsNX5eg/aORjjVhf+j/wqDRoEYW s0DPasQd9qPXhnJQCuHxX1Ib2w/KhXLnY6/xGHzmOvYersTC6uhnN8b/TFwGorg64eHOAYkIXou i5NZt+5T34BSOlkf3XPB6F38E8gBQr/U+oDygp9G0U9k6qE= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.614100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24700.000 X-MDID: 1561102446-i53-2KMZgvZq 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 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. >