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 869FFC4332F for ; Fri, 9 Dec 2022 01:58:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230128AbiLIB6f (ORCPT ); Thu, 8 Dec 2022 20:58:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230133AbiLIB6E (ORCPT ); Thu, 8 Dec 2022 20:58:04 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FEC06FF31 for ; Thu, 8 Dec 2022 17:58:01 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 38978B82707 for ; Fri, 9 Dec 2022 01:58:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C182EC433EF; Fri, 9 Dec 2022 01:57:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670551078; bh=jX2AXJWBy+qdj/R0QS+Gg2E2kfiAjkXSPViHZ/ccVq0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Sti/52Xca2mUc2qYn1+RmRMHPialKshNE5MLUhtzhVanWEJUk0UdzE6DZXZX630xl lw6uR2t/5cVQXdSTsPhszjrJh1SSj3M9rm7OgnkQ9lzTAgh7bSs3z66o061QXDf0ot 5JxmfItai7wcbR7g4SM3O3KVjP94gOw63pCYbe6Joe2aniHotBfHL40PMpTIurxKOA Y6AvtxqwqupOyaK0Zey9cCet8lFvFNvv07lvN3CiQgpRVTif0w/VRvP1hd5i2UK3rv 7DZG/GM7GhNyOexA39bCZYlip2r4I2fW2oo3PfaIW2QgdhRBTexVnuvL0NvBVaPT03 zcx2flongvAEw== Date: Thu, 8 Dec 2022 17:57:57 -0800 From: Saeed Mahameed To: Jakub Kicinski Cc: Saeed Mahameed , "David S. Miller" , Paolo Abeni , Eric Dumazet , netdev@vger.kernel.org, Tariq Toukan , Moshe Shemesh , Mark Bloch Subject: Re: [net-next 14/15] net/mlx5: SRIOV, Add 802.1ad VST support Message-ID: References: <20221203221337.29267-1-saeed@kernel.org> <20221203221337.29267-15-saeed@kernel.org> <20221206203414.1eaf417b@kernel.org> <20221207092517.3320f4b4@kernel.org> <20221208170459.538917da@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221208170459.538917da@kernel.org> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 08 Dec 17:04, Jakub Kicinski wrote: >On Thu, 8 Dec 2022 00:28:38 -0800 Saeed Mahameed wrote: >> So if the part in this series of adding support for 802.1ad, falls under that >> policy, then i must agree with you. I will drop it. > >Part of me was hoping there's a silver bullet or a compromise, >and I was not seeing it.. :) > >> But another part in this series is fixing a critical bug were we drop VF tagged >> packets when vst in ON, we will strip that part out and send it as a >> bug fix, it is really critical, mlx5 vst basically doesn't work upstream for >> tagged traffic. > >What's the setup in that case? My immediate thought is why would >VST be on if it's only needed for .1ad and that's not used? So the whole thing started from finding these gaps in our out of tree driver. there's the bug fix i will explain below, and the addition of .1ad both were found missing upstream when we convinced a customer to switch to upstream/inbox driver. vst .1q and vst .1ad are both totally separate scenarios and use cases for the customers. Currently upstream mlx5 only support VST for vlan proto .1q, but it's buggy when traffic from the guest comes with a vlan tag, depending on the HW/FW version, either the packets get dropped or the guest vlans get overridden with the VST host vlan, this is due to wrong interpretation of the hw steering rules in the initial driver implementation. in both cases it's a bug and the latter is even worse.