Dropping Multicast Traffic

Alveo X3522 User Guide (UG1523)

Document ID
UG1523
Release Date
2023-08-25
Revision
1.4 English

In the default configuration, the X3522 adapter will forward 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 will drop 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 -1

where <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 255
Note: If this would exceed the maximum number of filters, an error message is output, and the filter is not inserted. For example:
rmgr: Cannot find appropriate slot to insert rule
Cannot insert classification rule

Once this filter has been inserted, any UDP IPv4 multicast traffic arriving at the interface that does not match another steering filter will be dropped at the adapter and the port_rxdp_di_dropped_pkts counter shown by ethtool -S <interface> will be incremented.

The filter can be deleted using its ID to reference it. For example:

$ sudo ethtool -N enp2s0f0np0 delete 255

Allowing Specific UDP IPv4 Multicast Traffic

When the multicast-mismatch drop filter is present, UDP IPv4 multicast traffic will only be 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 will 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 will also match IGMP traffic, which will then be passed to the application instead of to the kernel. This will cause 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 will 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 1

These 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 3

IGMP, Layer 2 Multicast and IPv6

Because the multicast mismatch filter described here is for UDP IPv4 multicast traffic only, IGMP traffic will still be allowed to pass to the kernel without any specific exceptions. This will also be the case for any other layer 2 multicast protocols and IPv6 traffic.