--- Begin Message ---
El mar., 22 oct. 2019 a las 15:08, Guy Harris (<ghar...@sonic.net>) escribió:
>
> On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
> <tcpdump-workers@lists.tcpdump.org> wrote:
> > - TPACKET_V2 stays for immediate-mode support.
> > - As a side-effect, RHEL6 remains supported.
>
> So RHEL6's kernel is pre-3.16 and thus doesn't support TPACKET_V3?
>
It's 2.6 series (2.6.32?), and TPACKET_V3 was introduced in 3.2.
> > - 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.
>
> So you're talking about a TPACKET_V5, or changes to TPACKET_V3 or TPACKET_V4,
> to support immediate mode in memory-mapped capture, as opposed to using
> non-memory-mapped sockets?
>
I was thinking more of a backwards compatible extension to TPACKET_V3
in principle, but that's open for discussion.
My thoughts on this are at the end of my summary.
> > - 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.
>
> Yes, that's a different mechanism from AF_PACKET.
>
> Does it allow receiving copies of packets that are also handed either to the
> kernel networking stack or to other AF_XDP sockets for regular input
> processing? That would be needed to allow it to be used for packet sniffing.
>
I haven't looked into it yet, but I'll keep that in mind when I do.
> > 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.
>
> That sounds like the behavior with a timeout set to 0 (with PF_PACKET
> sockets, BPF devices, and Solaris DLPI)
>
> > - (0): expose packets as soon as they arrive. This would act more or
> > less as previous AF_PACKET versions work.
>
> That sounds like immediate mode.
>
> > - A positive integer: this would be how long to wait
>
> If you mean "deliver a block if it's full or if the timeout expires", that
> sounds like the behavior with a non-zero timeout.
>
> So how does this differ from the regular timeout mechanism?
>
This mechanism would be for the AF_PACKET driver in the Linux kernel,
not for libpcap.
libpcap would only either set a small non-zero deadline on TPACKET_Vx
(x >= 3) or 0 for immediate mode, and just use the default behavior
for non-immediate mode.
The similarity with what libpcap does is not a coincidence.
> > (I haven't decided on the unit, I'm guessing microseconds should work).
>
> The units are milliseconds in pcap_set_timeout() and with BPF devices.
>
Yes, but for spacing between packets milliseconds may be to coarse.
> > I'm not sure regarding what the deadline is set, but I'm thinking
> > since the first packet in the block arrived.
>
> At least for BPF devices, it's "since a read or select was done", rather than
> "since the first packet in the block arrived"; I think it might be "since the
> first packet in the block arrived" with Solaris DLPI.
>
I should read that for inspiration, then.
> > 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?
>
> "The two lists" being this list and some Linux list?
>
> Is the Linux list linux-netdev?
Yes.
Addendum: I missed one, replacing some device detection boilerplate.
Initially. `if_nameindex` was proposed, but there's already the
`getifaddr` based implementation that should detect all Linux
interfaces usable by pcap by 2.3.x due to the fact that it counts
AF_PACKET addresses, so we should be able to just remove the
'/proc/net' and '/sys/class/net' crawling when we start expecting 2.4.
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
