--- Begin Message ---
On Oct 22, 2019, at 2:24 PM, Mario Rugiero <mrugi...@gmail.com> wrote:
> El mar., 22 oct. 2019 a las 18:01, Guy Harris (<ghar...@sonic.net>) escribió:
>>
>> 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.
>>
> Exactly. I'm against supporting it if it requires extra work. I don't
> think libpcap 1.10 is an absolute need in a scenario where you have to
> deal with RHEL 6, except possibly for security fixes, but those will
> have to be backported by Red Hat anyway.
So we'll say "oldest longterm maintenance kernel from kernel.org", and if it
also happens to work on your enterprise Linux with a pre-3.16, consider
yourself lucky; we won't make any effort to support RHEL 6 or other enterprise
distribution releases with pre-3.16 kernels.
>> Either that, or just change TPACKET_V3 to do that.
>>
> Yes, that's what I was proposing.
The proposal was "We would want a way to signal we want time outs regardless of
blocks being empty, then, right?"; I was suggesting just delivering empty
blocks no matter what, if there's code that depends on it. Libpcap itself can
work either way, and most libpcap applications used on both Linux and a
platform with BPF devices can work either way, as they don't get timeouts with
an empty buffer on Linux and they do get them with BPF, so I'm not sure there's
a strong need to have TPACKET_V3 support both with an option to specify which
one.
>> Originally, TPACKET_V3 delivered wakeups in a bogus fashion:
>>
>> ...
>>
>> The code currently has the patch, and doesn't deliver empty blocks.
>>
> I'll read these carefully later, but my take on it is that TPACKET_V3
> used to support our use case, so in principle a patch to restore it
> could be accepted.
libpcap's use case doesn't require delivery of empty blocks; we make no promise
that pcap_dispatch() or pcap_next() or pcap_next_ex() will return within the
specified timeout interval. I don't think Solaris DLPI with bufmod delivers
empty packets, for example.
There may still be some programs that expect pcap_dispatch() or pcap_next() or
pcap_next_ex() to return after the timeout expires, but since that doesn't
happen on Linux with TPACKET_V3, most programs that used to do so have probably
been changed not to do so.
There may be programs directly using PF_PACKET sockets with TPACKET_V3 that
expected empty blocks to be delivered, but given that 3.19 was released on
2015-02-08, and contained the patch that caused empty blocks not to be
delivered, I suspect most programs that used to do no longer do so.
> I find it unclear whether it is the ability of posting of empty blocks
> that would break use cases or its absence from the previous paragraph,
> but I guess I'll know after reading the mails.
It's the *absence* of empty block delivery that was cited as potentially
breaking code.
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
