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 C2DE5A0471 for ; Thu, 20 Jun 2019 20:35:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 29DD11D44C; Thu, 20 Jun 2019 20:35:47 +0200 (CEST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by dpdk.org (Postfix) with ESMTP id 133C11D44B for ; Thu, 20 Jun 2019 20:35:45 +0200 (CEST) Received: by mail-pg1-f170.google.com with SMTP id 145so2021461pgh.4 for ; Thu, 20 Jun 2019 11:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SeczkQ/+bTFItAUky4Sk999BYg1zpgHcp+t2E9gyx7U=; b=jiDYhiFoRnoInls/qG2fW8mx0hRJNLgGriLhfjJNeHZMK/44ENSDzTKtW92A1X8f9K 6s83CGMmkPOavW7pebhGjLPqo+3Tf6P/mjGc3T1EcLn2g4EKjZoQN0S0tYpkqqfT8i5a Pj5OASFINUywvSl+3iWldz5HZAOUaDgoYECYDcrEeHi1whz0o9c9mh4BAg/fUPBXMtSt Bd2Tgh8sN7ovGhAPFPTUfF675wywhrhzsUJNY57zxSZAl6KVawMRtrhzZ+vGKlN6Yjoz 20wyCBLkZYsaJPxRXSOTatLccRpl1bLggTRTNI8oMz9sGavEeXqGSxEeMtz1vL0hDDB3 g8Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SeczkQ/+bTFItAUky4Sk999BYg1zpgHcp+t2E9gyx7U=; b=Qu/f5gxah6uLRRjhWJr23s72iY/ajBaAeMy+1odVRv0fEaqcCXU0q6QkbHvHDLGC2I 2JOyDq675VqaOeW/3MIgUlqvi6RrRamhDK9bko04itUoFj6qPh2CpqaP+ihRMz2b7vmz KjPaTSWfkDFNlkoJwUAxIT0KrCtcIG74af6/GjHR/n59oUYSpvco5zxpPn8X8aNdLXq8 g35ZRdEhtskdUv4e84LPddWoiTnuedbVlCkr4h1TmQlrbVo466kg/BHuT0shOOp+TjV5 XE/0Uybcu4a5NjMacUTvvhWLMvei7Bj2z6zNrb59NMRHlZV3DfJIYFPJfjVzmG870nRz ayBA== X-Gm-Message-State: APjAAAVDolL7Xw/F4wvEcYWPixLzV3WM46N1KlGlTXWueIvhAd1QkGUz Dq6+LFCgox6TMX2BgF4v7+3BBA== X-Google-Smtp-Source: APXvYqxNebPbUpdsN3lgcmM20HDdIFKVPfsosBGCaL4rdyusbDZUaudV3qd51fkbHo7Xwm/EhU43OQ== X-Received: by 2002:a17:90a:8d86:: with SMTP id d6mr991606pjo.127.1561055744139; Thu, 20 Jun 2019 11:35:44 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id g17sm198453pfb.56.2019.06.20.11.35.43 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 20 Jun 2019 11:35:43 -0700 (PDT) Date: Thu, 20 Jun 2019 11:35:37 -0700 From: Stephen Hemminger To: Haiyue Wang Cc: dev@dpdk.org Message-ID: <20190620113537.60f091fd@hermes.lan> In-Reply-To: <1561015552-37671-1-git-send-email-haiyue.wang@intel.com> References: <1561015552-37671-1-git-send-email-haiyue.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Thu, 20 Jun 2019 15:25:52 +0800 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 > --- Anything that is per device type is useless for a generic application. The goal of the DPDK should be to provide a high performance platform that works for many device types. Too often, I see patches from hardware vendors that are just "we can enable are cool proprietary hardware feature in DPDK". This would just encourage that bad practice.