From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3C1AC48BE3 for ; Fri, 21 Jun 2019 11:10:36 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 3CF5421530 for ; Fri, 21 Jun 2019 11:10:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CF5421530 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4DEC81D5A4; Fri, 21 Jun 2019 13:10:35 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 603CF1D580 for ; Fri, 21 Jun 2019 13:10:34 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 04:10:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,400,1557212400"; d="scan'208";a="182072973" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga001.fm.intel.com with ESMTP; 21 Jun 2019 04:10:31 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.143]) by IRSMSX102.ger.corp.intel.com ([169.254.2.159]) with mapi id 14.03.0439.000; Fri, 21 Jun 2019 12:10:30 +0100 From: "Ananyev, Konstantin" To: Ivan Malov , Olivier Matz CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] mbuf: outer offsets must be zero for non-tunnel packets Thread-Index: AQHVKBzzceaA6qfdg0KXZZZBEep34aal8LwA Date: Fri, 21 Jun 2019 11:10:29 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801689E31B2@IRSMSX104.ger.corp.intel.com> References: <20190412150542.12026-1-ivan.malov@oktetlabs.ru> <20190621103419.11626-1-ivan.malov@oktetlabs.ru> In-Reply-To: <20190621103419.11626-1-ivan.malov@oktetlabs.ru> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzYyNDBlM2EtN2JmMC00MmMxLWI4NWYtZTExNTQ4MzcyODQ3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMFwvaW5qVHgyTDdWY0R6M2Izd0hFZ081bFkrM1lmSHlWSlhCYTE5elJkWUorbjIyekZ6V0lmMG1Db0ZHVlhrSXIifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] mbuf: outer offsets must be zero for non-tunnel packets X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ivan, >=20 > Make sure that outer L2 and L3 header length fields are > equal to zero for non-tunnel packets in order to ensure > consistent and predictable behaviour in network drivers. > Explain this expectation in comments to help developers. >=20 > Signed-off-by: Ivan Malov > Reviewed-by: Andrew Rybchenko > --- Not sure it is a good idea: 1) it is a change in public API behavior (requirements). 2) why these 2 particular tx_offload fields only? If we'll follow that logic we should enforce same rule for other tx_offload fileds (tso, l4_len, l3_len, etc.) Personally I don't think there will be much gain from it. Might be better and easier just to fix offending drivers that make wrong as= sumptions. If we'll still decide to go that way, then I think at least it needs to be explained in RN, and probably deprecation process has to be followed = here. =20 Konstantin >=20 > Notes: > At the time of writing a couple of network drivers rely on > the statement (i40e, ice) whilst more drivers have runtime > conditional checks to guard all references to these fields. > This patch is likely to relieve datapath checks in drivers. >=20 > lib/librte_mbuf/rte_mbuf.h | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) >=20 > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index 0d9fef0..cb8b34e 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -702,7 +702,12 @@ struct rte_mbuf { > uint64_t tso_segsz:RTE_MBUF_TSO_SEGSZ_BITS; > /**< TCP TSO segment size */ >=20 > - /* fields for TX offloading of tunnels */ > + /* > + * Fields for Tx offloading of tunnels. > + * These fields must be equal to zero in the case > + * when (ol_flags & PKT_TX_TUNNEL_MASK) =3D=3D 0, > + * i.e. for all non-tunnel packets. > + */ > uint64_t outer_l3_len:RTE_MBUF_OUTL3_LEN_BITS; > /**< Outer L3 (IP) Hdr Length. */ > uint64_t outer_l2_len:RTE_MBUF_OUTL2_LEN_BITS; > @@ -2376,6 +2381,11 @@ static inline int rte_pktmbuf_chain(struct rte_mbu= f *head, struct rte_mbuf *tail > !(ol_flags & PKT_TX_OUTER_IPV4)) > return -EINVAL; >=20 > + /* Outer L2/L3 offsets must be equal to zero for non-tunnel packets. */ > + if ((ol_flags & PKT_TX_TUNNEL_MASK) =3D=3D 0 && > + m->outer_l2_len + m->outer_l3_len !=3D 0) > + return -EINVAL; > + > return 0; > } >=20 > -- > 1.8.3.1