Re: [RFC] New packet type query API

[Andrew Rybchenko <arybchenko@solarflare.com>]

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