[Cake] codel in ebpf?
toke at toke.dk
Fri Aug 3 06:19:04 EDT 2018
Dave Taht <dave.taht at gmail.com> writes:
> On Thu, Aug 2, 2018 at 1:04 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Dave Taht <dave.taht at gmail.com> writes:
>> > On Wed, Aug 1, 2018 at 10:25 AM Dave Taht <dave.taht at gmail.com> 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:
> 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
> 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,
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
More information about the Cake