[RFC,0/3] ethdev: add ptype as Rx offload

  From: Pavan Nikhilesh <pbhagavatula@marvell.com>

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`.

Pavan Nikhilesh (3):
  ethdev: add ptype as an Rx offload
  net: update Rx offload capabilities
  examples: add Rx ptype offload

 doc/guides/nics/features.rst                    |  3 +++
 drivers/net/atlantic/atl_ethdev.c               |  3 ++-
 drivers/net/bnxt/bnxt_ethdev.c                  |  3 ++-
 drivers/net/cxgbe/cxgbe.h                       |  3 ++-
 drivers/net/dpaa/dpaa_ethdev.c                  |  3 ++-
 drivers/net/dpaa2/dpaa2_ethdev.c                |  3 ++-
 drivers/net/e1000/em_rxtx.c                     |  3 ++-
 drivers/net/e1000/igb_rxtx.c                    |  3 ++-
 drivers/net/enetc/enetc_ethdev.c                |  3 ++-
 drivers/net/enic/enic_res.c                     |  3 ++-
 drivers/net/failsafe/failsafe_ops.c             |  6 ++++--
 drivers/net/fm10k/fm10k_ethdev.c                | 15 ++++++++-------
 drivers/net/i40e/i40e_ethdev.c                  |  3 ++-
 drivers/net/iavf/iavf_ethdev.c                  |  3 ++-
 drivers/net/ice/ice_ethdev.c                    |  3 ++-
 drivers/net/ixgbe/ixgbe_rxtx.c                  |  3 ++-
 drivers/net/mlx4/mlx4_rxq.c                     |  3 ++-
 drivers/net/mlx5/mlx5_rxq.c                     |  3 ++-
 drivers/net/mvneta/mvneta_ethdev.h              |  3 ++-
 drivers/net/mvpp2/mrvl_ethdev.c                 |  3 ++-
 drivers/net/netvsc/hn_rndis.c                   |  3 ++-
 drivers/net/nfp/nfp_net.c                       |  3 ++-
 drivers/net/octeontx/octeontx_ethdev.h          |  3 ++-
 drivers/net/octeontx2/otx2_ethdev.c             |  5 +++++
 drivers/net/octeontx2/otx2_ethdev.h             | 15 ++++++++-------
 drivers/net/qede/qede_ethdev.c                  |  3 ++-
 drivers/net/tap/rte_eth_tap.c                   |  3 ++-
 drivers/net/thunderx/nicvf_ethdev.h             |  3 ++-
 drivers/net/vmxnet3/vmxnet3_ethdev.c            |  3 ++-
 examples/ip_fragmentation/main.c                |  7 +++++++
 examples/l3fwd-power/main.c                     |  8 ++++++++
 examples/l3fwd/main.c                           |  9 +++++++++
 examples/performance-thread/l3fwd-thread/main.c |  9 +++++++++
 examples/tep_termination/vxlan_setup.c          |  1 +
 lib/librte_ethdev/rte_ethdev.h                  |  1 +
 35 files changed, 111 insertions(+), 40 deletions(-)

--
2.17.1
  

> 
> 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. 

Your second patch is incomplete in the sense that it only adds the capability. But it does not disable the lookups?
  

>-----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.

>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.
  

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.
  

On Tue, 6 Aug 2019 12:06:35 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:

> 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.
> 

With hardline API policy, this has to fail on compile for old applications.
You can't magically assume that applications using ptype will set new feature.