tcpdump mailing list archives
Re: Legacy Linux kernel support
From: Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Tue, 22 Oct 2019 16:58:53 -0400 (EDT)
--- Begin Message --- From: Guy Harris <gharris () sonic net>
Date: Tue, 22 Oct 2019 14:00:57 -0700
On Oct 22, 2019, at 1:22 PM, Mario Rugiero <mrugiero () gmail com> wrote:El mar., 22 oct. 2019 a las 16:02, Guy Harris (<gharris () sonic net>) escribió:I.e., the goal for libpcap support on Linux should be something such as it should work on min({kernel for oldest supported enterprise distribution}, {oldest "longterm maintenance" kernel release from kernel.org})I'm more inclined to oldest longterm from kernel.org only, but I guess so.If RHEL 6 matters, oldest longterm from kernel.org only doesn't work, because RHEL 6 runs 2.6.32, according to https://access.redhat.com/articles/3078 so if we're going to support only the oldest longterm maintenance kernel from kernel.org, we're not going to support RHEL 6 unless TPACKET_V3 has been back ported to the RHEL 6 kernel. If it's not backported, *and* we continue to use TPACKET_V2 for immediate mode, then RHEL 6 happens to still be supported to that extent. However, if we require any *other* mechanisms that aren't present in the RHEL 6 kernel, that means no RHEL 6 support. So I wouldn't claim RHEL 6 support solely on the basis of continued TPACKET_V2 support - don't rely on the side effect. if we're going to supportOK, so TPACKET_V3 currently supports something similar to what BPF devices support, i.e. "deliver a block if it's full or if the timeout expires". The timeout is in the tp_retire_blk_tov field of a tpacket_req3 structure, as handed to a SOL_PACKET/PACKET_RX_RING setsockopt() call. It's in units of milliseconds; it doesn't refer to inter-packet spacing, but to the age of the block. Currently it doesn't deliver empty blocks; libpcap can handle either "delivers empty blocks" (as that's what BPF devices do) or "doesn't deliver empty blocks" (as that's what TPACKET_V3 currently does). The main difference is whether the timeout times out even if no packets are available; I guess code that wants to be woken up periodically, perhaps to do other work, even if there's no traffic that passes the filter would prefer "time out even if no packets are available".I see. We would want a way to signal we want time outs regardless of blocks being empty, then, right?Either that, or just change TPACKET_V3 to do that. Originally, TPACKET_V3 delivered wakeups in a bogus fashion: https://www.spinics.net/lists/netdev/msg290837.html (that's the problem we're working around). The original developer of TPACKET_V3 claimed that empty blocks have to be delivered: https://www.spinics.net/lists/netdev/msg291734.html but didn't indicate why, so I tried to infer from the patch: https://www.spinics.net/lists/netdev/msg291734.html I have no record of a response (and, for whatever reason, his original message didn't show up in the netdev archives). The bogus wakeups were fixed by a later patch: https://www.spinics.net/lists/netdev/msg315231.html That also eliminated delivery of empty blocks to the user. A response said "This change would break existing applications that have come to depend on the periodic signal.": https://www.spinics.net/lists/netdev/msg315418.html to which I responded: https://www.spinics.net/lists/netdev/msg315425.html The author of the patch then responded: https://www.spinics.net/lists/netdev/msg315510.html https://www.spinics.net/lists/netdev/msg315528.html The code currently has the patch, and doesn't deliver empty blocks.OK, I guess I'll have to go back to reading that list. (It's a very heavy traffic list, and 99.99999999999% of it isn't relevant to packet capture - all that matters to me is 1) PF_PACKET stuff and 2) stuff involving device modes such as some ethtool features and monitor-mode/radiotap support - so I just look at it on occasion.)Wouldn't CC'ing you keep you on the loop already?It might, as long as everybody keeps me on the CC list. It doesn't look as if you've sent anything to netdev yet about tpacket changes.
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- Re: Legacy Linux kernel support, (continued)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero (Oct 08)
- Re: Legacy Linux kernel support Guy Harris (Oct 08)
- Re: Legacy Linux kernel support Mario Rugiero (Oct 08)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero (Oct 08)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero (Oct 09)
- Re: Legacy Linux kernel support Mario Rugiero via tcpdump-workers (Oct 21)
- Re: Legacy Linux kernel support Guy Harris via tcpdump-workers (Oct 22)
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero via tcpdump-workers (Oct 22)
- Message not available
- Message not available
- Re: Legacy Linux kernel support Guy Harris via tcpdump-workers (Oct 22)
- Message not available
- Message not available
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero via tcpdump-workers (Oct 22)
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Legacy Linux kernel support Guy Harris via tcpdump-workers (Oct 22)
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Legacy Linux kernel support Mario Rugiero via tcpdump-workers (Oct 22)
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Legacy Linux kernel support Guy Harris via tcpdump-workers (Oct 22)
- Message not available
- Re: Legacy Linux kernel support Guy Harris (Oct 08)
- Message not available
- Re: Legacy Linux kernel support Guy Harris (Oct 08)