Browse Prior Art Database

A Method to Efficiently Exchange Non-Packet Values (metadata values) with Accelerators (KeyGen and TLUs)

IP.com Disclosure Number: IPCOM000242563D
Publication Date: 2015-Jul-24
Document File: 5 page(s) / 150K

Publishing Venue

The IP.com Prior Art Database

Abstract

Passing of non-packet field values to packet matching accelerators today is inefficient. Many accelerators expect software to concatenate the metadata field values together and pass this compound key for performing look-up operations. Current issues with the existing accelerator include (i) limitations in passing non-packet based values to the accelerator, (ii) a significant amount of time is spent preparing the compound key, and (iii) supporting variable size non-packet based data can be a challenge for hardware accelerators. This paper focuses on providing the solution to the above issues.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 41% of the total text.

A Method to Efficiently Exchange Non-Packet Values (metadata values) with Accelerators (KeyGen and TLUs)

Abstract

Passing of non-packet field values to packet matching accelerators today is inefficient.  Many accelerators expect software to concatenate the metadata field values together and pass this compound key for performing look-up operations.  Current issues with the existing accelerator include (i) limitations in passing non-packet based values to the accelerator, (ii) a significant amount of time is spent preparing the compound key, and (iii) supporting variable size non-packet based data can be a challenge for hardware accelerators.  This paper focuses on providing the solution to the above issues.

Introduction

Table look--up accelerators are used to search for matching entries. In many packet processing applications, sessions are stored in tables. During packet processing table look-up accelerators are used to locate matching entries using the match field values. These match fields can be both packet and non-packet based. Non-packet based match fields are called metadata fields. Non-packet based match fields used across network applications, e.g., policy based routing, IPSec, firewall, and SDN open flow. The SDN Openflow 1.5 specification defines 32 metadata fields of 64 bits each.

Problem with existing accelerators

Passing metadata field values to table look--up accelerators in insufficient. Many accelerators expect the software to concatenate these metadata values and pass the compound key at look-up time. This may involve overhead/CPU cycles at packet processing time, which reduces the packet performance.

Current issues with the existing accelerator:

·         There are limitations in passing non-packet based values to the accelerator.

·         It is found that significant amount of time goes in preparing the key. 

·         Supporting of the variable size non-packet based data may be a challenge for HW accelerators.

The following section proposes a solution to the above problem.

Solution

Our solution defines a new interface to pass metadata field values. Our challenge is to provide an optimal solution where packet processing involves multiple table look-ups with different sets of match fields having various metadata values.

The solution includes the following:

·         Setting Metadata profile at the time of key profile creation.

·         Passing of metadata fields to the acceleration at packet processing time

·         Modifications required in accelerators.

A.    Metadata profile

Pre-condition:

·         Caller maintains 32bit array of metadata fields and 64bit array of metadata fields at packet processing. These array addresses are passed to the table lookup function.

Metadata can be defined as two types:

·         Array of 32 bit integers

·         Array of 64 bit integers.

With array of 32 bit integers, 8 bit metadata/16 bit metadata can also be programmed by specifying various mask values (eg. 0xff, 0xffff).

Fig.1 shows the metadata elements.

Fig. 1.    Metadata profile elements

Metadata...