Dave Taht <[email protected]> writes: > On Thu, Aug 2, 2018 at 1:04 PM Toke Høiland-Jørgensen <[email protected]> wrote: >> >> Dave Taht <[email protected]> writes: >> >> > On Wed, Aug 1, 2018 at 10:25 AM Dave Taht <[email protected]> wrote: >> >> >> >> I wonder if ebpf has opcode space for an invsqrt? >> > >> > bpf_ktime_get_ns() exists... >> > >> > one thing that I don't know if bpf can do is read/write the >> > skb->tstamp field. The plan would be to rigorously write it (if not >> > supplied by hw) on all ingress ports and check it on all egress ports. >> >> An XDP eBPF program (run at earliest possible ingress) has access to a >> buffer of arbitrary data that is attached to the skb and that can be >> read from later eBPF programs. So it doesn't need to muck with >> skb->tstamp for this. > > It does? All I see is maps.
See bpf_xdp_adjust_meta() - some description here: http://cilium.readthedocs.io/en/latest/bpf/#program-types > If you clone or otherwise split the packet, what happens? Hmm, good question; I *think* the metadata is tied to the skb, so I guess it should also be copied? >> Yeah, it is. Don't think there's a way to run an eBPF program after the >> qdisc... > > Well, it seems possible to move this typical part of an ebpf specific qdisc > from ingress to egress. Gawd knows what that would break, but, > essentially.... Well for one thing that would break the TC classification. And you'd have to implement a new qdisc to do it; at which point, you might as well implement the queueing there? But maybe a new generic eBPF hook could be added to the qdisc dequeue code? If there's a compelling use case, I've heard that the kernel people can be quite responsive for new features :) -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
