Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] pcapng / interface names / OPT_IDB_NAME

From: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Sun, 25 Oct 2020 12:07:07 +0100
Hi Guy,

On Sat, Oct 24, 2020 at 01:23:57PM -0700, Guy Harris wrote:
> > sidenote: I've just been doing some development work with io_uring
> > (using liburing) on modern Linux systems, and it's amazing in terms of
> > performance of asynchronous I/O.  Might be worth investigating.
> 
> Might be, although we'd need to either:
> 
> 1) figure out a way to do that, while hiding the platform-dependent details, on *all* (currently living) platforms supported by libpcap:
> 
> 	macOS;
> 	the *BSDs;
> 	Solaris;
> 	HP-UX;
> 	AIX;
> 	Windows;
> 	Linux;
> 
> which don't all have the same asynchronous I/O mechanisms (POSIX aio on most if not all of the UN*Xes, "overlapped I/O" or whatever Microsoft calls it on Windows)

I hear you.  But fundamentally, if your abstraction API bases on buffers in memory that
* get allocated/provided by the platform-specific code
* get handed to the platform-specific code for write

You should be able to cover all of those (famous last words).    I think the problem only starts
when the higher layer code tries to handle the select/poll or even only the write() calls by itself.

Now that I think more of your use case, you probably cannot even have the platform specific code
handle the allocations for the buffers, as you use mmap()ed AF_PACKET on the "read" side.   So
if the platform specific AIO mechanism cannot handle "foreign" memory that it didn't allocate,
you will have to copy.

With io_uring, you can hand in whatever buffers allocated in whichever way.  There's a small
performance benefit if you pre-register the buffers, so that the mapping in/out of kernel space
doesn't have to be done on every I/O operation.  You _should_ be able to
register the entire mmap'ed memory from the AF_PACKET socket once on
startup, though.

> 2) arrange that the user may, but need not, provide their own low-level writing code that the new writing APIs call, so they can either use a platform-independent mechanism supplied by libpcap or write their own code.  I think Michael Richardson has been thinking of something such as that.

That is basically more or less what I'm suggesting in the above.  I'm
happy to hack up an io_uring / liburing backend and contribute it, once
an interface for plugging that in materializes in libpcap.  As I'm not a
regular follower of the related mailing lists, please send me a ping
once you get to that point.

unrelated note: io_uring really does marvels, also for workloads with
many sockets.  It's easy to send and/or receive something like 500k pps
from thousands of sockets on my several years old laptop (Lenovo x26).
For a traditional userspace program using UDP socket based I/O that's
quite amazing.  Of course, not at all related to libpcap with it's
mmap() ed socket.

> What *might* be possible to do, in the absence of new libpcap capture APIs, would be to have dumpcap, when capturing from the "any" device on Linux and writing to a pcapng file:
> 
> 	when the capture starts, write out Interface Description Blocks (IDBs) for all the currently-known interfaces on the system, and make a table mapping from the kernel's interface indices (ifIndexes, in SNMP terms) to interface IDs for those IDBs;
> 
> 	when a packet arrives, look up its interface index of the packet, and:
> 
> 		if it's found, write the packet out with that interface index;
> 
> 		if it's *not* found, write out an IDB for the new interface, add it to the table, and write the packet out with that interface index.

Irrespective of current/future libpcap, this reflects the kind of logic that I
understood would be required for writing proper pcap-ng with IDBs on an
"any" interface capture, yes.  Good to hear it might be possible even
with the current code.

Regards,
	Harald

-- 
- Harald Welte <laforge@xxxxxxxxxxxx>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)