[dpdk-dev] [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification

[Xueming(Steven) Li]

> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil at 6wind.com>
> Sent: Monday, April 16, 2018 5:28 PM
> To: Xueming(Steven) Li <xuemingl at mellanox.com>
> Cc: Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>; Shahaf Shuler <shahafs at mellanox.com>; dev at dpdk.org;
> Olivier Matz <olivier.matz at 6wind.com>
> Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification
> 
> On Mon, Apr 16, 2018 at 08:05:13AM +0000, Xueming(Steven) Li wrote:
> >
> >
> > > -----Original Message-----
> > > From: Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>
> > > Sent: Monday, April 16, 2018 3:29 PM
> > > To: Xueming(Steven) Li <xuemingl at mellanox.com>
> > > Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at dpdk.org; Olivier Matz
> > > <olivier.matz at 6wind.com>; Adrien Mazarguil
> > > <adrien.mazarguil at 6wind.com>
> > > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type
> > > identification
> > >
> > > On Sat, Apr 14, 2018 at 12:57:58PM +0000, Xueming(Steven) Li wrote:
> > > > +Adrien
> > > >
> > > > > -----Original Message-----
> > > > > From: Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>
> > > > > Sent: Friday, April 13, 2018 9:03 PM
> > > > > To: Xueming(Steven) Li <xuemingl at mellanox.com>
> > > > > Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at dpdk.org; Olivier
> > > > > Matz <olivier.matz at 6wind.com>
> > > > > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type
> > > > > identification
> > > > >
> > > > > +Olivier,
> > > > >
> > > > > On Fri, Apr 13, 2018 at 07:20:13PM +0800, Xueming Li wrote:
> > > > > > This patch introduced tunnel type identification based on flow rules.
> > > > > > If flows of multiple tunnel types built on same queue,
> > > > > > RTE_PTYPE_TUNNEL_MASK will be returned, user application could
> > > > > > use bits in flow mark as tunnel type identifier.
> > > > >
> > > > > For an application it will mean the packet embed all tunnel
> > > > > types defined in DPDK, to make such thing you need a
> > > > > RTE_PTYPE_TUNNEL_UNKNOWN which does not exists currently.
> > > >
> > > > There was a RTE_PTYPE_TUNNEL_UNKNOWN definition, but removed due
> > > > to
> > > discussion.
> > > > So I think it good to add it in the patchset of reviewed by Adrien.
> > >
> > > Agreed,
> > >
> > > >
> > > > > Even with it, the application still needs to parse the packet to
> > > > > discover which tunnel the packet embed, is there any benefit
> > > > > having such bit?  Not so sure.
> > > >
> > > > With a tunnel flag, checksum status represent inner checksum.
> > >
> > > Not sure this is generic enough, MLX5 behaves as this, but how
> > > behaves other NICs?  It should have specific bits for inner checksum
> > > if all NIC don't have the same behavior.
> >
> > From my understanding, if outer checksum invalid, the packet can't be
> > received as a tunneled packet, but a normal packet, thus checksum
> > flags always result of inner for a valid tunneled packet.
> 
> Yes, since checksum validation information covers all layers at once (outermost to the innermost
> recognized), the presence of an "unknown tunnel"
> bit implicitly means outer headers are OK.
> 
> Now regarding the addition of RTE_PTYPE_TUNNEL_UNKNOWN, the main issue I see is that it's implicit, as
> in getting 0 after and'ing packet types with RTE_PTYPE_TUNNEL_MASK means either not present or unknown
> type.

How about define RTE_PTYPE_TUNNEL_UNKNOWN same ask RTE_PTYPE_TUNNEL_MASK? And'ding packet types always 
return a non-zero value.

> 
> How about not setting any tunnel bit and let applications rely on the presence of RTE_PTYPE_INNER_* to
> determine that there is a tunnel of unknown type? The rationale being that a tunneled packet without
> an inner payload is kind of pointless anyway.

An unknown type doesn't break anything, neither enum bits, straightforward IMHO.

> 
> > > > Setting flow mark for different flow type could save time of
> > > > parsing
> > > tunnel.
> > >
> > > Thanks,
> > >
> > > --
> > > Nélio Laranjeiro
> > > 6WIND
> 
> --
> Adrien Mazarguil
> 6WIND