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

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 6 Aug 2019 14:31:43 +0000
Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com> wrote:

> >-----Original Message-----
> >From: Andrew Rybchenko <arybchenko@solarflare.com>
> >Sent: Tuesday, August 6, 2019 2:30 PM
> >To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
> >Jacob Kollanukkaran <jerinj@marvell.com>; John McNamara
> ><john.mcnamara@intel.com>; Marko Kovacevic
> ><marko.kovacevic@intel.com>; Thomas Monjalon
> ><thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@intel.com>
> >Cc: dev@dpdk.org
> >Subject: [EXT] Re: [dpdk-dev] [RFC 1/3] ethdev: add ptype as an Rx
> >offload
> >
> >External Email
> >
> >----------------------------------------------------------------------
> >On 8/6/19 11:02 AM, pbhagavatula@marvell.com wrote:  
> >> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>
> >> Add ptype to DEV_RX_OFFLOAD_* flags which can be used to  
> >enable/disable  
> >> packet type parsing.
> >>
> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>  
> >
> >I like the idea. I think there are few more Rx features which
> >lack Rx offload bit:
> >  - delivery of RSS hash in mbuf (it is not always required when
> >    RSS is used to distribute packets across Rx queues)  
> 
> Especially when applications use custom hash functions to store flows.
> 
> >  - maybe Rx mark, since it is an extra information which could
> >    be passed by NIC to CPU and it is better to know in advance
> >    at Rx queue setup if it should be requested and processed  
> 
> Are you referring to RTE_FLOW_ACTION_TYPE_MARK?
> 
> >
> >API breakage should be considered here. I think it is OK to
> >introduce it in the next release cycle in a dummy way which
> >does not affect packet type delivery for existing PMDs
> >(i.e. add offload capability and advertise in PMD, but do not
> >take it into account when Rx mbuf is filled in) and
> >submit deprecation notice that it may be taken into account
> >by PMDs in 20.02 to avoid packet type delivery if the offload
> >is not requested. It will allow applications to make transition
> >smoother.  
> 
> Couldn’t agree with you more. I could extend the current RFC to include 
> RSS and RX mark as we would be modifying the same offload fields across 
> all drivers. Easier for PMD maintainers too.
> 
> >
> >Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>  
> 

I would rather the ptype offload be always on and handled in software
for drivers that don't do it.