Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

On Mon, Apr 16, 2018 at 03:27:37PM +0000, Xueming(Steven) Li wrote:
> 
> 
> > -----Original Message-----
> > From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Sent: Monday, April 16, 2018 9:48 PM
> > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > Cc: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>; Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org;
> > Olivier Matz <olivier.matz@6wind.com>
> > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification
> > 
> > On Mon, Apr 16, 2018 at 01:32:49PM +0000, Xueming(Steven) Li wrote:
> > >
> > > > -----Original Message-----
> > > > From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > > > Sent: Monday, April 16, 2018 5:28 PM
> > > > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > > > Cc: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>; Shahaf Shuler
> > > > <shahafs@mellanox.com>; dev@dpdk.org; Olivier Matz
> > > > <olivier.matz@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@6wind.com>
> > > > > > Sent: Monday, April 16, 2018 3:29 PM
> > > > > > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > > > > > Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org; Olivier
> > > > > > Matz <olivier.matz@6wind.com>; Adrien Mazarguil
> > > > > > <adrien.mazarguil@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@6wind.com>
> > > > > > > > Sent: Friday, April 13, 2018 9:03 PM
> > > > > > > > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > > > > > > > Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org;
> > > > > > > > Olivier Matz <olivier.matz@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.
> > 
> > I mean the value already exists, it's implicitly 0. Adding one with the same value as
> > RTE_PTYPE_TUNNEL_MASK could be seen as a waste of a value otherwise usable for an actual tunnel type
> > (there are only 4 bits).
> > 
> > > > 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.
> > 
> > Keep in mind that mbuf packet types report what is identified. All the definitions in this file name a
> > specific protocol. For instance there is no such definition as "L3 present" or "L4 present". "Tunnel
> > present" doesn't make a lot of sense on its own either.
> > 
> > Don't you agree that reporting at least one inner ptype while leaving tunnel ptype to 0 automatically
> > addresses this issue?
> 
> Currently, no inner L2 ptype, so for packet with only L2, it will be recognized as non-tunnel packet.

Applications can live with it. Don't bother with a ptype API change at this
point, it raises more issues than it solves.

Given the size of the series, let's deal with that later through a separate
task and according to user feedback.

-- 
Adrien Mazarguil
6WIND