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
