From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3F6A43B29E for ; Fri, 3 Aug 2018 06:19:09 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1533291548; bh=APepIpnlpb0Nr9ArTBbQZJCleBF6Of0NU3efc9kttWw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OXve02iAoOMyWOs3yFSXqPVVlUJ8UlNa6BpHR0BlbufhPHwIATgl1Wu9A08Rk63O1 bq3HQNNf2YM/asoPmmy7JKZcZgLE4+vk77ayp1wHED2TRwwHzZu/ExrUcSRJc4JiQX k4NypvXywDiproEFEFfk2XssTSimvC6hspn1T9jgOSPm32eOjxVMJZEu2JJs91Ysyd +8Bzy5gG8ApxTmsbnFGzpsLD2JUKZRQT9MoxYHe+hCgkFt4yqDjcu2ga2v0jiSSprU WEtp7zLmw0vW5Wl0wpNByl1F9QKpKAQGYY9y4vTH/nRvkJFB9s7ZTJT44Fpp32Mcf0 aROnoJeR4VtMw== To: Dave Taht Cc: Jonathan Morton , Cake List In-Reply-To: References: <87ftzwy1pw.fsf@toke.dk> Date: Fri, 03 Aug 2018 12:19:04 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sbfycpz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] codel in ebpf? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 10:19:09 -0000 Dave Taht writes: > On Thu, Aug 2, 2018 at 1:04 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> Dave Taht writes: >> >> > On Wed, Aug 1, 2018 at 10:25 AM Dave Taht 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 qdi= sc > 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