From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A29F7A00C2; Thu, 10 Feb 2022 13:21:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8BF05426DF; Thu, 10 Feb 2022 13:21:39 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 35CEC4013F for ; Thu, 10 Feb 2022 13:21:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644495697; x=1676031697; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=vkz2TezLoSi0n5xHd7aNu7Rr1xwsDQM1nCiQ2y/jLEU=; b=RQNl6+PTtsbm0JqdMfVeYUdkAEsU9YCKWNWWmDgk8t961G1nc/mZB6JT lVeQroP33UnT7AL0QWAO7kjL/prhIgRoumg7KKA4jvWhQ+4khwsXlBFVN UJpoSS3lQVO3aTQpVd0h5ukKWNtiylN2HQGC2Gb3ncj89q4uxCJlGII8d U4NrVPKc6r7obmwBSZAEeQQHhGOvVkrwTjvVlT2Va+50GQrgelVbTXVDP 3NHMPPcZ++S7jCm6S/uBp+av02yqI0tLNFc5R2kDosD/FDUUSz9Eclaid 9P3MiMpKkbc8e/DFAz3xicdpfBXXA7lmesf9UmW1+f520wOfc3adv4Bz6 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10253"; a="249427155" X-IronPort-AV: E=Sophos;i="5.88,358,1635231600"; d="scan'208";a="249427155" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2022 04:21:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,358,1635231600"; d="scan'208";a="633644827" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga004.jf.intel.com with ESMTP; 10 Feb 2022 04:21:36 -0800 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 10 Feb 2022 04:21:35 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Thu, 10 Feb 2022 04:21:35 -0800 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.174) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Thu, 10 Feb 2022 04:21:35 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pk90VonJccr3E/rFZwDjP3m3XtfUDiK2bsbmifM/zsm1lqWpoJ3s3PkFSieg/TKGb30KXP4Jj79lpz+GqT17lDXer0US8dKNesLMbhgcLQ9iNJnvwtZQWc2Z5UjsJOjdi1dgbdfDQgNZ+5QhRiRPr1OjBR3E6FCc2cd88JlWA87HLOAbcFIKtM1Fp69aM1DQ/TWLzJf4yI/WdTPx+xbDOWhqS3bn8ZMP6MHmaX2psCQzDjpe762w3JNsgri+201FMUeI+4a8Y0IoshggAgGpdt6ENKgv4caRT9E3FycPRubeS+mrIB1XCWQxmDag2ZCV+vmr1pSJouRO5X+bjIXbZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=t2HvTtNzwa3aQZPr7S5qzREH5f2ThNP0nzaGuIgVXio=; b=mLpZ7EnqBtli92ondj24x+AZHRhlNNph7+B+2E6e8md6i20I9n4S0iiUUk5dNRteJrU1MmtopNGGO7xrmrKzBeovQLBM4ldpeOqikNzMvp5uU5l9x6M3Ct29IXz/x/zplhHpHMNmtxzrjwgA2e9cP8r4GkvhuM2xySQX/P2aB8XA3XwD7w9RC7yVwOKI+88CRvGLhe3OKo2g9aeG6STQlj8mzlRf01weac/jmUpTOplataE6rTyEZ3gbmPZ4LBnRS5g2uZZiYqEek1MQ7X+mTkvZevxnM9QdI3AeueT/A2dPSHGaoTZ9A8ZsUcCX/6e8qFD/NnpBQKcz3t7eBL/s4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by BN6PR1101MB2164.namprd11.prod.outlook.com (2603:10b6:405:51::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Thu, 10 Feb 2022 12:21:34 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::8ccc:ed65:78fa:1b07]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::8ccc:ed65:78fa:1b07%4]) with mapi id 15.20.4951.019; Thu, 10 Feb 2022 12:21:34 +0000 From: "Ananyev, Konstantin" To: "chcchc88@163.com" CC: "dev@dpdk.org" Subject: Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data Thread-Topic: Re: [PATCH] ip_frag: add IPv4 options fragment and unit test data Thread-Index: AdgedV8ypi9OY3rFR8WhSxVcwv5L8w== Date: Thu, 10 Feb 2022 12:21:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c264640-239c-4249-a3f6-08d9ec8fe09a x-ms-traffictypediagnostic: BN6PR1101MB2164:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BUAfpqRYcaOW+scuVgaPZ1ZbBWmB9a02Pjf96J4Jzhl5tJnT8gG82e5WUnZXuPVSb3/M6jU/Fk5akBMDm6+0dNNteQ1DfxZeiqIWHCkqsik2J0oMqjyobu2ObOUPXCIfJ1D3HHeP5ay483Pk9e4ckvYA2zjk4SyPCKaUNsZuBOhWG5EWK+tDn7ZaP4t5l1O2ztTQNbupSYI5wCyheXrxcmzIV7gOeKMeAXCdHyNCp6Ihwrdj5LeFVatc5qohMUzwn7ieHeDryQ98hOGrqH6iGmG8wEOhs8lgRdf/opmrSMiuCYUoLvk3knFRFwv1A3ljFYnXdPZ8sDfvnq8X+9f7VaWiV5CBOvtuqUn9ECYBxbkQ6G50tYV8maow4HNpUk5EmKHxApm0OcHBFdZ4YX4D1vn4i7JtTHgAyle7O6RnAeFj8bBs6/ZOnvlZI/5hehk/fgcVMxWbtyAM8W47czDmSUkqCOUMh0Pr28cE8TOJ3U/OmQSJ2a2Jb3uCk5Q5IoGkekaQKCKd9hW6vMUgRd3TvFj6MbIde7//YuRWFbq5DCmbEa9OxVA4ybEH2/7cZPGmYKY6JAOApxf2BqqT+j56CEfLiRGNewMonZroy5ku1QIYcqMo1OFIbrsFlCtercJZiZ3MMrij/GGyESizCZIpSfvEZ4BVak9Q42gIC/hBkT9V2v+J8LLEICz2iAR8eQ0TlTCRSfFynri10yP3RLHUPQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(71200400001)(7696005)(52536014)(86362001)(2906002)(8936002)(316002)(83380400001)(6506007)(82960400001)(6916009)(9686003)(122000001)(38070700005)(26005)(186003)(508600001)(55016003)(66476007)(5660300002)(38100700002)(4326008)(66556008)(64756008)(33656002)(66446008)(66946007)(8676002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+2FGyprazkm/5vqlIskRCx42Wz2Z4WQJqi+npVfO3YkwQ0KbPGa1Royvf5oI?= =?us-ascii?Q?0RondqllIBLgT+ERKNSv5xhzb6VQqkqzWUTQYa2enKS6N36q0eA8CTgTozgy?= =?us-ascii?Q?gmFy+5W4d1lPGkbQ5N/ZftaZLKvW09uHTOOVTRmNmSeSjYvxeP+Gyn0f4Jyn?= =?us-ascii?Q?zz00qTXOhfqOqttR2L6/0YuPDjIBDnkWCEsB3P0888jvEoP9DrdOGigHmrxb?= =?us-ascii?Q?e0XpvZHHXh0bcoRTtugn6HdEryl0g/BS4FWNkiTT0sSsPZ1o59/p/jx1EsSW?= =?us-ascii?Q?mYOaNrlGe9c7Gs7htqZTSvoM8gononSFAqcaGcyD4C5LcokkJmVbO3zlOPlB?= =?us-ascii?Q?JdQJYx+ybjOi5HZZXHZxatJ1IhE1b66g2aiJLTYeMIFR3KH+6wk/gtM/yxtn?= =?us-ascii?Q?4h2xn2tRMCQXz6KBMjZ4kjoX9lM4NinNGBkuoQkvKBmaHYgga2SD0q0o9GC2?= =?us-ascii?Q?qAzz4K5/Kmu5XxvBFfrXtO4T9WxuE6IY3q1F+0xLpoYTtF9TqP1d2Hd9/iSg?= =?us-ascii?Q?xjZwd9pNkV3s/3IptFFw5zRQzpJi5HYa8nmZ7grzjaJooFuTXb7Rvml8G5EZ?= =?us-ascii?Q?ZV2V/LGFFCfRZzlkyicHik0oEGajpY/hRz3LUZPifwL1VtgTaRPoPrFhjnUs?= =?us-ascii?Q?m5NFUl2iNAatmxpjt+j4fj5rWPb4Qlpi/YpeBify5+k3nC5lTffjmdMWrfb2?= =?us-ascii?Q?k+yhoUvKHtS3JGsx1gcFJya/o7tcB7DHd6liUPhiEWGBoMFbn8meV0w56/BI?= =?us-ascii?Q?rQp+/ykIyNkFC0HuwajX08tD1h5FHiISJkL53lfmx50VZBXefEhN5IzjYkVm?= =?us-ascii?Q?c6Q4KzO0pFTK7d3MrWxlSYDvkfe9U9eD3MxKr5Zf0/RRMhom/8uB39v66UL6?= =?us-ascii?Q?gpNjWquFJxcqTE8pwTEp034PJGVMA7f23uHSbI//uxogijTMrA2xOx8wJARz?= =?us-ascii?Q?/SjV7fszYpMajMai/W6yye+Mnc3XMJX1h/k13hIG3T3Qq9kcf3AMDQj9sPSe?= =?us-ascii?Q?0vJKAEOEjV0DyOFy/MnsU13l6t89FkwUnbj83fpTJgAfzfQjH1i8PqNHJryL?= =?us-ascii?Q?5hjgV3OBtsZj8va1HmG8BuOL0jY2rIRx2wHSaKXvhhQKUKDH6Hb6IQejqXMl?= =?us-ascii?Q?IiNOwgzFIMlrattSnUe29PYpjTfyyPxG+k3ouMsZqp9B2fdPm3xfHRWII6q6?= =?us-ascii?Q?CT0XR4P//roDeg1LEys7pXjesNhKnjarHSHmMbR3D+gqEvRpHZLhdLQ0YUti?= =?us-ascii?Q?wuIekXDYKUwKMQf1j9i6e/eHdlXWXsMotZeWn3wO60WaPSnOzV+39MnV0i7G?= =?us-ascii?Q?H7d3KWtKXWPIhelYX9tpISbRTRIYXGLY0od+fUG1ImEQ9nmAaQCFUjZ0bhPp?= =?us-ascii?Q?DJ0w2CvC3idpwm181UEEnCJGlNqPglFIapy6BgpbEDE9D9H1nleW0TE7fhLw?= =?us-ascii?Q?QbkGfb7IRlgB8V9QYa/CPDZI/GoEEayJzu3sUq3TMVMXiQr6d9phM6xeS+9x?= =?us-ascii?Q?AMo/y+jScFjKFbP1tePX+61KGDY48nXg0/B8kVnqsj5RUTwU5xpT8EBMQs8p?= =?us-ascii?Q?sSoRhlIn22u9uwXUFUor2QUFzGqBeAT0FjYz8Yc/UQUqR/INYCT+PQVY8B8c?= =?us-ascii?Q?1rBZ7ksf96vVza97uBsbNrMtb73PJ2tNYESuF5vm1+jRV5pbVfKyQxm/3XsQ?= =?us-ascii?Q?qH6EyA=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c264640-239c-4249-a3f6-08d9ec8fe09a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 12:21:34.1251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4CLqWu1Qnl46K3zbBX6FS/MduMPLnI445SHoCpusNlkvHTxJ+JKjVU3GHtEIyjICN8G4liCY4kkDKiYolrpF/A7Ohn0VDvDlLrvKvQTvVEw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2164 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org >=20 > According to RFC791,the options may appear or not in datagrams. > They must be implemented by all IP modules (host and gateways). > What is optional is their transmission in any particular datagram, > not their implementation.So we have to deal with it during the > fragmenting process.Add some test data for the IPv4 header optional > field fragmenting. >=20 > Signed-off-by: Huichao Cai > --- .... > diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c b/lib/ip_frag/rte_ipv4_= fragmentation.c > index 2e7739d..bcafa29 100644 > --- a/lib/ip_frag/rte_ipv4_fragmentation.c > +++ b/lib/ip_frag/rte_ipv4_fragmentation.c > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: BSD-3-Clause > +/* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0) > * Copyright(c) 2010-2014 Intel Corporation > */ >=20 > @@ -12,6 +12,13 @@ >=20 > #include "ip_frag_common.h" >=20 > +/* IP options */ > +#define RTE_IPOPT_COPY 0x80 > +#define RTE_IPOPT_CONTROL 0x00 > +#define RTE_IPOPT_END (0 | RTE_IPOPT_CONTROL) > +#define RTE_IPOPT_NOOP (1 | RTE_IPOPT_CONTROL) > +#define RTE_IPOPT_COPIED(o) ((o) & RTE_IPOPT_COPY) > + > /* Fragment Offset */ > #define RTE_IPV4_HDR_DF_SHIFT 14 > #define RTE_IPV4_HDR_MF_SHIFT 13 > @@ -41,6 +48,38 @@ static inline void __free_fragments(struct rte_mbuf *m= b[], uint32_t num) > rte_pktmbuf_free(mb[i]); > } >=20 > +/* > + * Options "fragmenting", just fill options not > + * allowed in fragments with NOOPs. > + * Simple and stupid 8), but the most efficient way. > + */ > +static inline void ip_options_fragment(struct rte_ipv4_hdr *iph) > +{ > + unsigned char *optptr =3D (unsigned char *)iph + > + sizeof(struct rte_ipv4_hdr); As a nit, why not 'uint8_t *', to keep style the same through all file?=20 > + int l =3D (iph->version_ihl & RTE_IPV4_HDR_IHL_MASK) * > + RTE_IPV4_IHL_MULTIPLIER - sizeof(struct rte_ipv4_hdr); We already done such calculation in rte_ipv4_fragment_packet(), so can re-use header_len value here. > + int optlen; > + > + while (l > 0) { > + switch (*optptr) { > + case RTE_IPOPT_END: > + return; > + case RTE_IPOPT_NOOP: > + l--; > + optptr++; > + continue; > + } > + optlen =3D optptr[1]; > + if (optlen < 2 || optlen > l) Why optlen=3D=3D1 is not considered as valid one? > + return; > + if (!RTE_IPOPT_COPIED(*optptr)) > + memset(optptr, RTE_IPOPT_NOOP, optlen); > + l -=3D optlen; > + optptr +=3D optlen; > + } > +} > + > /** > * IPv4 fragmentation. > * > @@ -188,6 +227,17 @@ static inline void __free_fragments(struct rte_mbuf = *mb[], uint32_t num) > (uint16_t)out_pkt->pkt_len, > flag_offset, fragment_offset, more_in_segs); >=20 > + /* > + * ANK: What means 'ANK' here?=20 > dirty, but effective trick. Upgrade options only if > + * the segment to be fragmented was THE FIRST (otherwise, > + * options are already fixed) and make it ONCE > + * on the initial mbuf, so that all the following fragments > + * will inherit fixed options. > + */ > + if ((fragment_offset =3D=3D 0) && > + ((flag_offset & RTE_IPV4_HDR_OFFSET_MASK) =3D=3D 0)) > + ip_options_fragment(in_hdr); > + I see two problems with that approach: - you modify incoming packet's header - which is the change in behaviour, and doesn't look right at all. - you remove not-copied options from all fragments. As I can read RFC 791 - first fragment should have a copy of all options = present in original packet, while other fragments need to have only those that ha= ve to be copied. =20 > fragment_offset =3D (uint16_t)(fragment_offset + > out_pkt->pkt_len - header_len); >=20 > -- > 1.8.3.1