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: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 support
> > > OK, 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