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 8B03DA0471 for ; Fri, 21 Jun 2019 17:14:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 97F6E1D54F; Fri, 21 Jun 2019 17:14:11 +0200 (CEST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by dpdk.org (Postfix) with ESMTP id CFF571D4B0 for ; Fri, 21 Jun 2019 17:14:10 +0200 (CEST) Received: by mail-pg1-f181.google.com with SMTP id 196so3529145pgc.6 for ; Fri, 21 Jun 2019 08:14:10 -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=VkNAXf13Y88XzJGTorjoeZwshLvC+PwnQdgk0apr79s=; b=t0/GyyOyZQpvCWjHOZV82I6Y2OZLs7SsHskY8YFAFdPYc8vj6majVFOIXB0o/tntCJ Ocwk4QnKKSwoz3ZuX/1Bq+V+VdgkCFTu6Wv6xgoLRxoyGS+7XwbVKtOUKKq6VP/4fF9r ItVz22q4gmz00Qn6cOJCZQjS5izMNeWcBEYr6sHHLkFefuxdBlLgNutut2CNnV/tjLCt Z1AAfeIbKj4N51y4mWrKBhFbOY9kTomp2xwF+ytfxRgeC7mdIrP80/kUGFtlXEZ6uM2L 8eqHSSUtOsrC2xtZnYkud0bYyqmN1ttx+SovON0thD5EWDT7qFOiaERAIT9vIv9P+IEh K7yA== 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=VkNAXf13Y88XzJGTorjoeZwshLvC+PwnQdgk0apr79s=; b=he6O3V1SsTzXcFg99bJkbbiRDeX51ztqwOD9FhqhmhbdzvxEg/p6WrTmDZ3qlTswmz 53ajXdlJQtqW6vpkd9AL77a7Gvo7u2drc+NlWMniyRhF+MNiEFXE6Qjb+CIUfPSiKOtV UfxbBw+eNxiKjYOTIIy7HlZXIWKvQbZL/0URcmH556k6aBGBdPQaKEiVc6dnRsuyKeNa ocpG1HvAUm1Bvuy6XisLfARjmZdOzUMTi95fMMDarE745SkksFUuH/JOh4TKed13ruG+ VGJmtQRzHPrEbr3HEZNCesLFercIlsDYj13juCNdoBoh/woEcKat5hAQA7E4NQ6R47zZ tpVA== X-Gm-Message-State: APjAAAU87l2jxuzy345CAJKpv1LogJ7CqvW9bOA398odFoIqVOaHZPa+ KLMrkkHfkUJyjxk1hRZE1+s9bw== X-Google-Smtp-Source: APXvYqx4bIWp3tYmkZCtg2wJHi+ppgC0DNVxYIaZayu2A7ZAlCoHhWE3k5NUlIyA+RYYCTXaovT4nQ== X-Received: by 2002:a17:90a:2706:: with SMTP id o6mr7501997pje.62.1561130049995; Fri, 21 Jun 2019 08:14:09 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id i8sm992164pjk.12.2019.06.21.08.14.09 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 21 Jun 2019 08:14:09 -0700 (PDT) Date: Fri, 21 Jun 2019 08:14:03 -0700 From: Stephen Hemminger To: "Wang, Haiyue" Cc: Andrew Rybchenko , "dev@dpdk.org" , "Yigit, Ferruh" , Thomas Monjalon Message-ID: <20190621081403.3f157667@hermes.lan> In-Reply-To: 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> <8751ae1d-a912-5716-59d4-3afbeb89a057@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Fri, 21 Jun 2019 07:43:13 +0000 "Wang, Haiyue" wrote: > I know my patch is ugly for making customers happy, I will try to find ot= her method not to > break the beautiful rte_ethdev desgin. >=20 > Really thanks for your reply. This helps me understand the PMD design pra= ctice more. >=20 > BR, > Haiyue >=20 > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com] > Sent: Friday, June 21, 2019 15:40 > To: Wang, Haiyue ; dev@dpdk.org > Cc: Yigit, Ferruh ; Thomas Monjalon > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-signifi= cant bits for PMD scartch >=20 > 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. =E2=98=BA >=20 > Yes, it is a bug. No one is perfect. >=20 >=20 >=20 > BR, > Haiyue >=20 > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com] > Sent: Friday, June 21, 2019 15:34 > To: Wang, Haiyue ; d= ev@dpdk.org > Cc: Yigit, Ferruh = ; Thomas Monjalon > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-signifi= cant bits for PMD scartch >=20 > On 6/21/19 4:12 AM, Wang, Haiyue wrote: > Not so frightening in real world for an application to be aware of its NI= Cs: > https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_ethd= ev.c#L387 >=20 >=20 >=20 >=20 > 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. >=20 >=20 >=20 >=20 >=20 > Yes, we need to avoid this kind of design. >=20 > BR, > Haiyue >=20 > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com] > Sent: Friday, June 21, 2019 02:30 > To: Wang, Haiyue ; d= ev@dpdk.org > Cc: Yigit, Ferruh = ; Thomas Monjalon > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-signifi= cant bits for PMD scartch >=20 > CC ethdev maintainers >=20 > On 6/20/19 10:25 AM, Haiyue Wang wrote: >=20 > Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities >=20 > of a device is one-bit field definition, it has 64 different values at >=20 > most. >=20 >=20 >=20 > Nowdays the receiving queue of NIC has rich features not just checksum >=20 > offload, like it can extract the network protocol header fields to its >=20 > RX descriptors for quickly handling. But this kind of feature is not so >=20 > common, and it is hardware related. Normally, this can be done through >=20 > rte_devargs driver parameters, but the scope is per device. This is not >=20 > so nice for per queue design. >=20 >=20 >=20 > The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct >=20 > rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping >=20 > the ethdev API & ABI compatibility, and the application can make good >=20 > use of the NIC's specific features, reserving the most-significant bits >=20 > of RX offload seems an compromise method. >=20 >=20 >=20 > Then the PMDs redefine these bits as they want, all PMDs share the same >=20 > bit positions and expose their new definitions with the header file. >=20 >=20 >=20 > The experimental reserved bits number is 6 currently. Tt can be one-bit >=20 > for each features up to the the maximum number 6. It can also be some >=20 > bits encoding: e.g, 6 bits can stand for 63 maximum number of features. >=20 >=20 >=20 > We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left >=20 > unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) =3D >=20 > 39. >=20 >=20 >=20 > This is not so nice for applications, they need to check PMD's driver >=20 > name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it >=20 > is good for the applications to make use of the hardware compatibility. >=20 >=20 >=20 > Signed-off-by: Haiyue Wang >=20 > I would say that it very bad for applications. It sounds like reserved bi= ts > 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. There are two issues. First, having more OFFLOAD capability feature bits is good. As long as these feature bits are well defined. If only one vendor implements that feature that is fine. Another vendor can implement the same thing, and application can know what it is asking for. The other issue is the limited number of feature bits. I expect that some time soon the bits will have to grow into an array and cause API/ABI break. That can be fixed when the last bit is exhausted.