Linux Flattened Device Tree Selfchecking is a test suite to test the OF device tree interface used in device driver development. Traditionally, following input data was configured for the successful execution of Selfchecking tests.
– Append the testcase data to the current device tree (i.e. add a #include testcases.dtsi to the board .dts file to add in the
– Enable the testcase driver (i.e. enable OF_SELFTEST symbol in kernel config)
What was the problem above? – All the platforms had their custom device tree file so to execute the Selfchecking tests, and before enabling the DT self test the testcase data had to be manually appended to the device tree file (as mentioned above)
As a GSOC’2014 student intern, Gaurav Minocha removed the manual process of appending the testcase data to the board_specific .dts files, that is the input for the selftests. So, he has designed and improved the current code to automate the addition of the test data to the current device tree, if OF_SELFTEST symbol is enabled. In simple words, now user just needs to enable the appropriate config symbol to run the self tests.
Cavium demonstrates a high performance implementation of ODP-IPSec packet processing on a Cavium MIPS SoC on both Linux-Userspace and Bare Metal runtime environments. The demo is able to produce 40GB/s IPSec ESP processing.
Demonstrate the performance effective implementation of ODP-IPSec packet processing on Cavium SoC on Linux-Userspace and Bare Metal runtime environments.
IPSec ESP Processing (Authentication and Cipher)
40G Line rate
Linux User Mode environment support
Bare metal environment support
AES-CBC Cypher ( RFC 3602)
HMAC-SHA1-96 Authentication (RFC 2404)
Multiple SA support
Interview with Orange Sr. Research Scientist Dr. Christos Kolias and Raj Murali, Director of the Linaro Network Group on LNG Networking & Demo Day at the Connect event. The interview focuses on discussion about network functions virtualization (NFV), software defined networking (SDN), and OpenDataPlane (ODP).
Dr. Kolias explains the motivations and goals of the NFV project while Mr. Murali discussed the state of the ODP project and how it relates to the wider goals of NFV and SDN. The OpenDataPlane project provides an efficient abstraction layer to permit data plane applications to run portably across a wide variety of networking SoC platforms and processor architectures while still exploiting the various acceleration and offload features of those platforms. Mr. Murali also discussed the OpenDataPlane demonstrations showcased at Linaro Connect 2014. ODP v1.0 is scheduled for delivery at the end of 2014.
Network Functions Virtualization (NFV) envisions and promises to change the service provider landscape and has emerged as one of one of today’s significant trends. Although less than two years old, NFV has garnered the industry’s full attention and support. Moving swiftly, a number of key accomplishments have already taken place, and a lot more work is currently under way within ETSI NFV while we are embarking on its future phase. Various proofs-of-concepts (ranging from vEPC to vCPE, vIMS and vCDN) are being developed while issues such as open source and SDN are becoming key ingredients as the can play a pivotal role.
OpenDataPlane is a framework for developing cross-platform user space dataplane applications, like it is the case with Open vSwitch. For this we have written a “netdev provider” based on ODP to make OVS capable to work on a variety of platforms through the abstractions provided by the ODP API. The OpenDaylight Controller’s role is to manage virtual OVS switches/bridges running on top of ODP, both through a GUI web interface as well as through a series of scripts that take advantage of the REST northbound API of the OpenDaylight Controller. The video also shows how to control OVS switches through the ovs-ofctl command line tool of OVS, that is equivalent to using an externally connected controller implementing the OpenFlow specification (like the OpenDaylight Controller).
Right now the ODP netdev layer for OVS runs on linux-generic using basic socket transport, and it is scheduled to be running on linux-dpdk and linux-keystone2 ODP platforms. For the purpose of the demo the ODP netdev layer doesn’t take advantage of ODP’s packet scheduler, it only sends and receives packets in burst mode. For that it might be necessary to implement a dpif provider, which is one layer upper in the design of Open vSwitch.
Jon Masters, Chief ARM Architect at Red Hat, talks about Red Hat showing off their ARM Partner Early Access Program running on AMD’s ARMv8 64bit Seattle and on the Applied Micro ARMv8 64bit X-Gene Mustang booting both with UEFI and ACPI on a single same Kernel with no changes, common platform. Jon Masters talks about the Linaro Enterprise Group’s status and how much is yet required to be done for ARMv8 Servers to get into mass deployments worldwide.
Deepak Saxena and Linus Walleij discussing current and future endavours in the Linaro kernel working group: ARM consolidation, MMC power sequencing, preserving antique platforms for the future and more.
Direct access to perf counters for Networking/ODP domain really helps to budgeting lower CPU cycles to Benchmark Data Plane. Demo shows POC about Accessing Perf counters with Perf syscall Vs Direct access of perf counters from Userspace. Implementation has been shown for ArmV7 ( Arndale ) Board and ArmV8 ( Juno ) Board. Yogesh Tillu, Linaro/Cavium Engineer has demoed 1st cut implementation of concept.
Cisco offers cloud to set-top-box services, enabling Internet Speed for Service Providers to provide video-on-demand, video streaming, smart TV functionalities. Dr. Ken Morse, previously of Scientific Atlanta (aquired by Cisco in 2006), talks about Cisco working with Linaro to enable ARM Powered Set-top-box and home gateway solutions through open source.
Here you can watch his 1-hour keynote at the Linaro Connect 2014:
“As we move into a world where consumers expect to access all their video services on amy device, at any time, in any place, this requires major changes to the architecture of video delivery. In addition, the expectation is for new services to be launched at Internet Speed and not the typical 6 months or longer cycle taken by many new service introductions.”