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

[Adrien Mazarguil]

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

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

-- 
Adrien Mazarguil
6WIND