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 44C36A0471 for ; Thu, 20 Jun 2019 20:30:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9807C1D439; Thu, 20 Jun 2019 20:30:22 +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 771761D438 for ; Thu, 20 Jun 2019 20:30:21 +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-us5.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 02DB74C0059; Thu, 20 Jun 2019 18:30:19 +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; Thu, 20 Jun 2019 19:30:14 +0100 To: Haiyue Wang , References: <1561015552-37671-1-git-send-email-haiyue.wang@intel.com> From: Andrew Rybchenko CC: Ferruh Yigit , Thomas Monjalon Message-ID: <41d93d60-9097-48a4-6a26-8ebd0cfb4b39@solarflare.com> Date: Thu, 20 Jun 2019 21:30:10 +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: <1561015552-37671-1-git-send-email-haiyue.wang@intel.com> 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-24696.000 X-TM-AS-Result: No-13.462000-8.000000-10 X-TMASE-MatchedRID: ZFzIhWOuIzv4ECMHJTM/uY0SKX5sgI0F69aS+7/zbj80C8Dp8kkTtb5B EqXwSs2UbMNF9ka96Eg65qmz7y79BjD34XFwewe1MiMrbc70PfdxR6rIK7qIWfizcX4KtjQM35d D76rzBfdZrGQ1jqR3UVTtHa1dS0Hz+TGxWusieHL9xyC38S1f/TRsz6Azwf9SFnnQqxB12pf3pt /9B8TsvSxV8Fx/RnbPWHzZlpF+TzfAtZqrc7EMtmXaK3KHx/xpKWPnYJ5Ay2pOz8YOQHnBeWhkS wpykoqVG0YQuYSMuIgq6ulNfuwaN7l7A3O5D6aXHC7hAz/oKnJGI9Mwxz8yaXu4ox6u4PaGsx8U MJr4pndHy0Th+g/RGVD9ZzYLb2ZtmepGnJ5Ug+HwpAypldoLOQZyESFXAljffZ+tCoJPXE3zTu3 5URal5omZnwWWIBq/N862GpoHoW4sMLcUZMcjd2hQCsqhuTNiFW7LlhOHf7fDv5dDcuT2eVUu4d MbNIOZnvrQcNHM8ndZViwzOS9q6HZH581LXAeZnTqdU4w65WkcDDLReGt4PfmUDxpFogQXo8WMk QWv6iUD0yuKrQIMCAGLeSok4rrZec3QM3secWbQ6iZeBF944ExxPMlgncgylH5hjQ+IApnooOWf U+caS3JS77Heh6TOrFBigA68Ci9Hiy922qzzlRFhfsZDWZlJgSBR6uO578N+3BndfXUhXQ== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.462000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24696.000 X-MDID: 1561055420-Axessexo__Ca 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" 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.