From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 469A9C25B0E for ; Wed, 17 Aug 2022 01:23:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238108AbiHQBXe (ORCPT ); Tue, 16 Aug 2022 21:23:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237673AbiHQBXX (ORCPT ); Tue, 16 Aug 2022 21:23:23 -0400 Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 668C31081 for ; Tue, 16 Aug 2022 18:23:21 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id cd25so4669491uab.8 for ; Tue, 16 Aug 2022 18:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Misl/B06841rsdf51Aa+ttnbhsZR7d3YzAIKfH1afCM=; b=MG0YgAX5i1o7sBUDQM1NCnFgnxkQaaQm8ZOK13l79EOrXwG3hxCVCuxw53YmF/GPmG BotdAEanspQc99c8od7et+xJJfH666g+PKM2nqgz3aozMVwIaZpREipg9SXYXgriDnmG gd/gkMlKOf8PYpghcO3mkXIF7SKNqJjlKBYT913vJf9YESWgf8pX2vYoNDz1IqpbTxV3 ey8qpYsAzqcukQgw/XSXbpnh4iqMa5QXp6N0QLpAN0eT/f7DTXgLZh1huFFG57VyQyzn 6HWrAgsd8srbQ2yyjWgBYeijyKZyB2lbk+DexhRKJ/HbmCuh55PZoJ2SmQL/CWZeRD8m GOyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Misl/B06841rsdf51Aa+ttnbhsZR7d3YzAIKfH1afCM=; b=GP8PR72sqUQeR2OAMVjYCZahWeeYUb+oW7szLy3pzVjQiiG84x7tL6cdB82SPyTqIU D168TMTD/cDhU2pzSHV/17GYPILowCKkU1L0YMfEGjgmoglPqy2YNdzIyNBuUKk2YK6w 8JTFlnGjSR8rGMPQgBNNUaYr7ItE4ClVLMiZ7A3+vw230B5E1XlSK8hwMtZpDeLlhiIJ TF62bL1Hrejeo2IE5CpV3DbclE64FkXnyCAaYxpyrjmk1ra9+02ZFq6hZQWbABtKX4P/ Uu/uwJoT8Ctz1NJCPQ+VpdS+iReS9jDkONCeFbcJPHqfQ2tHtFZI3wFcPI4kn7efJBK0 niQw== X-Gm-Message-State: ACgBeo3uIXgY3PXmn+uiLUevg3vyLf0LJQowtEPMKoZ+la52Co/F6PCf K/1SVNb4bck1yMAMObcUZwGl0qdw5xEivm55cwOl8A== X-Google-Smtp-Source: AA6agR5ITNWjhKzMRt/O1Pao4VfpXIG2uEaU2CaLxbF3VzOqtgaIZ/UWesq0hyAy6dBXihAeRHYyLPGpOXaXwPHw0oU= X-Received: by 2002:ab0:785a:0:b0:386:d33c:d636 with SMTP id y26-20020ab0785a000000b00386d33cd636mr10128457uaq.87.1660699400464; Tue, 16 Aug 2022 18:23:20 -0700 (PDT) MIME-Version: 1.0 References: <5a93c5aad99d79f028d349cb7e3c128c65d5d7e2.1660362668.git.bobby.eshleman@bytedance.com> <20220816123701-mutt-send-email-mst@kernel.org> <20220816110717.5422e976@kernel.org> <20220816160755.7eb11d2e@kernel.org> In-Reply-To: <20220816160755.7eb11d2e@kernel.org> From: "Cong Wang ." Date: Tue, 16 Aug 2022 18:23:09 -0700 Message-ID: Subject: Re: [External] Re: [PATCH 3/6] vsock: add netdev to vhost/virtio vsock To: Jakub Kicinski Cc: Bobby Eshleman , Bobby Eshleman , "Michael S. Tsirkin" , Bobby Eshleman , Jiang Wang , Stefan Hajnoczi , Stefano Garzarella , Jason Wang , "David S. Miller" , Eric Dumazet , Paolo Abeni , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 16, 2022 at 4:07 PM Jakub Kicinski wrote: > > On Tue, 16 Aug 2022 07:02:33 +0000 Bobby Eshleman wrote: > > > From a cursory look (and Documentation/ would be nice..) it feels > > > very wrong to me. Do you know of any uses of a netdev which would > > > be semantically similar to what you're doing? Treating netdevs as > > > buildings blocks for arbitrary message passing solutions is something > > > I dislike quite strongly. > > > > The big difference between vsock and "arbitrary message passing" is that > > vsock is actually constrained by the virtio device that backs it (made > > up of virtqueues and the underlying protocol). That virtqueue pair is > > acting like the queues on a physical NIC, so it actually makes sense to > > manage the queuing of vsock's device like we would manage the queueing > > of a real device. > > > > Still, I concede that ignoring the netdev state is a probably bad idea. > > > > That said, I also think that using packet scheduling in vsock is a good > > idea, and that ideally we can reuse Linux's already robust library of > > packet scheduling algorithms by introducing qdisc somehow. > > We've been burnt in the past by people doing the "let me just pick > these useful pieces out of netdev" thing. Makes life hard both for > maintainers and users trying to make sense of the interfaces. I interpret this in a different way: we just believe "one size does not fit all", as most Linux kernel developers do. I am very surprised you don't. Feel free to suggest any other ways, eventually you will need to reimplement TC one way or the other. If you think about it in another way, vsock is networking too, its name contains a "sock", do I need to say more? :) > > What comes to mind if you're just after queuing is that we already > bastardized the CoDel implementation (include/net/codel_impl.h). > If CoDel is good enough for you maybe that's the easiest way? > Although I suspect that you're after fairness not early drops. > Wireless folks use CoDel as a second layer queuing. (CC: Toke) What makes you believe CoDel fits all cases? If it really does, you probably have to convince Toke to give up his idea on XDP map as it would no longer make any sense. I don't see you raise such an argument there... What makes you treat this differently with XDP map? I am very curious about your thought process here. ;-) Thanks.