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 A76A2C54EAA for ; Mon, 30 Jan 2023 14:42:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237805AbjA3OmZ (ORCPT ); Mon, 30 Jan 2023 09:42:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235759AbjA3OmY (ORCPT ); Mon, 30 Jan 2023 09:42:24 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CF581D93F for ; Mon, 30 Jan 2023 06:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding:Content-Disposition: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:From: Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Content-Disposition: In-Reply-To:References; bh=TfM2ehciCxuDO9aZadC7nXm35RgVlS2hj1lG/OodgEA=; b=CN 9B5xjb1mqY24du+h1I3aTrwTx+w+0w72kKnqll5haG9KKpgaLwrKDR9wE1D6gnsAxz6243PrbJByz lGzL2dAb8TpBcu1hE1+zeHBCLqKSI0ILn51/EVsfLPhEJxIyud58mVhndF4lgxyVJ5kD5tL/vivdR v+1Z7rz/Y2mT1yA=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pMVMI-003aDs-5a; Mon, 30 Jan 2023 15:42:10 +0100 Date: Mon, 30 Jan 2023 15:42:10 +0100 From: Andrew Lunn To: Jamal Hadi Salim Cc: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , Jiri Pirko , John Fastabend , Willem de Bruijn , Stanislav Fomichev , Jamal Hadi Salim , Jakub Kicinski , netdev@vger.kernel.org, kernel@mojatatu.com, deb.chatterjee@intel.com, anjali.singhai@intel.com, namrata.limaye@intel.com, khalidm@nvidia.com, tom@sipanda.io, pratyush@sipanda.io, xiyou.wangcong@gmail.com, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, vladbu@nvidia.com, simon.horman@corigine.com, stefanc@marvell.com, seong.kim@amd.com, mattyk@nvidia.com, dan.daly@intel.com, john.andy.fingerhut@intel.com Subject: Re: [PATCH net-next RFC 00/20] Introducing P4TC Message-ID: References: <63d6069f31bab_2c3eb20844@john.notmuch> <63d747d91add9_3367c208f1@john.notmuch> <87pmawxny5.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Jamal I'm mostly sat watching and eating popcorn, and i have little knowledge in the area. > Jiri, i think one of the concerns you have is that there is no way to > generalize the different hardware by using a single abstraction since > all hardware may have different architectures (eg whether using RMT vs > DRMT, a mesh processing xbar, TCAM, SRAM, host DRAM, etc) which may > necessitate doing things like underlying table reordering, merging, > sorting etc. The consensus is that it is the vendor driver that is > responsible for “transforming” P4 abstractions into whatever your > hardware does. What is the complexity involved in this 'transformation'? Are we talking about putting a P4 'compiler' into each driver, each vendor having there own compiler? Performing an upcall into user space with a P4 blob and asking the vendor tool to give us back a blob for the hardware? Or is it relatively simple, a few hundred lines of code, simple transformations? As far as i know, all offloading done so far in the network stack has been purely in kernel. We transform a kernel representation of networking state into something the hardware understands and pass it to the hardware. That means, except for bugs, what happens in SW should be the same as what happens in HW, just faster. But there have been mention of P4 extensions. Stuff that the SW P4 implementation cannot do, but the hardware can, and vendors appear to think such extensions are part of their magic sauce. How will that work? Is the 'compiler' supposed to recognise plain P4 equivalent of these extensions and replace it with those extensions? I suppose what i'm trying to get at, is are we going to enforce the SW and HW equivalence by doing the transformation in kernel, or could we be heading towards in userspace we take our P4 and compile it with one toolchain for the SW path, another toolchain for the HW path, and we have no guarantee that the resulting blobs actually came from the same sources and are supposed to be equivalent? And that then makes the SW path somewhat pointless? Andrew