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?rup -----Original Message----- From: Bruce Richardson [mailto:bruce.richard...@intel.com] 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
