[dpdk-dev] [RFC] New packet type query API

[Yang, Qiming]

> -----Original Message-----
> From: Shahaf Shuler [mailto:shahafs at mellanox.com]
> Sent: Wednesday, January 17, 2018 10:34 PM
> To: Andrew Rybchenko <arybchenko at solarflare.com>; Adrien Mazarguil
> <adrien.mazarguil at 6wind.com>; Yang, Qiming <qiming.yang at intel.com>
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [RFC] New packet type query API
> 
> Wednesday, January 17, 2018 10:09 AM, Andrew RybchenkoL
> > On 01/16/2018 06:55 PM, Adrien Mazarguil wrote:
> > > I understand the motivation behind this proposal, however since new
> > > ideas must be challenged, I have a few comments:
> > >
> > > - How about making packet type recognition an optional offload
> > configurable
> > >    per queue like any other (e.g. DEV_RX_OFFLOAD_PTYPE)? That way
> > > the
> > extra
> > >    processing cost could be avoided for applications that do not care.
> > >
> > > - Depending on HW, packet type information inside RX descriptors may not
> > >    necessarily fit 64-bit, or at least not without transformation. This
> > >    transformation would still cause wasted cycles on the PMD side.
> > >
> > > - In case enable_ptype_direct is enabled, the PMD may not waste CPU
> > cycles
> > >    but the subsequent look-up with the proposed API would translate to a
> > >    higher cost on the application side. As a data plane API, how does this
> > >    benefit applications that want to retrieve packet type information?
> > >
> > > - Without a dedicated mbuf flag, an application cannot tell whether
> > enclosed
> > >    packet type data is in HW format. Even if present, if port information is
> > >    discarded or becomes invalid (e.g. mbuf stored in an application
> > > queue
> > for
> > >    lengthy periods or passed as is to an unrelated application), there is no
> > >    way to make sense of the data.
> > >
> > > In my opinion, mbufs should only contain data fields in a
> > > standardized format. Managing packet types like an offload which can
> > > be toggled at will seems to be the best compromise. Thoughts?
> >
> > +1
> 
> Yes.
> PTYPE is yet another offload the PMD provides. It should be enabled/disabled in
> the same way all other offloads are.
> Application who are not interested with it, and wants the extra performance
> should not enable it.

Agreed, thank you for your advice, and comments in Adrien's email.