From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id D13272BE5 for ; Fri, 11 Mar 2016 15:19:08 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 11 Mar 2016 06:18:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,320,1455004800"; d="scan'208";a="921784660" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga001.fm.intel.com with ESMTP; 11 Mar 2016 06:18:51 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 11 Mar 2016 14:18:50 +0000 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.174]) by IRSMSX156.ger.corp.intel.com ([169.254.3.132]) with mapi id 14.03.0248.002; Fri, 11 Mar 2016 14:18:50 +0000 From: "Pattan, Reshma" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v3 0/5] add dpdk packet capture support for tcpdump Thread-Index: AQHReZuPSWKpJzrzAkO3FXdh2hqw6J9ULdng Date: Fri, 11 Mar 2016 14:18:49 +0000 Message-ID: <3AEA2BF9852C6F48A459DA490692831FFDB003@IRSMSX109.ger.corp.intel.com> References: <1455289045-25915-1-git-send-email-reshma.pattan@intel.com> <1456920970-2047-1-git-send-email-reshma.pattan@intel.com> <3298735.LFDh5RH4eW@xps13> In-Reply-To: <3298735.LFDh5RH4eW@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDI2ZTk1YjYtNjAwNi00YTVkLWJjNjgtMDRkYjk1NTk3NmJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkJmQ2dqUExVSXliOG9BSHAwcWZFU3V4REloVEQ3THh6MXhNSitkQzgwOTg9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3 0/5] add dpdk packet capture support for tcpdump 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: Fri, 11 Mar 2016 14:19:09 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, March 9, 2016 12:34 AM > To: Pattan, Reshma > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/5] add dpdk packet capture support fo= r > tcpdump >=20 > Hi, >=20 > This series has not been reviewed enough to be ready for 16.04. > So it would be good to restart the discussion about the tcpdump requireme= nts. Yes, will plan for next steps. >=20 > > packet capture flow for tcpdump: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Part of the design is implemented in secondary process (proc_info.c) > > and other part in primary process (eal_interrupt.c). >=20 > Why proc_info is used? Why not a dedicated tool? proc_info or any other new tool, it must be secondary process.=20 proc_info is already simple secondary process and does take care of printi= ng dpdk port's packet statistics upon users request, hence same application was enhanced for dpdk packet capturing support. >=20 > > *User should request packet capture via proc_info application command > > line by passing newly added tcpdump command line options i.e. > > [--tcpdump (port,queue)] [ --src-ip-filter \"A.B.C.D\"] [--single-tcpdu= mp-file]. > > > > Note: As basic support, a src ip filter option is provided for filterin= g the > packets. > > This is optional. If user dont provide any src ip filter option all > > packets will be captured for tcpdump. >=20 > Why filtering? Why only on IP address? Why not BPF? >=20 Here, simple src-ip-filtering was demonstrated to give an idea on where fil= tering logic can fit in this design. The filtering logic can be enhanced with BPF or by other filtering methods.= This also improves performance. > > 2: Because of the underlying pcap writing overhead packets can only be > captured at slow rates. >=20 > What is the benefit of slow rate capture in DPDK? > Shouldn't we target a high rate mechanism? I believe there will be performance improvements if we also use TUN/TAP PMD= , but this is not up streamed in to DPDK. Thanks, Reshma