From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E832F23A9; Sat, 15 Feb 2025 16:10:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739635846; cv=none; b=Cf1JJPGkNdZwH5s9fRtEQ9USDHOqti/EPUqoS408cly0amp1JkWHawQSTXaJZrpjCEok5QOqc9xntDOSf41BwJsaGuTn6TequswtgcXNVWalIKEnMaHPIBhqtoBX8ZOn5Kq7kH9OCzrilZDg0151nRXOWkkZSatxnc6whKfNRVU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739635846; c=relaxed/simple; bh=9s+IiJsEUk9aU24rG4a7pQ0sKjOHMDHvd8Goa1eO8Lo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N5F5PGFizcmF9IVidRsx4VrPyTqvydToeFBmHiKuMDqiYYznLa4XEwr0/yeGG/sH3tYLlrSotimFmeYODJN5/uLqXNuMY64tEQAj4TbR90v5jVHp4C0Qfg0SeVj2U/HGgxWHcXbNCunmtiTwvZFK0rivz2FMd6xXk1B42P8DEzw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V83/Jk4q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V83/Jk4q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF4B0C4CEDF; Sat, 15 Feb 2025 16:10:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739635845; bh=9s+IiJsEUk9aU24rG4a7pQ0sKjOHMDHvd8Goa1eO8Lo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=V83/Jk4qJm23lCL2iopygF9vkvI/eIYIR5p6ZCe+t2OLD+gMcxXdUgdCKcpxvP/hS eCs41y3gAcJm5KEix4csue3S8s8z/Ly+PMDhvrMH7N+E+hlMhQOpnEIIdPzpkryADP UGictaOpb7sxWwLf942PjV5D4QxRIxtzmXNAGlqpTf2Z8QVTgTXIeu1KuJKsuakqol JeSlcce1czwMpspQAjyDKBkBpCOnbtnnRZYH9wKkADw1AsDBseF5FYh6qhRD/0J0Sf G7x74L44CVjxmBxsXAW/UDFifjPtwRT2QIlbYznMFGEHhI8BUtFfTBngusuG3cxJ6N 1DIIxrFMe9sUw== Date: Sat, 15 Feb 2025 08:10:43 -0800 From: Jakub Kicinski To: Simon Horman Cc: Amit Cohen , Alexei Starovoitov , Petr Machata , "David S. Miller" , Eric Dumazet , Paolo Abeni , Andrew Lunn , Network Development , Ido Schimmel , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , bpf , mlxsw Subject: Re: [PATCH net-next 00/12] mlxsw: Preparations for XDP support Message-ID: <20250215081043.063e995a@kernel.org> In-Reply-To: <20250215140252.GP1615191@kernel.org> References: <20250205090958.278ffaff@kernel.org> <20250215140252.GP1615191@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 15 Feb 2025 14:02:52 +0000 Simon Horman wrote: > > TBH I also feel a little ambivalent about adding advanced software > > features to mlxsw. You have a dummy device off which you hang the NAPIs, > > the page pools, and now the RXQ objects. That already works poorly with > > our APIs. How are you going to handle the XDP side? Program per port, > > I hope? But the basic fact remains that only fallback traffic goes thru > > the XDP program which is not the normal Linux model, routing is after > > XDP. > > > > On one hand it'd be great if upstream switch drivers could benefit from > > the advanced features. On the other the HW is clearly not capable of > > delivering in line with how NICs work, so we're signing up for a stream > > of corner cases, bugs and incompatibility. Dunno. > > FWIIW, I do think that as this driver is actively maintained by the vendor, > and this is a grey zone, it is reasonable to allow the vendor to decide if > they want the burden of this complexity to gain some performance. Yes, I left this series in PW for an extra couple of days expecting a discussion but I suppose my email was taken as a final judgment. The object separation can be faked more accurately, and analyzed (in the cover letter) to give us more confidence that the divergence won't create problems. The "actively maintained" part is true and very much appreciated, but it's both something that may easily change, and is hard to objectively adjudicate. Reporting results to the upstream CI would be much more objective and hopefully easier to maintain, were the folks supporting mlxsw to "join a startup", or otherwise disengage.