On Mar 26, 2011, at 10:14 PM, Martin Visser wrote:
> However a network adapter/interface is by nature serial with a single path - packet reordering only occurs due to having say multiple queues that chosen on say a quality-of-service rule.
...or if:
you have a multiple-core system;
not all packets for a given interface are handled by the same core;
and, if cores A and B are working on packets, the packets get stuck on the queue for a socket in the order in which the cores get around to queueing the packet, even if the packet that arrives second gets queued first.
> My surprise if that libpcap interfaces would be implemented in a way different from the network stack.
On the platform where I've most heard of this happening, Linux, libpcap uses PF_PACKET sockets, which are part of the same general networking stack as PF_INET, PF_INET6, etc. sockets, so it doesn't work differently from the network stack. (And, yes, I suspect the IPv4 and IPv6 implementations, for example, sometimes get packets in an order other than the order in which they arrive on the wire; that's no different from getting them in an order other than the order in which they were handed to the link layer on the sending machine - IP and the protocols running atop it have to deal with out-of-order packets, no matter why they're out-of-order.)
On *BSD and Mac OS X, libpcap uses BPF devices; they use a separate code path from most of the networking stack - the networking drivers deliver packets to BPF separately; I think it's similar with AIX's BPF. In SunOS 5.x-based Solaris, packets are delivered to raw DLPI devices in much the same way they're delivered to the rest of the networking stack; OpenSolaris 11, however, I think they now have BPF, which might use a separate code path. WinPcap attaches to NDIS, just as the rest of the networking stack does.
Now, perhaps libpcap should do some (small) amount of buffering and reordering of the packets it receives from the OS's capture mechanism, to at least attempt to deliver packets in time stamp order (which is the best it can do; that's not necessarily the order in which packets arrived on the network adapter, as the packets might have been time-stamped by different cores in an order other than the order in which they were delivered to the host by the adapter).
