Using scalable filters, an Onload stack can install a MAC filter to receive all traffic from a specified interface.
Using scalable filters removes limitations on:
- the number of listening sockets in scalable filters passive mode
- the number of active-open connections in scalable filters transparent-active mode. This works only for sockets having the IP_TRANSPARENT option set. See Transparent Reverse Proxy Modes below.
On Onload 201805 and later, scalable filters can be combined for both passive and active open connections and with RSS, enabling very high transaction rates for use cases such as a reverse web proxy.
The most effective way to use scalable filters is with a dedicated VI created with a MACVLAN. This allows the kernel stack or another application using scalable filters to use the same physical port. The kernel option
inject_kernel_gid (introduced in Onload 201805) controls the injection of packets not handled by Onload back to the kernel when the VI is instead shared with other functions
Solarflare adapters can be partitioned to expose up to 16 PCIe physical functions (PF). Each PF is presented to the OS as a standard network interface. The adapter is partitioned with the sfboot utility - see example below.
Once a MAC filter has been installed on a PF, other Onload stacks can still receive other traffic on the same PF, but sockets will have to insert IP filters for the required traffic. Apart from ARP, ICMP and IGMP packets, OS kernel sockets, using the same PF, will not receive any traffic.
Per interface, the MAC filter can only be installed by a single Onload stack. If a process creates multiple stacks, the EF_SCALABLE_FILTERS_ENABLE per-stack variable can be used to enable/disable this feature for individual stacks using the existing Onload extensions API. For example:
The MAC filter is inserted when the stack is created. This is before sockets are created, and sockets need to be created to receive any traffic destined for this stack.