El lun., 7 oct. 2019 a las 16:07, Guy Harris (<ghar...@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
