Great idea, Arnon. Let?s look at existing use cases from the real world.
Our company makes network appliances. They are not running GNU/Linux or similar, so they do not offer a BASH prompt or any other BSD/Linux like command line interface. Here?s a simplified description of how the user interacts with the packet capture feature in our appliances: Our GUI allows you to input a filter, e.g. a MAC address, an IP address or a compiled BPF program as a single hexadecimal string (roughly ?tcpdump ?ddd? output), and start capturing. The captured packets can then be downloaded from the GUI in pcap format. The other packet filters our appliance needs, e.g. DHCP, ARP etc., are not provided by the user (or by any other external interaction), but are hardcoded in C, just like any other part of our firmware. Med venlig hilsen / kind regards Morten Br?rup CTO SmartShare Systems A/S Tonsbakken 16-18 DK-2740 Skovlunde Denmark Office +45 70 20 00 93 Direct +45 89 93 50 22 Mobile +45 25 40 82 12 mb at smartsharesystems.com <mailto:mb at smartsharesystems.com> www.smartsharesystems.com <http://www.smartsharesystems.com/> From: Arnon Warshavsky [mailto:ar...@qwilt.com] Sent: 16. december 2015 12:37 To: Bruce Richardson Cc: Matthew Hall; dev at dpdk.org; Morten Br?rup Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3 2 points from our experience in saving pcap files from a dpdk 10G fire hose: 1) Our capture module provides a small "bit-vector" to the code that handles the packets. Since our packet processing code is already finding out basic stuff about the packet traversing it (is it IPv4? v6? is it TCP? is it fragmented? ..etc), it sets the relevant bits ON as it goes ,so that the capture module can later quickly (mask against desired filters) decide if the a packet needs to be captured. Point is - when a capture layer exposes a slim API that lets it utilize info coming from other modules , its easier and less expensive to handle the fire hose. 2) In many cases we are interested in capturing complete TCP flows, or at least the first X packets of them. In this case, A more expensive filter may be applied only on the SYN packet and when matches, turns ON a bit on the tcp flow applicative context that says we want to capture any packet falling under this tuple. Point is - applicative filters at different costs are applied on different packet types utilizing the mask from the previous bullet Such a model should obviously need to be optional on a formal capture layer, but when dealing with a fire hose - I find it very useful. /Arnon
