From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=DATE_IN_PAST_12_24, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 25732 invoked from network); 18 Dec 2023 16:37:05 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2023 16:37:05 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 9front; Sun Dec 17 16:08:46 -0500 2023 Message-ID: <07A941FBFC8DA8FE7E43834692DFC459@felloff.net> Date: Sun, 17 Dec 2023 22:08:36 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <1537051341.3430184.1702834009641@comcenter.netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extended structured pipelining STM property frontend Subject: Re: [9front] [patch] ethervirtio - fix multicast without a cmd queue Reply-To: 9front@9front.org Precedence: bulk I dont follow. this doesnt change the fact that we'r not really enabling mcast reception or not. all it does is make it FAIL silently. Are you saying that the cmd is not needed for devices that do not have cmd queue and always are in promisc mode so to speak? If thats the case, add a comment in the code why we'r basically doing nothing and why that is ok. -- cinap