From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by dpdk.org (Postfix) with ESMTP id A27D78E63 for ; Wed, 16 Dec 2015 12:40:45 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Dec 2015 12:40:43 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC358AF76F@smartserver.smartshare.dk> In-Reply-To: <20151216104502.GA10020@bricha3-MOBL3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] tcpdump support in DPDK 2.3 Thread-Index: AdE38FBx15GbDraKTfCvT1pYxeiUeAAAIqBg References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> <20151214182931.GA17279@mhcomputing.net> <20151214223613.GC21163@mhcomputing.net> <20151216104502.GA10020@bricha3-MOBL3> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3 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: Wed, 16 Dec 2015 11:40:45 -0000 Bruce, This doesn't really sound like tcpdump to me; it sounds like port = mirroring. Your suggestion is limited to physical ports only, and cannot be = attached further inside the application, e.g. for mirroring packets = related to a specific VLAN. Furthermore, it doesn't sound like the filtering part scales well. = Consider a fully loaded 40 Gbit/s port. You would need to copy all = packets into a single rte_ring to the attached filtering process, which = would then require its own set of lcores to probably discard most of = these packets when filtering. I agree with Matthew that the filtering = needs to happen as close to the source as possible, and must be scalable = to multiple lcores. On the positive side, your idea has the advantage that the filter can be = any application, and is not limited to BPF. However if the purpose is = "tcpdump", we should probably consider BPF, which is the type of = filtering offered by tcpdump. I would prefer having a BPF library available that the application can = use at any point, either at the lowest level (when = receiving/transmitting Ethernet packets) or at a higher level (e.g. when = working with packets that go into or come out of a tunnel). The BPF = library should implement packet length and relevant ancillary data, such = as SKF_AD_VLAN_TAG etc. based on metadata in the mbuf. Transferring a BPF filter from an outside application could be done by = using a simple text format, e.g. the output format of "tcpdump -ddd". = This also opens an easy roadmap for Wireshark integration by simply = extending excap to include such a BPF filter format. Lots of negativity above. I very much like the idea of attaching the = secondary process and going through an rte_ring. This allows the = secondary process to pass the filtered and captured packets on in any = format it likes to any destination it likes. Med venlig hilsen / kind regards - Morten Br=F8rup -----Original Message----- From: Bruce Richardson [mailto:bruce.richardson@intel.com]=20 Sent: 16. december 2015 11:45 Hi, we are currently doing some investigation and prototyping for this = feature. Our current thinking is the following: * to allow dynamic control of the filtering, we are thinking of making = use of the multi-process infrastructure in DPDK. A secondary process can = attach to a primary at runtime and provide the packet filtering and dumping = capability. * ideally we want to create a generic packet mirroring callback inside = the EAL, that can be set up to mirror packets going through Rx/Tx on an ethdev. * using this, packets being received on the port to be monitored are = sent via an rte_ring (ring ethdev) to the secondary process which takes those = packets and does any filtering on them. [This would be where BPF could fit = into things, but it's not something we have looked at yet.] * initially we plan to have the secondary process then write packets to = a pcap file using a pcap PMD, but down the road if we get other PMDs, like a = KNI PMD or a TAP device PMD, those could be used as targets instead. This implementation we hope should provide enough hooks to enable the = standard tools to be used for monitoring and capturing packets. We will = send out draft implementation code for various parts of this as soon as = we have it. Additional feedback welcome, as always. :-) Regards, /Bruce