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 A7F7F3B29E 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-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-280-wthkKgOVPaWLbF51Vy24mw-1; Sat, 28 Mar 2020 15:58:12 -0400 X-MC-Unique: wthkKgOVPaWLbF51Vy24mw-1 Received: by mail-lf1-f69.google.com with SMTP id j3so5519620lfe.10 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=OYqUoQVBvgt3ELP+N4Rm5WqkRxh4Pr5YLtZROYWMq2cZikr/iDSxG0ogBNdlYOLL5V SoBN5XS3gLSMmCcV3LEurg0D7nRYx0oeApYZAhR/lUUisTbGjjI2cuPDVUFstkG1XSJY Nq0qVJbebtTb96wYf+9SZSk30wITrcsmsqwg4EkMyDKVLpelBuDvtvFHQW+1UOUdHwV+ IEcN7gojAQfF0+I7J/EtW/TxGuU7TcytuRkB0aMvwj2b34sPJHmeiB21bF8n+YtsLldv cUjiL1+rilImAk9UdWuhAXx69rCUKqjIe9t9Ju2+/hMVwD2W9JX1giVY7WhtUP5dcccK m7FA== X-Gm-Message-State: AGi0Pua04KOPhnzY/e3q60ZMd+OWdfA1yFk4RO2qEaTxl93UZraDaetW DZabD6lWdtZF4tOMf0VDoVuF7quyYG8HYvrM92BLh+z1yM0055KOijIQnDXIdB8GdyN5obv4//Z yxmYsNa+ePGnbqFfm2ac1JYuxGaM4FzzJOA== X-Received: by 2002:a2e:9757:: with SMTP id f23mr2836233ljj.269.1585425491113; 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 X-Mailman-Approved-At: Mon, 30 Mar 2020 07:21:13 -0400 Subject: Re: [Cerowrt-devel] [Cake] mo bettah open source multi-party videoconferncing in an age of bloated uplinks? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project 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