Re: Legacy Linux kernel support

[Mario Rugiero via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Mario Rugiero <mrugiero () gmail com>
>
> Date: Mon, 21 Oct 2019 22:04:54 -0300
>
> I think it's time to summarize, and to propose one last idea.
> I'm following the thread again to try and be as accurate as possible,
> but of course any objections are welcomed.
>
> - The oldest officially supported kernel is 3.16, as this is the
> oldest LTS according to kernel.org.
> - Users of the library must be properly informed when their
> environment is unsupported, as well as the last version supporting it.
>   This should be done both at compile-time and at run-time.
> - SOCK_PACKET goes away. This is already done in master.
> - TPACKET_V1 goes away.
> - TPACKET_V2 stays for immediate-mode support.
>   - As a side-effect, RHEL6 remains supported.
>   - The idea of exploring using non-memory-mapped sockets for this was
> proposed, and it would be interesting to follow-up.
>      For this, I was supposed to check whether that makes a difference
> regarding how the kernel implements it.
> - The workaround for TPACKET_V3's bug stays, as the fix was only
> introduced in 3.19.
> - We should explore reaching a solution to immediate-mode that doesn't
> require TPACKET_V2.
>   - It has to be noted, tho, that any changes to allow that aren't
> unlikely to be back-ported to older kernels, so we'd still need
> TPACKET_V2 for the time being. It'd be a bet for the future.
> - Just to acknowledge it, it was proposed to research on whether
> support for AF_XDP makes sense. I think that belongs to its own
> discussion, tho.
>
> Now, the idea goes along with the last item.
> I was thinking of proposing a new option for TPACKET_V3 sockets to set
> a deadline.
> I haven't completely decided on the details, but basically it would
> behave somewhat like this:
> - The deadline can take three types of value:
>   - (-1): no deadline, wait until a block is full before marking as
> ready for user space. This would be the default, so no existing
> programs change their behavior.
>   - (0): expose packets as soon as they arrive. This would act more or
> less as previous AF_PACKET versions work.
>   - A positive integer: this would be how long to wait (I haven't
> decided on the unit, I'm guessing microseconds should work).
>     I'm not sure regarding what the deadline is set, but I'm thinking
> since the first packet in the block arrived.
>
> Any ideas on this?
> How should we keep the discussion in sync between the two lists?
> Should I CC the participants on this list on the RFC on the kernel list?
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers