From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by mail.toke.dk (Postfix) with ESMTPS id 14E128BDBCA for ; Fri, 17 Sep 2021 20:35:56 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key) header.d=sipanda-io.20210112.gappssmtp.com header.i=@sipanda-io.20210112.gappssmtp.com header.b=R5G5fsvT Received: by mail-pj1-x102c.google.com with SMTP id n13-20020a17090a4e0d00b0017946980d8dso10626886pjh.5 for ; Fri, 17 Sep 2021 11:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sipanda-io.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=RQz0HBa237orvU02L0BUE1Sdyiicm5tWKJYNaVd0mZ8=; b=R5G5fsvT79Ayk31klSxUfA/w/V3Ji9ldR08BrbsinMX6g3Cc6jSs3sFkzVjbj25nqX fSw6JWisv7/qIzKXXmu3W56aNwmyaVmxogfOUIfCFHXJOeiVX5o2cq6kSW19QjB/XSyu t3AiU4PYigmYeumed6sEomRJ/y4SN5kPCQp0pojfkyenCj9cMWqWwCf0qPBnZFjpTAvP 0rSI/n+hzLmreZc0koDk8KYha69wVMW9PsX0MXv4cV8MlEweEyNlbnjlZzUCSdngDhlh fvhI7As/qYJNGCFfqC95hQ8ojIa4cCiB10PjwuGupNSNNZLUOHXmxRs6gJ1sa/Npf2um +MzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RQz0HBa237orvU02L0BUE1Sdyiicm5tWKJYNaVd0mZ8=; b=YrPXmnPZ41dVhBYRsXmcBFwsx9KURqSYpdw7/Qg4QYnP0AMS8DtVG3E6wTRJOtEjoI zmYVIj6WWYUh0ueM0Ah9Yi4KqBT8GS7d6GDoN7XY6zLi3Lk775uNTlcTDDsZL4Oay3L4 ClAI2SGvxsa44QSHoQ1ee60E5kI5faajia1gjhy4Mfvmd2BxIC9U3B823IbHWCCGoG6k +8lCRZERysiBW2pNfPGMzDe92cCWt0NkIMcgh3iqZjC5W0N164OoRHQ3niZqENOluKTD IgIrmFnjBLXzBJYMl/VRD7VDQ7vZnbf7x6HcnT88Gd8Y8nFEazFYwL8R9LU1kkcRN2lp WOdw== X-Gm-Message-State: AOAM530m+7urstIOqJ9DTl0hvO/dnOmPEaRvXCLW+aVxumzq+ktabxqg qXtvrryoXfht2rrSFZpv0zIcK38DpGemAVguEGKftYMdaU7HoQ== X-Google-Smtp-Source: ABdhPJzx/YrZ0+IZrQ1idH0vSaKFb34+BZ5dG7hTNEOdOnx5vC8G3C+g1UijvVbhPWO0nTVqTW/b1CUzh//mi0Yjzi0= X-Received: by 2002:a17:90b:1488:: with SMTP id js8mr14184032pjb.41.1631903754019; Fri, 17 Sep 2021 11:35:54 -0700 (PDT) MIME-Version: 1.0 From: Tom Herbert Date: Fri, 17 Sep 2021 11:35:41 -0700 Message-ID: Subject: PANDA: Zabiplane reboot and XDP Hints To: xdp-hints@xdp-project.net Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: ZBN6NJHI5J4R2U4G4MELGFHO42QWGCJX X-Message-ID-Hash: ZBN6NJHI5J4R2U4G4MELGFHO42QWGCJX X-MailFrom: tom@sipanda.io 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 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: 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 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