2015-07-16 00:36, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2015-07-15 23:57, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > A packet is tunnelled if the tunnel type is identified or if it has an > > > > inner part. > > > > > > > > Fix also a typo in RTE_PTYPE_INNER_L3_MASK. > > > > > > > > Fixes: f295a00a2b44 ("mbuf: add definitions of unified packet > > > > types") > > > > > > > > Signed-off-by: Thomas Monjalon <thomas.monjalon at 6wind.com> > > |...] > > > > /* Check if it is a tunneling packet */ -#define > > > > RTE_ETH_IS_TUNNEL_PKT(ptype) ((ptype) & RTE_PTYPE_TUNNEL_MASK) > > > > +#define RTE_ETH_IS_TUNNEL_PKT(ptype) ((ptype) & > > > > +(RTE_PTYPE_TUNNEL_MASK | \ RTE_PTYPE_INNER_L2_MASK | \ > > > > +RTE_PTYPE_INNER_L3_MASK | \ > > > > + RTE_PTYPE_INNER_L4_MASK)) > > > > > > Could you help to explain more of why here? > > > My understanding is that if an inner one can be recognized, there must be > > > a > > tunnel type there. > > > > Not always. > > It was my comment in mlx4 patch: > > http://dpdk.org/ml/archives/dev/2015-July/021702.html > > Currently we can know that mlx4 has detected a tunnel but don't know which > > one. > > I'd suggest to do more in mlx4 driver, rather than adding more checks in this > macro. > If it can detect the inner l2/l3 type, the driver should tell it is a > tunneled packet. > If it cannot know which tunnel it is, I'd suggest to add one more tunnel type > of > RTE_PTYPE_TUNNEL_UNKNOWN. > Two reasons: > - PMD should tell enough info to high level caller or application. It should > be clear enough.
RTE_PTYPE_TUNNEL_UNKNOWN doesn't make it clearer, IMHO. > - Adding more checks in those macro results in more cpu cycles for other NICs > to check > the packet types. Not sure. It only extends the mask to check. It shouldn't add more cpu cycle.
