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 E855E3CB39 for ; Sat, 28 Mar 2020 15:58:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585425496; 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=OoVfpBC7776WyFS0fh2ijfK5yZblFwlJEc3KMMAGhbpiF8rb7HA4iMDZSp0ycRfK94BUZT kAsMYZIbfn9sSUgD2+K3Qi95yORCx1hfvl/qwg43Mz6LnLr5SZA0EmvTBjyJ9vHMIxF18k 1JAtw5BHN3mWnTnFFdw6MRBXmstemA4= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-451-eDsVLFafNte6PSieFE23Yg-1; Sat, 28 Mar 2020 15:58:12 -0400 X-MC-Unique: eDsVLFafNte6PSieFE23Yg-1 Received: by mail-lf1-f70.google.com with SMTP id p8so2006334lfc.8 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=RlB99qLTEytlZ81upI6wwPx119aXPDWsd0YUqdz2ve7d9SUIKLb9uKBDP8/p2uEbda ZXq64nhN5T4ZebeHeCm5vgH0onO8GiSVjuVPrirO7Tzm5e8pIfMHwQHzNvLpjN8f7HmK HRT5L0sBX2iL5hQkdNjY/GA3oJ28L0G8IoS6vGZLfkIVlo/YjYInC9ReLLG4l6WOJ78M nVLoN1vAkVSQ2pQEE74MPadrc3PlyXHF998svhNxoJy4G+hGEcA9THer8d6/J3f35qNV ek6UZ84vllH1aJQ687MAgqfmt8wF88v+ZGGfL8hFs2CJuN0gk4vzB890N1nZ1Lzj4kLg dTYg== X-Gm-Message-State: AGi0Pubr49ihKyQu2HC4byORsn4xp19kcVlTzlw8RHpW2A3DVQhFrEDd UGgBm/X2MoqY9W+vsExKXLQrvf4YUCCnUB2s9hpFXR1gVGZf8SYChA8nCJi/ZL57tp0VC0/V8Gz v+mLFSgxoHI3GZmkzmxcrzrI= X-Received: by 2002:a2e:9757:: with SMTP id f23mr2836224ljj.269.1585425491023; 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: [Bloat] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 19:58:17 -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