From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id A133A2B83 for ; Tue, 13 Nov 2018 10:47:51 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 01:47:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,498,1534834800"; d="scan'208";a="108146946" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga002.jf.intel.com with ESMTP; 13 Nov 2018 01:47:50 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.87]) by irsmsx105.ger.corp.intel.com ([169.254.7.144]) with mapi id 14.03.0415.000; Tue, 13 Nov 2018 09:47:49 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , "Lipiec, Herakliusz" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] example/ipv4_multicast: fix app hanging when using clone Thread-Index: AQHUesjXwRa/wc3zoEOCvWNGqQmfc6VNcAmAgAAA7IA= Date: Tue, 13 Nov 2018 09:47:48 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258010CE49B5D@IRSMSX106.ger.corp.intel.com> References: <20181112204650.7175-1-herakliusz.lipiec@intel.com> <4835654.xzScbSBJzk@xps> In-Reply-To: <4835654.xzScbSBJzk@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzIzYzU2ZDEtMTkwNS00YWVjLWE3OWEtNjNmMWIzYTkxZDMxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaFwvQWhmdW5zaVMwVFEzTGpJemZPakFRM3JnV01GdlJjNFJuc3NBS0lGT3p3SXVxQUdWXC9NdUU5NHhiQ3VcL3NNayJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 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] example/ipv4_multicast: fix app hanging when using clone 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: , X-List-Received-Date: Tue, 13 Nov 2018 09:47:52 -0000 >=20 > Hi, >=20 > 12/11/2018 21:46, Herakliusz Lipiec: > > This example was dropping packets when using clone (ip 224.0.0.103). The problem is that ipv4_multicast app: 1. invokes rte_pktmbuf_clone() for the packet=20 (that creates a new mbuf with IND_ATTACHED_MBUF set in ol_flags). 2. creates new mbuf containing L2 header and chains it with cloned at step= 1 mbuf. 3. copy ol_flags from cloned mbuf to new header mbuf. So after step 3 L2 header mbuf also has IND_ATTACHED_MBUF set in ol_flags. That makes pktmbuf_free() wrongly assume that this is an indirect mbuf, which causes all sorts of problems: incorrect behavior, silent memory cor= ruption, etc. The easiest way to reproduce the problem: - run ipv4_multicast, using two ports: ipv4_multicast -l 0,1 - -p 0x3 send 8K+ packets to one of the ports with dest ip address: 224.0.0.103 ipv4_multicast will stop forward any packets. In fact, there is no reason to copy ol_flags from the cloned packet. So the fix is just to remove that code. Konstantin >=20 > What is this IP? > What is clone? >=20 > > The problem was that mbufs were not freed. This was caused by coping > > ol_flags from cloned mbuf to header mbufs. >=20 > Mbuf is not freed because of ol_flags? > I feel this description should be improved. >=20 > > Signed-off-by: Herakliusz Lipiec > [...] > > --- a/examples/ipv4_multicast/main.c > > +++ b/examples/ipv4_multicast/main.c > > @@ -266,8 +266,6 @@ mcast_out_pkt(struct rte_mbuf *pkt, int use_clone) > > hdr->tx_offload =3D pkt->tx_offload; > > hdr->hash =3D pkt->hash; > > > > - hdr->ol_flags =3D pkt->ol_flags; > > - > > __rte_mbuf_sanity_check(hdr, 1); > > return hdr; > > } >=20 >=20