> -----Original Message----- > From: Adrien Mazarguil <adrien.mazarg...@6wind.com> > Sent: Monday, April 16, 2018 5:28 PM > To: Xueming(Steven) Li <xuemi...@mellanox.com> > Cc: Nélio Laranjeiro <nelio.laranje...@6wind.com>; Shahaf Shuler > <shah...@mellanox.com>; dev@dpdk.org; > Olivier Matz <olivier.m...@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.laranje...@6wind.com> > > > Sent: Monday, April 16, 2018 3:29 PM > > > To: Xueming(Steven) Li <xuemi...@mellanox.com> > > > Cc: Shahaf Shuler <shah...@mellanox.com>; dev@dpdk.org; Olivier Matz > > > <olivier.m...@6wind.com>; Adrien Mazarguil > > > <adrien.mazarg...@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.laranje...@6wind.com> > > > > > Sent: Friday, April 13, 2018 9:03 PM > > > > > To: Xueming(Steven) Li <xuemi...@mellanox.com> > > > > > Cc: Shahaf Shuler <shah...@mellanox.com>; dev@dpdk.org; Olivier > > > > > Matz <olivier.m...@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
