Information Technology Reference
In-Depth Information
whose path is /proc/net/pf_ring/ethX/rules that network
administrators, and not just monitoring applications, can use for
adding/removing filters by means of a simple echo of a string on it. For
instance echo “ +(1,-1,tcp,192.168.0.10,25,0.0.0.0,0)” >
/proc/net/pf_ring/eth3/rules , instructs PF_RING to add in the
eth3 device a new filtering affinity rule with id 1 and that sends all TCP
packets from 192.168.0.10:25 to the core id -1. Since the identifier -1 does
not correspond to a physical processor core, this rule allows packets
matching the filter to be dropped at the NIC layer. Using another existing
queue id would simply advise the filtering mechanism to direct the packets
to the appropriate queue and hence through the SMP affinity mechanism in
the Linux kernel into the desired core.
In order not to modify the existing driver structure by introducing new hooks
for adding and removing filters, we decided to jeopardize some existing driver
hooks. The advantage is that all current drivers do not need to be changed,
and this gives us a way to migrate towards packet filtering integration when
supported in Linux 1 . The data structure used to pass filter specifications to
drivers is generic and does not rely on 82599 specific data types. In this way,
the efforts for supporting future network adapters providing similar features
will be substantially reduced. 82599 provides several types of filters including
layer 2 and FCoE (Fibre Channel over Ethernet), but as PF_RING supports
only precise and wild card filters, we focus only on 5-tuple and flow director
filters that are very close to PF_RING filters:
5-tuple filters (up to 128 filters can be defined in 82599) allow packets
belonging to flows identified by the 5-tuple <protocol, ip source, port
source, ip destination, port destination> to be forwarded to a specific RX
queue. 5-tuple filters are defined as <id, protocol, ip/port
src, ip/port dst, target RX queue id> . Some of the
fields specified in a 5-tuple filter can be “masked” (i.e. wild carded) in
order to avoid comparing them against incoming packets.
Flow Director (FD) filters can be specified as precise (i.e. the filter
members are matched precisely against incoming packets) or hash (i.e.
the packet hash is compared against the filter hash, conceptually similar
to bloom filters [14]) filters. 82599 supports up to 32k precise filters. The
number of distinct hash filters is not limited by design. However, the
adoption of excessive hash filtering rules may lead to false positives. FD
filters are expressed as <slot id, VLAN, protocol, ip
netmask/port src, ip netmask/port dst, target RX
1
In kernel 2.6.34 the ethtool, not the kernel itself, introduced limited support for EFD
thanks to patches we submitted to Linux kernel maintainers.
Search WWH ::




Custom Search