Re: Legacy Linux kernel support

[Mario Rugiero <mrugiero () gmail com>]

El lun., 7 oct. 2019 a las 16:07, Guy Harris (<gharris () sonic net>) escribió:

> 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?
No, I get a packet fire hose because I passively sniff. The protocol
idea is new to me.

> 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?
Good time to discuss (and fix it?), then :)

> 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.
Hmmm, that makes sense. I thought the concern was about total memory use.
Give me a day or two to check the sources on how the skbuff gets exposed.

> 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.
Interesting.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers