Wiki

Weekly Update:

• I would like to highlight the *VERY FIRST* contribution from an OPNFV project that has been up-streamed to an open source project. This contribution took the form of 2 commits (specified below) to www.dpdk.org. These 2 commits enable the callback infrastructure that enables additional processing on RX/TX as well as an example application that uses this infrastructure to timestamp packets on TX and RX.

The commits have been merged to master will be part of DPDK 2.0 which is expected at the end of this month.

commit e7bc40da738c24a0cf23517f9d7144c0c96a75de
Author: Bruce Richardson <bruce.richardson@intel.com>
Date:   Mon Feb 23 18:30:10 2015 +0000

  examples/rxtx_callbacks: show use of callbacks

  Example showing how callbacks can be used to insert a timestamp
  into each packet on RX. On TX the timestamp is used to calculate
  the packet latency through the app, in cycles.

  Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
  Signed-off-by: John McNamara <john.mcnamara@intel.com>
  Acked-by: Declan Doherty <declan.doherty@intel.com>

commit 4dc294158cac46b6b69b60ff4216503777c5eb57
Author: Bruce Richardson <bruce.richardson@intel.com>
Date:   Mon Feb 23 18:30:09 2015 +0000

  ethdev: support optional Rx and Tx callbacks

  Add optional support for inline processing of packets inside the RX
  or TX call. For an RX callback, what happens is that we get a set of
  packets from the NIC and then pass them to a callback function, if
  configured, to allow additional processing to be done on them, e.g.
  filling in more mbuf fields, before passing back to the application.
  On TX, the packets are similarly post-processed before being handed
  to the NIC for transmission.

  Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
  Signed-off-by: John McNamara <john.mcnamara@intel.com>
  Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>

• Demo Instructions from the Prague Hackfest have been uploaded to the project wiki.
• Error and drop statistics collected by SFQM have been shared with the Doctor project and an opportunity for collaboration has been identified.
• CI precommit validation, a couple of suggestions are:
  • Compile DPDK
  • Run the dpdk unit tests using “make test”
  • We will be co-ordinating with Octopus to ensure this is enabled on our project repo.

Tools:

• Email topic, Email prefix and JIRA project tag is now SFQM.

• Review Project Proposal (baseline)
  • Today we had a walkthrough the project proposal some of the key points I would like to draw your attention to include:
    1. The scope of the project (the DPDK APIs and functions for latency and interface monitoring and the sample app) and what’s out of scope (VNF specific processing, Traffic Monitoring, Performance Monitoring and Management Agent).
    2. The proposed 2nd phase for the project (DPDK “Keep Alive” functionality which supports a DPDK failover and HA mechanism).
    3. The APIs and utilities that are in the scope of this project should be a logical extension of existing VNF and monitoring utilities to enable integration with higher level management components in the VIM, MANO, BSS/OSS… To that end, the project committers and contributors for the Software Fastpath Service Quality Metrics project wish to work in sync with the “Doctor” project – to facilitate this.
• Discuss Project Plan (high level)
  • The aim is to intersect DPDK R2.0 with contribution patches with the specified functionality and any additional documentation updates. DPDK R2.0 is provisionally planned for end March 2015.
• Project Repo and Infrastructure
  • The Git project repo (fastpathmetrics) has been setup https://gerrit.opnfv.org, a Linux Foundation account is required to access it. To create a Linux Foundation account please follow this link: http://identity.linuxfoundation.org/user/ The repo is Gerrit enabled for code review.
  • In terms of bug trackers, the proposal is to use JIRA, the supported bug tracker by the Linux Foundation.
  • Governance model to follow.
  • Jenkins build as an integrated sanity check (Open: Maryam to investigate)
• Questions:
  • What will the timestamp format be?
    • The initial proposed timestamp would be cycle accurate stamp (RTDSC). However the mechanism will be flexible so that different formats can be supported.