Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-2932

SDP Receive for CSP PSI-Low Data Capture

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • Data Processing
    • Hide

      Integration and demonstration of CBF to SDP signal chain data capture using PSI-Low enables exercising and validating the ICD.

      Show
      Integration and demonstration of CBF to SDP signal chain data capture using PSI-Low enables exercising and validating the ICD.
    • Hide
      • Successful configuration of network topology: receive pod mounts physical NIC, we test that it implements ARP + SPEAD as per the ICD. No need for the P4 switch to be involved in any of this.
      • A single visibility receive pod can capture multiple SPEAD streams.
      • SDP receive address(es) configurable per channel (possibly just processing block parameters, ideally think about how the processing script might allocate them)
      • Stretch: SPEAD data flows through the P4 switch. This implies that ARP requests are sent by the P4 switch that are acknowledged by the receiver pods.
      • Stretch: Multiple visibility receive pods deployed on different host nodes capture SPEAD streams in parallel.
      Show
      Successful configuration of network topology: receive pod mounts physical NIC, we test that it implements ARP + SPEAD as per the ICD. No need for the P4 switch to be involved in any of this. A single visibility receive pod can capture multiple SPEAD streams. SDP receive address(es) configurable per channel (possibly just processing block parameters, ideally think about how the processing script might allocate them) Stretch: SPEAD data flows through the P4 switch. This implies that ARP requests are sent by the P4 switch that are acknowledged by the receiver pods. Stretch : Multiple visibility receive pods deployed on different host nodes capture SPEAD streams in parallel.
    • Inter Program
    • 5
    • 5
    • 0
    • Team_YANDA
    • Sprint 5
    • Hide

      AC1 to AC3 were met and demoed https://confluence.skatelescope.org/display/SE/2023-02-15+DP+ART+System+Demo+17.5

      Stretch including multiplicity of pods and nodes could not be achieved and are ticketed as SP-3259 in PI18.

       

      Addendum:
      Following a requested at the objective review on 23/02/2023, here is a paragraph on the risk reduction associated with this work.

      After CDR and as outlined in ROAM-356 there have been a number of uncertainties accumulating around the CBF SDP interface. In collaboration with Perentie (CBF Low), Viola (PSI Low) and Orca (SDP software) it has now been demonstrated/determined that the SDP Receiver, running inside a k8s cluster, can receive data from an external SPEAD source using the network interface dedicated to communications with CBF. For AA0.5 the network configuration as it stands on PSI Low was made to work for a multi channel Receiver deployed on a single pod, demonstrating that multi-stream (i.e., multi-port) reception also works as expected.

      Show
      AC1 to AC3 were met and demoed https://confluence.skatelescope.org/display/SE/2023-02-15+DP+ART+System+Demo+17.5 Stretch including multiplicity of pods and nodes could not be achieved and are ticketed as SP-3259 in PI18.   Addendum: Following a requested at the objective review on 23/02/2023, here is a paragraph on the risk reduction associated with this work. After CDR and as outlined in ROAM-356 there have been a number of uncertainties accumulating around the CBF SDP interface. In collaboration with Perentie (CBF Low), Viola (PSI Low) and Orca (SDP software) it has now been demonstrated/determined that the SDP Receiver, running inside a k8s cluster, can receive data from an external SPEAD source using the network interface dedicated to communications with CBF. For AA0.5 the network configuration as it stands on PSI Low was made to work for a multi channel Receiver deployed on a single pod, demonstrating that multi-stream (i.e., multi-port) reception also works as expected.
    • 18.2
    • Stories Completed, Integrated, Solution Intent Updated, BDD Testing Passes (no errors), Outcomes Reviewed, NFRS met, Demonstrated, Satisfies Acceptance Criteria, Accepted by FO
    • PI23 - UNCOVERED

    • LOW_SUT1 YANDA
    • SOL - G1

    Description

      During SP-2528 it was demonstrated that a pod running within a k8s cluster could be configured in such a way that the P4 switch could send ARP requests for its MAC address and the pod would respond successfully. This in turn configures the switch to know which port to use to forward the SPEAD packets coming from CBF into the corresponding SDP receiver node. However, during that exercise no actual SPEAD data was exchanged. Moreover, the pod used for the experiments wasn't the receiver pod, but a custom one that had all the metadata needed for the experiment to succeed. While a useful and big advance in the right direction, there is still work left to be done to ensure visibility data can be exchanged between CBF and SDP.

      This feature should ensure SPEAD data can be exchanged on the PSI environments. Given the previous steps, the following items need to be clarified or worked on:

      • Firstly, this experiment was performed on the LOW PSI. Is it expected that a similar setup will be available on the MID PSI, and therefore the same solutions apply to both environments?
      • The solution used to have a k8s pod respond to ARP requests was to configure it with a CNI plug-in and enable it to use the host interface directly. To this effect, the pod specification needs to be told the interface to use (its PCI bus ID) and the IP to set on that interface.
        • Does this works/scales if we use multiple ports in the same pod? and multiple pods in the same node? and multiple nodes?
        • How does usage of this plug-in affect the Service definitions laid on top pods? Are Service definitions required in the first place?
        • The receive chart needs modifications to receive this configuration
      • If IPs and PCI bus IDs need to be passed down the system, who's responsibility is that? The easiest solution is to pass down these values via PB parameters, such that the vis-receive script can both put them in the receive chart, and use them to re-calculate the receive addresses that are communicated to CSP, inserting the IPs from the PB in place of the k8s hostnames
      • If the receive chart still needs to define externally-visible services, the chart needs further modifications to setup NodePort services for each of the ports it will listed data on.
      • Data exchange should happen using Jumbo frames, we need to investigate if/how k8s supports this.

      Once those items are tackled, we should be able to test an integrated system on the LOW PSI with SPEAD visibility data travelling into a receiver pod started via the usual SDP Tango interfaces.

      All of the above applies to multiple nodes rather than a single receive pod.

      For some further details on the setup used during SP-2528 please visit https://confluence.skatelescope.org/display/SWSI/PSI+Low+Deployment+and+Operations#PSILowDeploymentandOperations-Low-levelaccesstonetworkinterfacesandadditionalinterfaces

       

      Attachments

        Issue Links

          Structure

            Activity

              People

                p.wortmann Wortmann, Peter
                m.dolensky Dolensky, Markus [X] (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 5.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete1323.0
                  Total1323.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel