ARP packet gets through DPDK filter

[anujkaliaiitd]

On X710 NICs, this ARP packet got through the filter:

15:300779 TRACE:   Transport: RX pkthdr = [type REQ, dsn 0, reqn 0, pktn 0, msz 0]. Frame = [ETH: dst ff:ff:ff:ff:ff:ff, src 0:50:56:a1:28:a7, eth_type 2054], [IPv4: ihl 0, version 0, ecn 1, tot_len 2048, id 1540, frag_off 1, ttl 0, protocol 80, check 41302, src IP 40.167.10.11, dst IP 6.71.0.0], [UDP: src_port 0, dst_port 0, len 2571, check 19718].

We need a filtering test.

[anujkaliaiitd]

Also, this DHCP packet on an XL710 NIC:

11:372264 TRACE: Transport: RX pkthdr = [type REQ, dsn 6928, reqn 8392448, pktn 12237, msz 1537]. Frame = [ETH: dst ff:ff:ff:ff:ff:ff, src 64:9d:99:0:a8:b3, eth_type 2048], [IPv4: ihl 5, version 4, ecn 0, tot_len 329, id 0, frag_off 0, ttl 128, protocol 17, check 38201, src IP 0.0.0.0, dst IP 255.255.255.255], [UDP: src_port 68, dst_port 67, len 309, check 35220].

[anujkaliaiitd]

This bug probably happens as follows: Intel DPDK NICs steer packets that match no eRPC-installed filter rules to queue #0, which feeds into eRPC. This doesn't happen on Mellanox NICs because the kernel still controls some NIC queues.

This is hard to fix in software. The DPDK transport implementation cannot just drop these packets since the Rpc class expects packets in contiguous ring buffer slots.

A better fix might be to try adding a drop rule for all packets that don't match any filter rules.