Answered in adrien’s email. From: Andrew Rybchenko [mailto:arybche...@solarflare.com] Sent: Wednesday, January 17, 2018 4:09 PM To: Adrien Mazarguil <adrien.mazarg...@6wind.com>; Yang, Qiming <qiming.y...@intel.com> Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC] New packet type query API
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
