Hi, i have recently made an update to the netmap I/O framework http://info.iet.unipi.it/~luigi/netmap/
that should make it easier to add netmap support to libpcap. So I was wondering if there is any interest to implement this and how we can go for it. In short (see the webpage for details) netmap is a kernel module (native on FreeBSD, external in Linux) that supports extremely high tx/rx packet rates (15-20Mpps per core, at least for the raw I/O; of course any processing will reduce your actual packet rate). You can find the most recent sources in the git repository at http://code.google.com/p/netmap/ In the past I have implemented a subset of the pcap library that lets programs run on top of netmap by just pointing LD_LIBRARY_PATH to the netmap-based library. This has some limitations though, and I'd rather see native netmap support in libpcap so we can e.g. reuse filters etc. A basic implementation of the equivalent of pcap_open_live(), pcap_close(), pcap_dispatch() and pcap_next() is in the <net/netmap_user.h> header file (it is so small and simple that there is really no need for a user library). pcap_inject() is similarly simple. Of course they should be integrated with libpcap and support the full set of methods, so i think to figure out the following: PORTING ISSUES + interface naming netmap provides an alternate method to access standard network interfaces, so the technique I am currently using in applications is to use the interface name to discriminate between standard (bpf, PF_PACKET or other) and netmap mode. This way applications do not need changes, and commandline arguments can be used to select the operating mode. "netmap:*" refers to interfaces in netmap mode, "valeXX:YY" refers to ports of VALE virtual switches (basically dynamically created ethernet bridges; VALE is part of the netmap module), and other names would just fall back to the regular pcap methods. Does this make sense ? + template for source I suppose the way to go is to pick the simplest pcap-*.c backend and use it as a reference for the implementation -- so which one should I use ? + receive side netmap natively uses shared memory, so pcap_dispatch() and pcap_next() are trivial to implement and very cheap. + transmit side pcap_inject() can be implemented easily by copying user data into the (preallocated) buffers supplied by netmap. + zerocopy As mentioned the receive side is alrea dy zerocopy, while for the transmit side i don't know if there is a pcap method that support a transmit callback -- i.e. an equivalent of pcap_dispatch() where pcap supplies the buffer and the callback puts in its data. Also one thing to remember is the address(es) returned by pcap_next() are only good until the next invocation of select()/poll() . Again I have no idea if the pcap API gives some control to the user for that + multiqueue netmap supports multiqueue NICs both on tx and rx. There are two operating modes: 1) one file descriptor binds to all queues; 2) one file descriptor per queue. This is selected at open time. Supporting this feature could be as simple as adding a suffix to the interface name. Comments anyone ? cheers luigi _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers