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 [216.205.24.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 299503B29E 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-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-317-uZY5KUtaNQCQ14s2vuTZAg-1; Sat, 28 Mar 2020 15:58:12 -0400 X-MC-Unique: uZY5KUtaNQCQ14s2vuTZAg-1 Received: by mail-lf1-f71.google.com with SMTP id b25so5480375lfi.21 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=atLLjl+jfWrog0VvVLmOBcF8lWJbS4GJJHnADxTtfqoIJKSUhVb8KdrjRUbF0zO0U9 yAaeqjh2dzP4ne/aX3TH4zieH2CzZ3JdWj8uVdKlAox16fv6DfHNL1kyoZitZ7554W49 UPfDW3BzUBT/qIxCRrRJokIHrDfSMRNCQWedQ183tYGb5SLJJD1nXSlQUT7kp0ao/jGq lGzWcFuzUCBF5x7y2wL+p96Wh+gusXzDplw98gccfRKUsN4eRj5cC7+pxhNrc16wa1MJ CQKjLNumrRrntCSItw02i7Xu1w6advFSzKDOx+O47hsZBKWU8i8R7vFn5vgdqGhG5oMq 67Ig== X-Gm-Message-State: AGi0PuYvuy2uZAC/+Pp4sXW0InKCvHnvcOzyBLdu2Yr3T1ekS5UtjUD3 6Qp68i1i7fsHOhHGVY5J3BoMn9vmCk+tF1F0RavE7bz1dQDvfXLnfQPf7tEKDSHYozhN/2ArGPt XRIy4+G0c0UUsty3qYJSoXy2O7gdN8AiQQGw= X-Received: by 2002:a2e:9757:: with SMTP id f23mr2836236ljj.269.1585425491128; 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: [Make-wifi-fast] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: 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