Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch

[David Marchand <david.marchand@redhat.com>]

On Fri, Jun 21, 2019 at 6:37 PM Wang, Haiyue <haiyue.wang@intel.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Friday, June 21, 2019 23:14
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: Andrew Rybchenko <arybchenko@solarflare.com>; dev@dpdk.org; Yigit,
> Ferruh <ferruh.yigit@intel.com>;
> > Thomas Monjalon <thomas@monjalon.net>
> > 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" <haiyue.wang@intel.com> 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><mailto:
> 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