From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AA3F23CB35 for ; Sat, 28 Mar 2020 15:58:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585425494; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X0W13ZR8OK6A0LCu6SU3hZ2sjSiwybH3M4Yx3ll1vXE=; b=fvobG0ffyVOSTD6MhNZQTyK3DpAwAzDxXYM2qIjbSTJeKMU8HTOlxPEzyW7l9ZNEisC7Ck 1RXih0ECSTds44yMXKg+Z/f+J/1w1WqPmhQgeHQJuqilShhh+1t0HphOv+HJaA76/TB9VB z/NEgmgYTj+3cocFNo2oG9qfYQQTyDU= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-436-j-a8qAKzPciY-D02-T_x8w-1; Sat, 28 Mar 2020 15:58:12 -0400 X-MC-Unique: j-a8qAKzPciY-D02-T_x8w-1 Received: by mail-lf1-f72.google.com with SMTP id c22so2775020lfb.14 for ; Sat, 28 Mar 2020 12:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=X0W13ZR8OK6A0LCu6SU3hZ2sjSiwybH3M4Yx3ll1vXE=; b=naYzNK7Wt/JARByt/IjYhAE6S0zDHhv2IvYwK/6GpqFXuCl9zEY91P9sUAK2X6tqSu NTCVOrJEN88UO4OtbucqcDl61iTAt1yTDzP2wrr+bYEFvydze+HuMWMA9qcjc6/i1FNi o4ks2dlJw8/WxdonjBAmMs+cgDvrZC0srMVK/AhnLwtPgfI4AJMhw+f+A74EMfqe+kvP RPZtZz1qIAAFqX+NzfbRtNn0Opy31D8i+z7jt3x2X8cRavzWLCbLGjY/9JZ97kqyp1bS 0CE6646xmr3+f2XtOoawcO8d3Ys+JwE+XZagBMxjWTNSdlq+3vCAcnz+aA9wAGdXwTUx Iegw== X-Gm-Message-State: AGi0PuZF2vrwcKht1g+2esI6/k06OQpUAwyVIXEhz0T9g1a5QSCRmeS/ q9jaoOaBrA9pAMTdcUNTs3qM1fcgJ7OfvjKDZyiJxJ4Iff4b4SQRx5mouPqjeLMjADI/B+pFmV6 A1iWyJ2uWpV1C+V9VhH41oA== X-Received: by 2002:a2e:9757:: with SMTP id f23mr2836234ljj.269.1585425491125; Sat, 28 Mar 2020 12:58:11 -0700 (PDT) X-Google-Smtp-Source: APiQypJ7vkGFp2jEgE/fIb1d6LH2TJScU7xorzZbUbLh5epUrNRP11bNad+0S5LsQewjX6ESAsTPfw== X-Received: by 2002:a2e:9757:: with SMTP id f23mr2836218ljj.269.1585425490831; Sat, 28 Mar 2020 12:58:10 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id y26sm3345794lfl.95.2020.03.28.12.58.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Mar 2020 12:58:10 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 57E5C18158B; Sat, 28 Mar 2020 20:58:08 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht , "David P. Reed" Cc: Make-Wifi-fast , Anthony Minessale II , Cake List , Ken Rice , cerowrt-devel , bloat In-Reply-To: References: <1585335604.839628636@apps.rackspace.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 28 Mar 2020 20:58:08 +0100 Message-ID: <878sjkl0a7.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks? 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: Sat, 28 Mar 2020 19:58:15 -0000 Dave Taht writes: >> So: 1. We really should rethink how timing-sensitive algorithms are >> expressed, and it isn't gonna be good to base them on semaphores and >> threads that run at random rates. That means a very different OS >> conceptual framework. Can this share with, say, the Linux we know and >> love - yes, the hardware can be shared. One should be able to >> dedicate virtual processors that are not running Linux processes, but >> instead another computational model (dataflow?). > > Linux switched to an EDF model for networking in 5.0 Not entirely. There's EDT scheduling, and the TCP stack is mostly switched over, I think. But as always, Linux evolves piecemal :) >> 2. EBPF is interesting, because it is more secure, and is again >> focused on running code at kernel level, event-driven. I think it >> would be a seriously difficult lift to get it to the point where one >> could program the networked media processing in BPF. > > But there is huge demand for it, so people are writing way more in it > than i ever ever thought possible... or desirable. Tell me about it. We have seen a bit of interest for combining eBPF with realtime, though. With the upstreaming of the realtime code, support has landed for running eBPF even on realtime kernels. And we're starting to see a bit of interest for looking specifically at latency bounds for network processing (for TSN), including XDP. Nothing concrete yet, though. -Toke