Re: Legacy Linux kernel support

[Guy Harris <gharris () sonic net>]

On Oct 7, 2019, at 11:07 AM, Mario Rugiero <mrugiero () gmail com> wrote:

> > So that would mean using non-memory-mapped capturing in immediate mode.  That might even work better for that 
> > purpose - yes, there's more copying involved (copying the packet to the socket buffer and then copying from the 
> > socket buffer into userland), but:
> >
> >        immediate mode is generally used for people (ab)using libpcap to implement protocols at the link layer, where 
> > you aren't necessarily dealing with the packet firehose you can get when doing sniffing;
>
> Hmmm, I use memory-mapping precisely to deal with that fire hose
> without dropping too much.

So are you saying that, even if you're using libpcap to implement a protocol running directly atop the link layer, 
rather than passively sniffing traffic, you still get a packet firehose?

> >        memory-mapped mode means declaring a maximum-sized buffer for packets, so it may consume more memory for the 
> > buffering;
>
> I could argue that declaring this maximum-sized buffer may give you
> more control over the memory consumption instead.

How so?  There's no way to specify, with TPACKET_V3, "deliver a block as soon as there is a packet in it" (unless I've 
missed something), which is what immediate mode means, so, for memory-mapped capturing in immediate mode, we have to 
fall back on TPACKET_V1 or TPACKET_V2.

With TPACKET_V1 or V2, the frame size is fixed, and must be >= the largest amount of data you will get in a frame.  If 
the frame is shorter than that, there's wasted space.

With TPACKET_V3, the frame size isn't fixed, so if you have a snapshot length of 1514 bytes but the frame is only 60 
bytes, you don't get 1454 bytes of wasted space.

> > so non-memory-mapped capturing might be a better fit.
>
> Isn't pcap currently using memory-mapping whenever it can?

Yes, but *should* it do so for immediate mode?

In immediate mode, with TPACKET_V1 or V2, you have wasted space, as per the above.  With non-memory-mapped capture, you 
just get skbuffs attached to the socket; I don't know if Linux has the equivalent of what the "loaned mbufs" some 
BSD-style stacks have, where the skbuff would directly point to a driver ring buffer slot, in which case there would 
probably still be wasted space (and in which case, if you don't consume the packet quickly, the adapter could run out 
of buffers), or if they're copied, in which case the target skbuff might not be full sized and there'd be less wasted 
memory.

> > ("(Ab)using" in the sense that perhaps there should be a *separate* library for use by code implementing protocols 
> > that run directly atop the link layer; on some platforms - not just Linux - that code might use a completely 
> > different mechanism from the mechanism used by libpcap.)
>
> That's a weird use-case indeed.

There are some protocols that work that way, and I think I remember at least one person complaining about an impedance 
mismatch between what libpcap offered and what they needed.

> I'm not sure libpcap is that bad of an option for this.

One of the aforementioned impedance matches is that the protocol implementation might want only one particular Ethernet 
type or one particular OUI/PID combination for SNAP frames - that could be done with a packet filter, but the OS 
mechanism might have a way to do it directly (binding to a particular protocol with Linux PF_PACKET sockets, binding to 
a particular SAP rather than setting SAP-promiscuous mode with DLPI, something else with the *non-BPF* mechanism that 
may be a better fit for this in macOS).

I'd have to find my notes from when I was looking at what an alternative library might do to see what some of the other 
ones are.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers