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 EFAC8A0471 for ; Fri, 21 Jun 2019 18:45:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5DE051D556; Fri, 21 Jun 2019 18:45:57 +0200 (CEST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by dpdk.org (Postfix) with ESMTP id 57D141D54F for ; Fri, 21 Jun 2019 18:45:55 +0200 (CEST) Received: by mail-vs1-f52.google.com with SMTP id a186so4257498vsd.7 for ; Fri, 21 Jun 2019 09:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3wacABEhktbzZuHwpqsasENgC2YSJtwjVl0HgtUMHsA=; b=eRo7Zg1NvfR8YGhbwc/5wdEOhEALxoTLLmTQirf4JDQDIj6ectGf7q2osnfxSwN+cb UCKQbu0RkGOqpbnQMdC5ZbK8FSpRd7FAQf/JJAajz7vxqjOJ9hJUbdD1wNcSXenUC61t VT+XczWA28Jdp8cPNHRSNZY6vXzG1QwaUJPnrpgh6J3OoOxymXiTf3J3SejBu03iiVV2 CWDU+wi/PA6zXqzwpb7KTNy/chHpqorXA7TFfG8ow8KmqQmnFs0w9RvvIdHKBqpkTSQT MJ7KZ5vLizxDnQi0rL5O7ID7nU57jIWR9hxNsRaLfviBJKqcwRce8lpO18+mK05WCxKx mKNA== X-Gm-Message-State: APjAAAXeRYkr0iRavisaKIMwTRD9dz3Y49gpAuVtXQrDKno46TBZ6iFa orEveC7OlFJv+VZtvVhi0B0NP2420arDcCR35wHmmA== X-Google-Smtp-Source: APXvYqwifpqPS9r8OpLnOmXORSvlP/BkogS+/o/CPsefgBe+BcUnTbjg2Jt1WWeYBuQX8U0sZ0+s0T2QGoQM5qHQBVU= X-Received: by 2002:a67:da99:: with SMTP id w25mr18226066vsj.141.1561135554685; Fri, 21 Jun 2019 09:45:54 -0700 (PDT) MIME-Version: 1.0 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> <20190621081403.3f157667@hermes.lan> In-Reply-To: From: David Marchand Date: Fri, 21 Jun 2019 18:45:43 +0200 Message-ID: To: "Wang, Haiyue" Cc: Stephen Hemminger , Andrew Rybchenko , "dev@dpdk.org" , "Yigit, Ferruh" , Thomas Monjalon Content-Type: text/plain; charset="UTF-8" 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 Fri, Jun 21, 2019 at 6:37 PM Wang, Haiyue wrote: > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Friday, June 21, 2019 23:14 > > To: Wang, Haiyue > > Cc: Andrew Rybchenko ; dev@dpdk.org; Yigit, > Ferruh ; > > Thomas Monjalon > > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload > most-significant bits for PMD scartch > > > > On Fri, 21 Jun 2019 07:43:13 +0000 > > "Wang, Haiyue" wrote: > > > > > 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 haiyue.wang@intel.com> > > > > > > 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. > > > > 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. > > > > > > If one bit for one feature, then it will be exhausted soon. That's why I > said > using DEV_RX_OFFLOAD_PMD_SCRATCH bits to *encode* the PMD's offload if it > is no > so common now, such as 6 bits will give the vendor 63 different types to > select > their own features. And have 39 for common features defined in the future. > > Frankly speaking, if we open some bits for PMD using, like the > __rte_experimental > API style, then PMD will have more rich feature for open, customer can use > the > experimental features, and these experimental features may be common in > some day. > Just try to imagine what it would mean for the dataplane handling a packet: if (is_port_vendor_X(portid)) { handle_exotic_vendor_X(); } else if (is_port_vendor_Y(portid)) { handle_exotic_vendor_Y(); } else { generic_handle(); } Add to this changes with versions of dpdk since this would be out of the ABI/API stability and this is a huge mess. This is a NAK for me. -- David Marchand