--- Begin Message ---
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.
> Either that, or just change TPACKET_V3 to do that.
>
Yes, that's what I was proposing.
> 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.
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 doesn't look as if you've sent anything to netdev yet about tpacket
> changes.
>
I haven't, I wanted to discuss this here first.
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
