From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mail.toke.dk (Postfix) with ESMTPS id 241968BEAF5 for ; Mon, 20 Sep 2021 13:48:57 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10112"; a="223157493" X-IronPort-AV: E=Sophos;i="5.85,308,1624345200"; d="scan'208";a="223157493" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Sep 2021 04:48:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,308,1624345200"; d="scan'208";a="556203349" Received: from irvmail001.ir.intel.com ([10.43.11.63]) by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2021 04:48:52 -0700 Received: from alobakin-mobl.ger.corp.intel.com (jmusial-MOBL1.ger.corp.intel.com [10.213.18.230]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 18KBmp6p015022; Mon, 20 Sep 2021 12:48:51 +0100 From: Alexander Lobakin To: Tom Herbert Subject: PANDA: Zabiplane reboot and XDP Hints Date: Mon, 20 Sep 2021 13:48:33 +0200 Message-Id: <20210920114833.196-1-alexandr.lobakin@intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: NOAQU7URMSOSTBAHIRIRD2BFR273XHOI X-Message-ID-Hash: NOAQU7URMSOSTBAHIRIRD2BFR273XHOI X-MailFrom: alexandr.lobakin@intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Alexander Lobakin , xdp-hints@xdp-project.net X-Mailman-Version: 3.3.4 Precedence: list List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Tom Herbert Date: Fri, 17 Sep 2021 11:35:41 -0700 > Hello, > > As you may recall, there was some initial work a while back on the > Zabiplane project as a ubiquitous, high performance networking > dataplane. For various reasons, that effort really didn't go very far, > however the intent and the principles behind it were correct and the > need in the industry for a ubiquitous, programmable, high performance, > and easy-to-use dataplane still persists. To that end we propose PANDA > as an open source project that achieves the goals but also addresses > the problems Zabiplane had. > > PANDA ties in well with XDP hints. Where XDP hints is about defining > the kernel/driver interfaces to allow devices to provide metadata > about packets, PANDA is the model allowing the stack to _program_ the > device to provide exactly the information it wants as XDP hints. This > programming includes not only the types of extracted metadata, but > also describes _how_ to programmatically produce the metadata. In > particular, PANDA is a common model for programmable parsers with > metadata extraction which is the device mechanism for things like XDP > Hints (pretty much every hardware vendor is developing hardware > parsers, PANDA would be the common means to get value from that). > > This programming is done explicitly through the stack as a form of > offload-- per the HW/SW offload equivalence principle, the kernel > stack and the device would run the exact same source code (hence why > P4 doesn't work). The net effect of this is that the device is now > operating under the direct auspices of the stack to the extent that > that stack boundary is extended _into_ the device. This means the > stack can now trust what the device is doing since it has full > visibility and control. In this way, we can go beyond just getting > simple "hints" and get pertinent operational information to the stack > from the device. For example, a programmable device should be able to > perform all the stateless processing for a TCP/IP packet such that the > stack could jump directly to TCP receive processing function > (borrowing from the goal of TXDP). As another example, a truly useful > LRO could be programmed in the device that would basically run the > same code as GRO and be equally extensible. > > If you are interested, please join the discussion list > PANDA.groups.io, or if you have any questions you can contact me Joined, thanks! > directly. Also, unlike Zabiplane, we are starting the PANDA effort > with contributions as opposed to manufacturing an open source project > from thin air (code for the PANDA parser is > https://github.com/panda-net/panda and we have also posted some RFC > patches on netdev for flower2 that uses PANDA) . > > Thanks, > Tom Al