OnixS C++ CME MDP Premium Market Data Handler  5.8.7
API Documentation
Solarflare Feed Engine

The default implementation of the Feed Engine is based on the standard socket API. Network card manufacturers offer ultra-low latency alternatives to this API. For example, Solarflare offers the ef_vi API to send and receive multicast packets bypassing the kernel and avoiding copying data from internal buffers to user space.

The SDK includes the implementation of the Feed Engine abstraction based on the Solarflare ef_vi API. The functionality is encapsulated into the OnixS::CME::MDH::SolarflareFeedEngine class. The design of this class is similar to the OnixS::CME::MDH::SocketFeedEngine class. The only difference is Solarflare-specific parameters.

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

Configuring the Solarflare Feed Engine

The Solarflare ef_vi API uses the concept of virtual interfaces to receive network data. The corresponding configuration parameters are available via the OnixS::CME::MDH::SolarflareFeedEngineSettings class:

Mixed mode

The mixed mode for the Solarflare Feed Engine combines the ef_vi SDK with standard network sockets. This mode allows taking advantage of using the ultra-low latency ef_vi API on Solarflare network adapters while receiving some data from non-Solarflare network interfaces using the socket API.

The following code shows how to configure data receiving when Incremental data comes via the Solarflare network adapter (eth0) and recovery data is available on a 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;
SolarflareFeedEngine feedEngine(feSettings);

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

Handler handler;
FeedSettings& feedSettings = handler.settings().feeds();
// We need to update all interfaces at once instead of assigning
// values for each feed type (Incremenal, Snapshot, Instrument, etc).
// Now, updates the settings for Incremental feeds only.