From be44496b705f6ce8b7e43aa0fa6ddf35c7408e66 Mon Sep 17 00:00:00 2001 From: Frode Nordahl Date: Thu, 17 Feb 2022 14:30:00 +0100 Subject: [PATCH] smartnic-dpu: Update implementation details During the review of the Nova and Neutron implementations the wording used changed from "board serial number" to "card serial number". Partial-Bug: #1932154 Change-Id: Ib342351cad3ff1cd46016c1fcfe05e05bf92bf2b --- .../off-path-smartnic-dpu-port-binding-with-ovn.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/specs/yoga/off-path-smartnic-dpu-port-binding-with-ovn.rst b/specs/yoga/off-path-smartnic-dpu-port-binding-with-ovn.rst index 0ec17fa78..0a89c37c7 100644 --- a/specs/yoga/off-path-smartnic-dpu-port-binding-with-ovn.rst +++ b/specs/yoga/off-path-smartnic-dpu-port-binding-with-ovn.rst @@ -20,7 +20,7 @@ code relies on that. The goal of this specification is to introduce changes necessary to extend the existing hardware offload code to cope with the hostname mismatch and related design challenges while reusing the rest of the code. To do that, PCI(e) add-in card tracking is -introduced for boards with unique serial numbers so that it can be used +introduced for cards with unique serial numbers so that it can be used to determine the correct hostname of a SmartNIC DPU which is responsible for a particular VF. Additionally, more information is suggested to be passed in the "binding:profile" during a port update to facilitate @@ -169,7 +169,7 @@ Proposed Change Identifying a SmartNIC DPU Host and VF Representor -------------------------------------------------- -The related Nova specification [7]_ introduces add-in-card (board) serial +The related Nova specification [7]_ introduces add-in-card serial number collection via PCIe VPD and forwarding of that information in port updates to Neutron, therefore, it becomes possible to match that against what is seen at the SmartNIC DPU host side. Those serial numbers are unique, @@ -177,7 +177,7 @@ read-only, and assigned at the manufacturing time (per the PCI and PCIe specs). The board serial number can be stored in the OVN SB database as an external-id for a particular OVN chassis:: - external_ids:ovn-board-serial-number=UNIQUEBOARDSERIAL + external_ids:ovn-cms-options='card-serial-number=UNIQUEBOARDSERIAL' Note that there can be other means of accessing the NIC from the SmartNIC DPU host side (e.g. platform devices or other I/O types) so querying the serial @@ -185,7 +185,7 @@ number can be done either by extracting PCIe VPD via sysfs or by using devlink-info API and getting ``board.serial_number`` (which does not depend on a particular I/O interconnect type). However, this is a concern for OVN itself since Neutron does not have any agents running at the SmartNIC DPU side -- it only needs to look up a chassis by a ``ovn-board-serial-number`` +- it only needs to look up a chassis by a ``card-serial-number`` regardless of how it got collected at the SmartNIC DPU host. The responsibility of placing it there can be given to: @@ -198,7 +198,7 @@ The responsibility of placing it there can be given to: Regardless of the chosen method of populating this value, Neutron will then be able to lookup which OVN chassis should handle representor plugging and flow -programming for a particular port update that has a board serial included. +programming for a particular port update that has a card serial included. VF logical numbers are relevant in the context of a particular PF. In turn, PF logical numbers are tied to a particular controller. Since a NIC Switch is