In the default configuration, the X3522 adapter forwards all traffic to the host even if no steering filter matching the traffic is present. When no matching filter is present, traffic is steered to queue 0. This behavior differs from the X2 series adapter which drops traffic not matching any filter.
In environments where a lot of unsolicited traffic is forwarded to the adapter, it can be undesirable to pass this up to the host because it leads to increased CPU load to process and drop the traffic. In particular, ultra low latency layer 1 switches do not support IGMP snooping and forward all multicast traffic. This section presents a method to configure an X3522 adapter to drop unwanted UDP traffic at the adapter.
Inserting a UDP IPv4 Multicast Mismatch Filter
To prevent any UDP IPv4 multicast traffic arriving through interface
<interface> reaching the kernel, insert a filter to drop it.
As root, use the following command:
ethtool -N <interface> flow-type udp4 dst-ip 224.0.0.0 m 15.255.255.255 action -1where <interface> is the name of an X3522 interface. For example:
$ sudo ethtool -N enp2s0f0np0 flow-type udp4 dst-ip 224.0.0.0 m 15.255.255.255 action -1
Added rule with ID 255rmgr: Cannot find appropriate slot to insert rule
Cannot insert classification ruleOnce this filter has been inserted, any UDP IPv4 multicast traffic arriving at
the interface that does not match another steering filter is dropped at the adapter
and the port_rxdp_di_dropped_pkts counter shown by
ethtool -S <interface> is
incremented.
The filter can be deleted using its ID to reference it. For example:
$ sudo ethtool -N enp2s0f0np0 delete 255Allowing Specific UDP IPv4 Multicast Traffic
When the multicast-mismatch drop filter is present, UDP IPv4 multicast traffic is only delivered to an application if a steering filter that matches the traffic is added. For kernel applications, this can be achieved using further ethtool ntuple rules. An example is given in the following section of a PTP client that needs to receive multicast traffic.
- Applications running under Onload or using the TCPDirect API automatically have filters inserted with no changes to the applications or system configuration.
- ef_vi applications should insert filters for the traffic they wish to receive as has traditionally been the case for applications written to work with X2 adapters.
- Filters should match on the destination IP and port associated with the
multicast traffic.
If filters instead match on MAC address they also match IGMP traffic, which is then passed to the application instead of to the kernel. This causes a subsequent networking failure unless the application appropriately handles the IGMP traffic, for example by somehow forwarding it to the kernel stack.
Allowing PTP Traffic
The following ethtool ntuple rules allow a PTP client to receive required traffic via the kernel driver (on queue 0) for PTP operating in end-to-end mode:
$ sudo ethtool -N enp2s0f0np0 flow-type udp4 dst-ip 224.0.1.129 dst-port 319 action 0
Added rule with ID 0$ sudo ethtool -N enp2s0f0np0 flow-type udp4 dst-ip 224.0.1.129 dst-port 320 action 0
Added rule with ID 1These rules should be applied to all interfaces that need to receive PTP traffic. If using a bond then the rules should be applied to all underlying interfaces.
If operating PTP in peer-to-peer mode then the following rules are required in addition to those above.
$ sudo ethtool -N enp2s0f0np0 flow-type udp4 dst-ip 224.0.0.107 dst-port 319 action 0
Added rule with ID 2$ sudo ethtool -N enp2s0f0np0 flow-type udp4 dst-ip 224.0.0.107 dst-port 320 action 0
Added rule with ID 3IGMP, Layer 2 Multicast and IPv6
Because the multicast mismatch filter described here is for UDP IPv4 multicast traffic only, IGMP traffic is still allowed to pass to the kernel without any specific exceptions. This is also the case for any other layer 2 multicast protocols and for IPv6 traffic.