The Feed Engine Based On Solarflare ef_vi SDK

The default implementation of the Feed Engine is based on the standard socket API. However, various network card manufactures offer alternatives to the standard socket API to manipulate network data. For example, the Solarflare offers ef_vi SDK to send and receive multicast packets bypassing the kernel and avoiding copying data from internal buffers to user space. The Solarflare ef_vi SDK is designed for high-performance networking for trading applications.

Starting from version 5.1 of the SDK, the standard distribution includes an implementation of the Feed Engine concept based on the Solarflare ef_vi SDK. The functionality is encapsulated into the OnixS::CME::MDH::SolarflareFeedEngine class. The design of the class is similar to the OnixS::CME::MDH::SocketFeedEngine class. The only difference is the parameters affecting the behaviour of the new Feed Engine.

Note

The Solarflare ef_vi SDK is available for Linux platforms only and supports solely Solarflare network cards. To simplify the development process for users, the CME Market Data Handler SDK exposes the OnixS::CME::MDH::SolarflareFeedEngine and related classes for all platforms. However, instance creation will fail at runtime on platforms where the corresponding functionality is not supported.

Configuring the New Feed Engine

The Solarflare ef_vi SDK uses the concept of virtual interfaces to receive network data. The CME Market Data Handler SDK follows this concept and exposes parameters related to the given entities. All parameters are gathered into the OnixS::CME::MDH::SolarflareFeedEngineSettings class:

• The OnixS::CME::MDH::SolarflareFeedEngineSettings::mode defines behavior of the Feed Engine in certain cases. In particular, the Feed Engine will fail operating on non-Solarflare network interfaces in the conventional mode as use of the ef_vi services on non-Solarflare network interfaces is not supported by manufacturer and thus leads to a failure. In contrast, the mixed mode combines ef_vi with ordinary socket API thus making possible multicast packets reception on both Solarflare and non-Solarflare network interfaces. The mixed mode gives more flexibility for the users whose operating environments configured in a specific way (for example, when incremental data is available on a Solarflare network adapter and recovery data comes via a non-Solaflare network interface).

  Note

  The given control parameter was introduced in the 5.6 Release. Before that, the Engine supported only conventional operational mode.

• The OnixS::CME::MDH::SolarflareFeedEngineSettings::receiveRingSize parameter defines the number of buffers in a virtual interface receive ring. Buffers from the receive ring are filled with network packets (a single buffer is used for a single packet). The feed engine checks which buffers are filled with incoming data and delivers those buffers to the handlers for further processing. The receive ring must be large enough to accommodate incoming data during market data bursts.
• The OnixS::CME::MDH::SolarflareFeedEngineSettings::cacheSize parameter sets the size of a pool of buffers used to receive and manipulate incoming data. When the buffers are put into the receive ring and filled with incoming data, the feed engine delivers the buffers to the handlers for further processing. Thus, the buffers filled with the data are kept busy until the received data is processed by handlers. In case of rapid transmission, buffers may be allocated by the feed engine quicker than they are processed by the handlers and released back to pool. Therefore, the pool must be large enough to avoid data loss caused by an empty pool and receive ring.
• The OnixS::CME::MDH::SolarflareFeedEngineSettings::socketBufferSize parameter establishes size of a socket buffer used to store incoming packets before they are retrieved by the Feed Engine. The given parameter is used by the Feed Engine operating in the mixed mode when ordinary sockets are used as the way of multicast data reception on non-Solarflare network interfaces.

The Sample Application

The SDK evaluation distribution includes fast-start reference implementation source code samples - including a Benchmarking sample. This sample has been updated to include the Feed Engine based on the Solarflare ef_vi SDK in the available predefined Feed Engine implementations. See the sample source code to get familiar with the concept and use of the feed engine implementation based on the Solarflare ef_vi SDK.

Mixed Mode Example

The 5.6 Release introduced the new mixed mode for the Solarflare Feed Engine which combines the ef_vi SDK with ordinary network sockets. The new mode lets to take advantage of using the ef_vi services on Solarflare network adapters and manages data reception on non-Solarflare network interfaces with the help of network sockets API.

The following code depicts how to establish data reception for the case, when incremental data comes via Solarflare network adapter (eth0) and recovery data is available on the non-Solarflare network interface (eth2).

Configuring consists of two steps.

The first step is to tell Solarlfare Feed Engine to work in the mixed mode:

SolarflareFeedEngineSettings feSettings;

// The given statement turns the Feed Engine behavior in necessary way. 
feSettings.mode(SolarflareFeedEngineOperatingMode::Mixed);

SolarflareFeedEngine feedEngine(feSettings);

The second step is to bind Handler's feeds to proper network interfaces:

Handler handler;

FeedSettings& feedSettings = handler.settings().feeds();

// The trick is to update all interfaces at once instead of assigning 
// values for each type of feed (incremenal, snapshot, instrument, etc).

feedSettings.feedANetworkInterfaces("eth2");
feedSettings.feedBNetworkInterfaces("eth2");

// Now, updates specs for incremental feeds only.

feedSettings.incrementalFeeds().feedANetworkInterfaces("eth0");
feedSettings.incrementalFeeds().feedBNetworkInterfaces("eth0");