Re: Legacy Linux kernel support

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Tue, 22 Oct 2019 14:41:32 -0700
>
> On Oct 22, 2019, at 2:24 PM, Mario Rugiero <mrugiero () gmail com> wrote:
>
> > El mar., 22 oct. 2019 a las 18:01, Guy Harris (<gharris () 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