Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote:
>
>> -----Original Message-----
>> From: Hemant Agrawal <hemant.agrawal@nxp.com>
>> Sent: Tuesday, August 6, 2019 1:49 PM
>> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
>> Jacob Kollanukkaran <jerinj@marvell.com>
>> Cc: dev@dpdk.org
>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>>> Add PTYPE to DEV_RX_OFFLOAD_* flags.
>>>
>>> Currently, most of the NICs already support PTYPE parsing and update
>> the
>>> mbuf->packet_type through an internal lookup table, but there is no
>> way to
>>> disable the lookup if the application is not intrested in ptypes
>> returned by
>>> `rte_eth_dev_get_supported_ptypes`.
>>>
>> [Hemant]  it will also mean introducing another check in datapath, if the
>> application has asked for PTYPE offload - copy the results to mbuf-
>>> packet_type otherwise don't do it.
> I think that having the check would give better performance than loading ptype table to L1
> doing  a lookup and copying it to mbuf when the application doesn't need it.

Anyway, if PMD decides that it is better to always provide packet type
information - there is no harm. Basically if the offload is not requested
it makes packet_type undefined in mbuf.

>> Your second patch is incomplete in the sense that it only adds the
>> capability. But it does not disable the lookups?
> It is upto the maintainer of the PMD to disable the lookup in data path. If there is a scope of optimization
> then they could do it. There is no harm in exposing  PTYPE even RX_OFFLOAD_PTYPE is not enabled.
> I was hesitant to touch data path as it would be impossible to verify performance effect on all NICs.

I think it is the right way to approach it especially taking transition 
into account.