Information Technology Reference
In-Depth Information
In a nutshell, flow affinity filters introduce new opportunities, not yet
exploited by operating systems and monitoring applications, for the
implementation of hardware assisted packet schedulers capable to accelerate
traffic analysis applications by fully exploiting the parallelism offered by
multi-core architectures.
As we believe that 82599 is just the “first of a kind” and similar flow affinity
filters mechanisms will soon be introduced by other vendors, PF_RING has
been extended not only to exploit these features as implemented by 82599 but
also to support future NICs providing similar capabilities. For this reason we
introduced a new hardware-neutral software layer that is responsible for
setting up specific flow affinity filtering rules in hardware. This layer has not
been designed for natively supporting the 82599 controller in PF_RING, but
rather as a foundation layer for offloading selected filtering tasks to those
NICs that feature flow affinity filters. This means that:
not all facilities offered by 82599 have been supported yet (e.g. IEEE
1588 time synchronization), but only those (i.e. flow affinity filters) that
can be currently exploited by PF_RING for accelerating its operations
(i.e. we have not added support of 82599 in PF_RING, but rather
exploited those 82599 features that can accelerate PF_RING);
adding support in PF_RING for flow affinity filters-like features in future
NICs, will not require PF_RING redesign but it will just require the
implementation of new extensions into PF_RING-enabled NIC drivers;
existing applications such as RTC-Mon will not need to be recoded (but
just slightly modified) in order to exploit flow affinity filters, as
PF_RING transparently sets in hardware the appropriate flow affinity
filters.
PF_RING supports two families of filters: precise filters where the whole
<vlan, protocol, ip/port src, ip/port dst> tuple needs to
be specified, and wild card filters where some filter parameters can be
unspecified (e.g. tcp and port 80 ). When a packet is received,
PF_RING uses the “best match first” policy, so it will first try to match the
packet against configured precise filters, and in case of no match against wild
card filters. Packets matching a filter will be passed to the specified plugin or
action, if configured. Hardware flow affinity filters support has been added
into PF_RING as follows:
PF_RING-aware drivers notify (when the driver is loaded inside the kernel)
the PF_RING engine whenever a given NIC supports flow affinity filters.
PF_RING has been extended with a new function named
handle_hw_filtering_rule() that allow precise and wild carded
filters to be added/removed inside NICs.
For each NIC supporting flow affinity filters, PF_RING adds a virtual file
Search WWH ::




Custom Search