[Cake] codel in ebpf?

[Toke Høiland-Jørgensen]

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:
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