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 ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D3503C04A6A for ; Tue, 8 Aug 2023 04:22:47 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 3E67E2B003 for ; Tue, 8 Aug 2023 04:22:47 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 3ABB09864A1 for ; Tue, 8 Aug 2023 04:22:47 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 2E755986461; Tue, 8 Aug 2023 04:22:47 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 1CC4F986460; Tue, 8 Aug 2023 04:22:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046049;MF=xuanzhuo@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0VpJg.RQ_1691468556; Message-ID: <1691468213.0926805-6-xuanzhuo@linux.alibaba.com> Date: Tue, 8 Aug 2023 12:16:53 +0800 From: Xuan Zhuo To: Parav Pandit Cc: "virtio-dev@lists.oasis-open.org" , "virtio-comment@lists.oasis-open.org" , "Michael S. Tsirkin" , Jason Wang References: <20230803083150.46745-1-xuanzhuo@linux.alibaba.com> <20230803054333-mutt-send-email-mst@kernel.org> <1691059929.235804-1-xuanzhuo@linux.alibaba.com> <1691060652.3764465-2-xuanzhuo@linux.alibaba.com> <1691061508.9066079-5-xuanzhuo@linux.alibaba.com> <1691062204.2378864-7-xuanzhuo@linux.alibaba.com> <1691062877.0013635-8-xuanzhuo@linux.alibaba.com> <1691129914.3255427-1-xuanzhuo@linux.alibaba.com> <1691132049.7182267-2-xuanzhuo@linux.alibaba.com> <1691135097.4908528-3-xuanzhuo@linux.alibaba.com> <20230804053958-mutt-send-email-mst@kernel.org> <1691388171.3192031-1-xuanzhuo@linux.alibaba.com> <1691462188.324996-1-xuanzhuo@linux.alibaba.com> <1691467247.671468-4-xuanzhuo@linux.alibaba.com> In-Reply-To: Subject: [virtio-dev] Re: RE: RE: RE: RE: RE: RE: [virtio-comment] RE: RE: RE: RE: [RFC] virtio-net: support access and control the member devices On Tue, 8 Aug 2023 04:11:03 +0000, Parav Pandit wrote: > > > > From: Xuan Zhuo > > Sent: Tuesday, August 8, 2023 9:31 AM > > > > On Tue, 8 Aug 2023 03:16:44 +0000, Parav Pandit wrote: > > > > > > > > > > From: Jason Wang > > > > Sent: Tuesday, August 8, 2023 8:39 AM > > > > > > > > > > > Yes, but even for TX, would it be better to filter the IP as early > > > > as possible in the TX path other than depend on the switch to do that? > > > > > > The idea is to introduce filters on the new virtio switch object for tx and rx > > both. > > > > Filters for tx? > > > Yes. the regular switchdev model that exists in Linux kernel for several years now. > And similar in another hypervisor. > > > Are there other use cases? > > > > > > > > A virtio switch object can be part of a existing virtio device or a new virtio > > device type in itself. > > > > > > Xuan, > > > As we discussed, since the owner device packets also needs to be > > > filtered, potentially outside of the owner device itself, > > > > > > Do you see the need to introduce virtio switch object now, or can it wait? > > > > For virtio switch, I am ok. > > > I didn't follow your answer "I am ok". > Do you see the need now or can it wait? > > > But for me, I just have this requirement that needs the switch. > > > So if we do this in the device, then that is not need for me. > > > Device meaning outside of the virtio domain, for example dpu or something else, yes? NO. I mean the virtio-net device. > > > Now, you think we should introduce the rx/tx filter to the virtio switch. > > > I am asking to _not_ introduce currently. I don't care whether swtich is introduced or not. Because we have no dependencies on it. My requirement is to implement ip restriction which is very important for cloud scenarios. I think the gap is, I don't care how it's implemented. Because for me, it can be supported by switch rx, tx filter or virtio-net device. I'd love to hear everyone's opinions. Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org