Coder Social home page Coder Social logo

omec-project / ngic-rtc Goto Github PK

View Code? Open in Web Editor NEW
53.0 29.0 44.0 7.77 MB

NGIC-RTC is Control User Plane Separated (CUPS) architecture 3GPP TS23501 based implementation of EPC Service and Packet Gateway functions (SGW, PGW)

Home Page: http://www.omecproject.org

License: Apache License 2.0

Makefile 1.51% Shell 4.95% C 91.17% Python 2.27% Dockerfile 0.11%
3gpp cups epc sgw pgw lte

ngic-rtc's Introduction

๐Ÿ’ฅ New features have been released to the e-utran-features branch include:

  • PFCP Support (Sxa,Sxb,Sxa/Sxb reference points)
  • Expanded E-UTRAN procedure support including handover scenarios
  • User Level Packet Copying feature captures session data
  • CSID implementation and UP recovery
  • UPF selection by DNS
  • Predefined Rules
  • UE sessions with multiple Bearer support.
  • Charging by volume and time notification.
  • Session level promotion/demotion due to handover

For more information take a look at the e-utran-features branch and supporting documentation.

Next Generation Infrastructure Core

Introduction

NGIC-RTC is a Control User Plane Separated (CUPS) architecture 3GPP TS23401 based implementation of Evolved Packet Core (EPC) Service and Packet Gateway functions (SGW, PGW) in a run to complete design to maximize packet processing performance per compute core. NGIC-RTC allows runtime configurable SGWC-SGWU <S5/S8>, PGWC-PGWU or SPGWC-SPGWU options.

Interface between Control and User/Data plane i.e. S-PGWC and S-PGWU is ZMQ push-pull mechanism over TCP transport. Options for UDP transport or SDN integration are available too.

                                       EPC Core
                             +-------------------------+
                             | +---------+ +---------+ |
                      Control| |  MME    | |  PCRF   | |
                       Signal| |         | |         | |
         +----------+  +-------+         | |         | |
+--+     |          |  |     | +-----+---+ +---+-----+ |
|UE+-----+          |  |     |       |         |       |
+--+     |          |  |     |   +-----------------+   |
         |          +--+     |   |   |s11      |Gx |   |
+--+     |  eNodeB  +--+     |   | +-------------+ |   |
|UE+-----+  (Base   |  |     |   | |    CP       | |   |
+--+     |  Station)|  |     |   | +-------------+ |   |   +--------------+
         |          |  |     |s1u| +-------------+ |sgi|   | External     |
+--+     |          |  +---------+ |    DP       | +-------+ Network      |
|UE+-----+          |  User  |   | +-------------+ |   |   |              |
+--+     +----------+  Data  |   |    NGIC NFV     |   |   |              |
              ||             |   +-----------------+   |   +--------------+
              ||             +-------------------------+
              ||
              ++

Feature List

The NGIC currently supports the following SAE-GW features:

  • PCC (Policy Control and Charging) rules configuration.
  • ADC (Application Detection and control) rules configuration.
  • Packet Filters for Service Data Flow (SDF) configuration.
  • Packet Selectors/Filters for ADC configuration.
  • UE sessions with multiple Bearer support.
  • SDF and APN based Qos Metering for MBR.
  • Charging by volume and asynchronous notification.
  • Enable command line or display stats periodically.
  • IPv4 support
  • Multiport support
  • Sponsored Domain Name support

High Level Design

The NGIC is divided into Control plane (CP) and Data plane (DP). CP is used to set the PCC rules, QoS profiles, and UE Session to DP via UDP or ZMQ communication performed by the cp_dp_api library. Currently ADC rules are static.

        +----------------+
        |                |
+-----> |    Control     |
 S11    |    Plane       |
<-----+ |                |
        |                |
        +-------+--------+
                |
                |
                | IPC
                |
                v
        +-----------------+
        |                 |
        |                 |
+-----> |     Data        | +--->
 S1U    |     Plane       |  SGi
<-----+ |                 | <---+
        |                 |
        +-----------------+

Below is a packet walk for the DP

          +-----------------------------------------------------------------------------------------------------+
          |                        NGIC Data Plane Flow Diagram.                                                |
          |                               +---------------------------------+           +-----------------+     |        Flow1
          |  +------+  +------+  +------+ |    UE session                   |  +------+ | SDF & ADC Filter|     |    <--------------+
          |  | CDR  |  | APN  |  | PCC  | | +--------------------------+    |  | PCC  | |                 |     |        Flow2
   Flow1  |  |Charg |  | Meter|  | Meter| | |Default            sdf1   |    |  |Gating| |    sdf1         |     |    <--------------+
<-------+ |  |ing   |  |      |  |      | | |Bearer             sdf3   |    |  |      | | <-----------+   |     |
   Flow2  |  |      |  |      |  | sdf1 | | +--------------------------+    |  | sdf1 | |    sdf2         |     |
<-------+ |  |per UE|  |per UE|  | sdf2 | |                                 |  | sdf2 | | <-----------+   |     |        Flow3
   Flow3  |  |per ADC  |      |  | sdf3 | |                                 |  | sdf3 | |                 |     |    <--------------+
<-------+ |  |per   |  |      |  | sdf4 | | +--------------------------+    |  | sdf4 | |                 |     |        Flow4
   Flow4  |  | bearer  |      |  |      | | |Dedicated          sdf2   |    |  |      | | <-----------+   |     |    <--------------+
<-------+ |  |      |  |      |  |      | | |Bearer             sdf4   |    |  |      | |    sdf3         |     |
          |  +------+  +------+  +------+ | +--------------------------+    |  |      | | <-----------+   |     |
          |                               |                                 |  +------+ |    sdf4         |     |
          |                               +---------------------------------+           +-----------------+     |
          |                                                                                                     |
          +-----------------------------------------------------------------------------------------------------+

The CP does session establishment and management by polling the configured S11 interface. Alternatively, the s11 interface may be bypassed to read/write packet capture (pcap) files, as the allocation of TEID and IP addresses are deterministic. The CP manages within its own data structures all required information to process the management of its connections, therefore tests may be performed independent of the data plane. The high level design of the control plane is shown below.

                  +-------------------------------------------------------------+
                  |                     NGIC Control Plane                      |
                  |   +------------------+                 +------------+       |
                  |   | Create Session   |_________________| IP         |       |
                  |   | Parser/Responder |                 | allocation |       |
                  |   +------------------+_______________  +------------+       |
                  |    |                                 \                      |
                  |    |  +------------------+            \___+-------------+   |
                  |    |  | Modify Bearer    |________________| UE/Session/ |   |
                  |    |  | Parser/Responder |                | Bearer data |   |
                  |    |  +------------------+      __________+-------------+   |
                  |    |   |  .                    /                        |   |
          +-----> |    |   |  .                   /          +------------+ |   |
         S11/pcap |    |   |  .                  /        ___| Packet     | |   |
          <-----+ |    |   |  +------------------+       /   | Filters    | |   |
                  |    |   |  | Create Bearer    |______/    +------------+ |   |
                  |    |   |  | Parser/Responder |                          |   |
                  |    |   |  +------------------+                          |   |
                  |    |   |   |  ...                                       |   |
                  |    |   |   |    +------------------+                    |   |
                  |    |   |   |    | Delete Session   |____________________|   |
                  |    |   |   |    | Parser/Responder |                        |
                  |    |   |   |    +------------------+                        |
                  |    |   |   |     |                                          |
                  |    |   |   |     |                                          |
                  |   +------------------+                                      |
                  |   |    CP_DP_API     |                                      |
                  |   +------------------+                                      |
                  +-----------||------------------------------------------------+
                              ||
                              \/
                              DP

Messages currently supported by the control plane include:

  GTP Echo Request (RX) / GTP Echo Reply (TX)
  Create Session Request (RX) / Create Session Reply (TX)
  Delete Session Request (RX) / Delete Session Reply (TX)
  Modify Bearer Request (RX) / Modify Bearer Reply (TX)
  Create Bearer Request (TX) / Create Bearer Reply (RX)
  Delete Bearer Request (TX) / Delete Bearer Reply (RX)
  Bearer Resource Command (RX - on the condition TAD operation type specifies addition or deletion of packet filter)

Error handling is not implemented as specified by 3GPP 29.274, specifically the MME will receive no indication of error. Messages indicating error type may be displayed to console output, depending on type of error.

Furthermore, the control plane expects the contents of these messages to contain certain Information Elements (IE). These may differ from all corner cases allowed by 3gpp 29.274, which will be ignored, and may drop messages if some IEs are not present.

For low level details on the Control Plane see CP_README.MD

Installation

Please refer INSTALL.MD for instructions to install and run CP and DP

Release Notes

Please refer RELEASE_NOTES.MD

ngic-rtc's People

Contributors

ajamshed avatar amitinfo2k avatar brianwaters3 avatar hyunsun avatar krsna1729 avatar somnathchakrabarti avatar sureshmx avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ngic-rtc's Issues

Build system inconsistency

libgtpv2c is built is differently than other components in the repo

  • as a shared library
  • independent of DPDK build system

Any particular reasoning for this? If there is no technical requirement should we

  • build as a static library
  • leverage DPDK build system

Add Dockerfile

Add Dockerfile and Makefile targets to build S/PGW-C/U images.

Depends-on: #6 to stay free of duplication of installation steps

TODO Tracker

There are lot of TODOs sprinkled over the code. Lets have a corresponding issue open here. This can be the top-level tracker issue.

Simplify DP config file

Currently in DP configuration (dp_config.cfg) user needs to specify PCI ID and MAC Address where, there is chance of typo error. Instead, we can use the Port index (DPDK port bind order) and using DPDK API get the MAC address which will make configuration simple.

DP kni interface config when processing traffic causes crash

Capture the bug we discovered internally in the release notes, if it has not been fixed already.

Excerpt:

We tried to execute a couple of commands specific to S1Udev/SGIdev interface configurations with ngic-rtc (KNI mode). It turns that running commands such as changing MTU size (when ngic-rtc is running against il_trafficgen) triggers a crash. This is because the current code is not taking care of the race condition(s) that may arise when MTU size is being changed (rx/tx operations on the NIC are not paused, while ports are being configured).

Close this issue if it has been fixed.

Add branch protection to the repo

As we start working on the codebase, nobody including owners should be able to push directly to master. Let us put branch protection in place to make all changes through a pull request.

NIC checksum offloading for vdevs?

We are currently relying on NIC-based checksum verification in init.c:

ngic-rtc/dp/init.c

Lines 88 to 99 in d65e865

const struct rte_eth_conf port_conf_default = {
.rxmode = {
.max_rx_pkt_len = ETHER_MAX_LEN,
.offloads =
DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
DEV_RX_OFFLOAD_TCP_CKSUM |
DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM |
DEV_RX_OFFLOAD_CRC_STRIP,
/* Enable hw_crc_strip for PF/VF drivers */
.hw_strip_crc = 1}
};
.

Does this cover checksum offloading for vdevs as well (e.g. virtio & af_packet devices)? This needs to be investigated.

Otherwise we need to have a pure SW-based fallback for RX-based checksum verification.

Add kubernetes manifests

Add manifests under deploy/k8s folder that will help bring up each of the S/PGW-C/U components in this repo

Files without license header to begin with or left out in the SPDX replacement

The below files currently do not have the SPDX license identifier and/or copyright

$ grep -rL 'SPDX-License-Identifier: Apache-2.0' * \
--exclude=\*.{cfg,pcap,patch,csv,gitignore,txt,pem} --exclude=LICENSE 
config/ng-core_cfg.mk
cp/chk_cpcfg.sh
cp_dp_api/vepc_cp_dp_api.c
dp/chk_dpcfg.sh
dp/gtpu_echo.c
dp/commands.c
dp/pipeline/epc_arp_icmp_api.hlp
dp/perf_timer.h
dp/timer_stats.c
dp/build_ngic.sh
kni_ifcfg/kni-S1Udevcfg.sh
kni_ifcfg/kni-S1Udevdel.sh
kni_ifcfg/kni-SGIdevdel.sh
kni_ifcfg/kni-SGIdevcfg.sh
test/zmq_device/req_streamer_dev.py
test/zmq_device/resp_streamer_dev.py
test/fmea/test_fmea.sh

Document dp/dp_rules_verify

Expanding on question 5 in #12 this folder currently contains some big files and no documentation of its purpose and usage.

Also provide feedback on whether this should be moved to a test or ci folder

[RFC] Add veth + AF_PACKET DPDK vdev support to leverage kernel control plane

Environments that do not allow to ship and install kni kernel module should continue to work. Since we rely on the Linux kernel to handle control traffic (ARP, ICMP, etc.,) we should provide an alternative where mirror veth interfaces are leverged using DPDK AF_PACKET vdev to send and receive packets to the kernel.

SGWC: Skewed Create Session Response Sequence Number, when sending a response back to the MME on S11 interface.

In Create Session Response under GTPv2 header Sequence Number is not correct, that's why MME rejects the Create Session Response.

Please find below the analysis when the sequence number is getting skewed:

CP: Before byte conversion:6e5
CP: 1 S11 SGWC recv after byte conversion Seq:e50600
CP: 2 SGWC Send to PGWC Seq:e50600
CP: 3 SGWC recv from PGWC Seq:e50600
CP: 4 Filled in cs_resp Seq:e50600
CP: 5 Before encoding Seq:e50600
CP: 6 After encoding Seq:6e5
CP: 7 Set Resp for MME seq:6e5
CP: 8 SGWC Send Resp to MME seq:6e5

s11-0212-sgwc.zip

Credit contributors

Since the git history is not available, we should at least credit contributors to NGIC codebase, from before release in the README.md or CONTRIBUTING.md.

SGWU and PGWU: Failed to launch due to missing GW address and MASK.

Need to remove the following parameters from dp_config and run.sh

 --sgw_s5s8gw_ip $SGW_S5S8GW_IP  \
 --sgw_s5s8gw_mask $SGW_S5S8GW_MASK    
 --sgw_s5s8gw_ip $PGW_S5S8GW_IP  \
 --sgw_s5s8gw_mask $PGW_S5S8GW_MASK  

EAL: FATAL: Invalid 'command line' arguments.
EAL: Invalid 'command line' arguments.
EAL: Error - exiting with code: 1
Cause: Error with EAL initialization

DP Checksum errors

In our tests with ngic-rtc against ng40, both UL and DL cores are sometimes reporting checksum errors on packet reception:

        0        15         0         0         0   ||         0        15         0         0         0
        0        17         0         0         0   ||         0        17         0         0         0
DP: DL Bad checksum: 50
DP: DL Bad checksum: 48
DP: DL Bad checksum: 52
DP: DL Bad checksum: 48
DP: DL Bad checksum: 48
DP: DL Bad checksum: 48
DP: DL Bad checksum: 170
DP: DL Bad checksum: 172
DP: DL Bad checksum: 168
DP: DL Bad checksum: 168
DP: DL Bad checksum: 168
DP: DL Bad checksum: 174
DP: DL Bad checksum: 168
DP: DL Bad checksum: 168
DP: DL Bad checksum: 168
DP: UL Bad checksum: 24
DP: UL Bad checksum: 24
DP: UL Bad checksum: 24
DP: DL Bad checksum: 168
DP: DL Bad checksum: 174
DP: DL Bad checksum: 54
DP: DL Bad checksum: 48
DP: DL Bad checksum: 50
DP: DL Bad checksum: 174
        0   1128679   1131981   1131975         6   ||         0   3069894   3074366   3074366         0

The code needs to be analyzed to find the root cause of this problem.

Clean up references to ng-core_cfg.mk

File ng-core_cfg.mk has been moved to custom-cp/dp.mk in PR #18.
Old name is still referenced in repo:

ngic-rtc {master}$ grep -nr ng-core_cfg.mk .
./dev_scripts/wokni/Makefile_wokni:14:include $(NG_CORE)/config/ng-core_cfg.mk
./dev_scripts/wokni/Makefile_wkni:14:include $(NG_CORE)/config/ng-core_cfg.mk
./INSTALL.MD:216:`ng-core_cfg.mk`. In this case ZMQ push/pull model is used.
./INSTALL.MD:218:ZMQ_COMM flag (ZMQ Push Pull) is enabled by default in config/ng-core_cfg.mk
./INSTALL.MD:257:    `ng-core_cfg.mk`.
./INSTALL.MD:571:  If ZMQ_COMM flag is enabled in the config file ng-core_cfg.mk, then we need to start the
./.git/COMMIT_EDITMSG:3:Removed config/ng-core_cfg.mk
./config/interface.cfg:11:; ng-core_cfg.mk
./config/interface.cfg:46:; ng-core_cfg.mk
./config/interface.cfg:54:; ng-core_cfg.mk

DP crashes when CP connects

When testing with Dockerfile and Ubuntu 18.04 base, DP crashes when CP connects

        0         0         0         0         0   ||         0         0         0         0         0
12: [/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f394ea6688f]]
11: [/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db) [0x7f394ed3d6db]]
10: [ngic_dataplane(eal_thread_loop+0x1f1) [0x5598082fc9f1]]
9: [ngic_dataplane(+0x81b91) [0x559808279b91]]
8: [ngic_dataplane(+0x81bbd) [0x559808279bbd]]
7: [ngic_dataplane(iface_process_ipc_msgs+0xdf) [0x55980828119f]]
6: [ngic_dataplane(+0x781b4) [0x5598082701b4]]
5: [ngic_dataplane(meter_profile_entry_add+0xb9) [0x559808280e29]]
4: [ngic_dataplane(dp_meter_profile_entry_add+0x2a) [0x55980827080a]]
3: [/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f394e983f20]]
2: [ngic_dataplane(sig_handler+0x38) [0x559808280568]]
1: [ngic_dataplane(rte_dump_stack+0x2e) [0x5598082fecae]]
EAL: Error - exiting with code: 1
  Cause: received SIGSEGV

As noted in #54 (comment) this only appears when compiling with -O3

Delete logs directory and any hardcode

These directories are empty and of no use. So delete them. The application should create any directory necessary or take an argument --log-dir for user to specify pre-created directory

Remove hardcode folder name. If need to then define in one place and re-use

dp/main.h

  • #define SPGW_S1U_PCAP_FILE "logs/uplink.pcap"
  • #define SPGW_SGI_PCAP_FILE "logs/downlink.pcap"
  • #define SGW_S1U_PCAP_FILE "logs/sgw_s1u.pcap"
  • #define SGW_S5S8_PCAP_FILE "logs/sgw_s5s8.pcap"
  • #define PGW_S5S8_PCAP_FILE "logs/pgw_s5s8.pcap"
  • #define PGW_SGI_PCAP_FILE "logs/pgw_sgi.pcap"

dp/timer_stats.c

  • #define STATS_PATH "./logs/"

Related -
dp/session_cdr.c

[RFC] Configuration consistency

  • Remove hardcode of configuration directory location and replace with --conf-dir option
    • #define METER_PROFILE_FILE "../config/meter_profile.cfg"
    • #define PCC_RULE_FILE "../config/pcc_rules.cfg"
    • #define SDF_RULE_FILE "../config/sdf_rules.cfg"
    • #define ADC_RULE_FILE "../config/adc_rules.cfg"
    • #define IFACE_FILE "../config/interface.cfg"
    • #define SIMU_CP_FILE "../config/simu_cp.cfg"
  • Consolidate all config parameters in config files instead of split between scripts/commandline and config to help ease customization. Ideally ./binary --conf-dir /path/to/conf/dir should be the usage

Refactor documentation

  • Keep the landing README.md light. Move documentation into appropriate files under docs and provide pointers, with exceptions of contributing, release notes, etc. E.g., 1, 2
  • New user quick start
  • Packet walks showing in different configs/modes S/PGW-C/U
    • cores, port, queues
    • key functions/tables and packet manipulations
  • Call flow diagram with messages supported and not supported
  • Create svg under docs/img instead of ascii art and reference in markdown

Cleanup config folder

  • Makefiles should not exist in this config directory (PR #18)
  • Document within config files or README.md in this folder or docs/ as per #5
    • the key and possible values
    • optional/required
    • which entity/mode requires this file e.g., SPGWU, PGWU, etc.,

Attach-detach failed randomly with polaris load test

Attach, detach issues observed randomly in jenkins tests (TC1 and TC2). Issue is reproducible in manual run as well.

Profile: 32K UES, 250 TPS
Setup: ONF jenkins setup
Testcase: Testcase 1 and 2 ( ZMQ + KNI, UDP + STATIC ARP)

Polaris Report:
+----------------------------------------------Summary-----------------------------------------------+
+ 1. Test start time.............................................................04-04-2019 17:43:28 +
+ 2. Test end time...............................................................04-04-2019 17:50:07 +
+ 3. Total time taken....................................................................399 seconds +
+ 4. Average time per test case..........................................................399 seconds +
+ 5. Total number of tests executed................................................................1 +
+ 6. Total number of tests passed..................................................................0 +
+ 7. Total number of tests failed..................................................................1 +
+ 8. Test pass percentage.........................................................................0% +
+--------------------------------------------Passed Tests--------------------------------------------+
+  No Test Passed.                                                                                   +
+--------------------------------------------Error Tests---------------------------------------------+
+--------------------------------------------Failed Tests--------------------------------------------+
+ 1. ./Attach-Detach-wdata.tcl                                                                       +
+     Errors:                                                                                        +
+      1. Attach failed : 739 out of 32000 attempts.                                                 +
+      2. Detach failed : 4 out of 31261 attempts.                                                   +
+----------------------------------------------Results-----------------------------------------------+
+ 1. ./Attach-Detach-wdata.tcl                                                                       +
+     Results:                                                                                       +
+      1. Attach: Attempt: 32000, Success: 31261,  Completion Time (max/min/avg): 4111.92/8.66/77.15 +
+      2. Detach: Attempt: 31261, Success: 31257,  Completion Time (max/min/avg): 240.31/4.81/21.65  +

Create dpdk subfolder in patches

Today patches/ is flat. We should create sub directories denoting which dependency we are patching so that install scripts can apply all of them at once per dependency.

DP should convey its S1U IP to CP on start up

Instead of user providing S1U IP of DP in the CP commandline arguments, the DP can send a message to CP with this information. This will reduce the number of things to know upfront for CP.

Refactor install.sh

To help re-use in other build environments, e.g docker build with Dockerfile, CI systems

  • Non-interactive
  • Source able
  • Do not require sudo if already root user - check if $EUID or id -u is 0

Don't check-in certificates

Certificates are checked in under dp/conf. We should delete this folder and include a helper script to generate the certs like in c3po components.

The need for libmnl-dev for handling dataplane link/route events

Pull request #32 introduces a patch that enables the data-plane to communicate with the kernel via af_packet sockets. We use netlink sockets in order to capture link events (such as mtu size changes, promiscuous mode changes, etc.), with this new interface. We submitted a commit that uses libmnl-dev library to handle such events. Introducing this library to the dataplane means that one will have to install this library (Ubuntu deb package is already available) and then link it in dp's Makefile. I suggest that we make this update since using this library simplifies the overall code structure.

In future revisions, one can also use the same API (/usr/include/libnl3, libmnl-dev) to capture route event changes that are currently being handled in dp/pipeline/epc_arp.c file. In the long run, the overall code structure of epc_arp.c may improve.

License clarification for dp/commands.c

Any idea whats happening in this file? The first paragraph seems like BSD-3 and has UC Berkeley name in it while the copyright notice on top is Intel and we have second paragraph with Apache-2.0 license

ngic-rtc/dp/commands.c

Lines 1 to 43 in d65e865

/*
* Copyright (c) 2017 Intel Corporation
*
* All rights reserved.
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of the University of California, Berkeley nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
///*
// * Copyright (c) 2017 Intel Corporation
// *
// * Licensed under the Apache License, Version 2.0 (the "License");
// * you may not use this file except in compliance with the License.
// * You may obtain a copy of the License at
// *
// * http://www.apache.org/licenses/LICENSE-2.0
// *
// * Unless required by applicable law or agreed to in writing, software
// * distributed under the License is distributed on an "AS IS" BASIS,
// * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// * See the License for the specific language governing permissions and
// * limitations under the License.
// */

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.