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 8E83AC61DA4 for ; Tue, 14 Feb 2023 20:41:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231680AbjBNUlC (ORCPT ); Tue, 14 Feb 2023 15:41:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231812AbjBNUlB (ORCPT ); Tue, 14 Feb 2023 15:41:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 605ED2BED2 for ; Tue, 14 Feb 2023 12:40:57 -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 dfw.source.kernel.org (Postfix) with ESMTPS id EFF57618A8 for ; Tue, 14 Feb 2023 20:40:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EF7CC433EF; Tue, 14 Feb 2023 20:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676407256; bh=4zsZXfwf74bJFssWdqA5/Fmp6j9owfxJ5DruIC0CRlc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cSApAA81gbRcSLpxePoByN+UuTIDasnGq1o0isBWLvf6UINaXYrBwfsHE/k7fv0qa ONaaEOf2WxW12DT5Ow8LnmIFdx+hZDbaR6pRDFEb54HgQVYp0K+zMSphQkt082Boic DtQJEW6VzQDw+pGm0EmFLtQh6gVnWkyFGYgjMNnLJMtBaLeLRGJABsRZO/vVcrIXDa YEeScljqWkSyWt0cxXw0f2CsCv1F4UvJA/bRnpd/Bst1fu3c20O9UdVXBWd8mEnW1I X5PtY+YdehN1yDpNLtrY0Y7MWxgqoOoDXB5OeliRmWF4EkUOGy/fHYmAkate9uGeIr KYiaQHT5gycKA== Date: Tue, 14 Feb 2023 12:40:55 -0800 From: Jakub Kicinski To: Mark Bloch Cc: Saeed Mahameed , "David S. Miller" , Paolo Abeni , Eric Dumazet , Saeed Mahameed , netdev@vger.kernel.org, Tariq Toukan , Roi Dayan , Maor Dickman Subject: Re: [net-next 01/15] net/mlx5: Lag, Let user configure multiport eswitch Message-ID: <20230214124055.6e9df4dd@kernel.org> In-Reply-To: References: <20230210221821.271571-1-saeed@kernel.org> <20230210221821.271571-2-saeed@kernel.org> <20230210200329.604e485e@kernel.org> <20230213180246.06ae4acd@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 14 Feb 2023 09:31:10 +0200 Mark Bloch wrote: > > Oh, the "legacy software where updating the logic isn't possible" > > sounds concerning. Do we know what those cases are? Can we perhaps > > constrain them to run on a specific version of HW (say starting with > > CX8 the param will no longer be there and only the right behavior will > > be supported upstream)? > > While I can encourage customers to update their software to deal with > this new mode it's up to them. As you already know, it's hard to change > customers infrastructure so quickly. These things take time. They plan > on running multiple hardware generations on top of the same software. > I'll keep pushing on making this mode the default one. I think we should document some time horizon. We can always push it back but having a concrete plan in place may motive users. Also it's useful to point at and say "we warned you". Doesn't have to be anything very imminent, time flies.