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.
