From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id E98F66A87 for ; Thu, 16 Jul 2015 11:08:26 +0200 (CEST) Received: by wgxm20 with SMTP id m20so53006397wgx.3 for ; Thu, 16 Jul 2015 02:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=0uF6THJk4hKfwuWfqMmC86XSegeeoJ+M8kWhuBt1sK8=; b=A/WXZlQBnfk/frAwG+x5Ej+DFJ1RDKOYqvi0lCVfzz2KnPHxwf2ggKGbwmx0Z4dR3d NCs1MtaTNTuGn9AoIc53PH42tVCawZTJJR1Av2JoNwF2Il5g4SuNgLgpieU1m46HfiBp s3SbK4hOunZT9l2fVSOddG7w9vr1pdUvas5BqTzk3RW8K/GfbkbdKKBWV5ItTH4WDelw wz5ZCsDYCDr7kiNl3jAZjYQYkN3c0XFntPyBGusUhqIskA077kE9DHdTonyzV2CuO2JM y8lJQyw+SZMHT7oGYKl8E8JtAcdGzp+4SpC9eDKGR16slfPrqGm7tC3fqGvyY9XK3JP4 y2Kw== X-Gm-Message-State: ALoCoQnEROh/KsPVXTj6s51oTx0r8F9uH391x3GO2T9r23opBvgf8hUUhGZobMlB0Ose2q6NTruD X-Received: by 10.180.215.101 with SMTP id oh5mr4849090wic.6.1437037706783; Thu, 16 Jul 2015 02:08:26 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.151.210]) by smtp.gmail.com with ESMTPSA id lv8sm11882209wjb.41.2015.07.16.02.08.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 02:08:25 -0700 (PDT) From: Thomas Monjalon To: "Zhang, Helin" Date: Thu, 16 Jul 2015 11:07:15 +0200 Message-ID: <7940373.JSzZk48P3I@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: <1437004212-31646-1-git-send-email-thomas.monjalon@6wind.com> <28177519.UZIomONHXn@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mbuf: fix tunnel flags check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 09:08:27 -0000 2015-07-16 00:36, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2015-07-15 23:57, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon@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 > > |...] > > > > /* 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.