rjarry / brouter Goto Github PK

Can it have any performance impact?

Some interfaces have limited (fixed sometimes) number of tx queues. We cannot force one tx queue per datapath worker thread.

Potential solutions:

• Use graph pipeline mode
• Use locks for these specific tx queues

All these solutions will affect the overall performance of the other ports.

More details: http://inbox.dpdk.org/dev/[email protected]/

https://docs.frrouting.org/en/latest/zebra.html#zebra-fib-push-interface

Or can we implement a loadable plugin that will directly interact with libbr.so and not have any netlink/protobuf overhead?

A number of modules may require traffic from some unicast or multicast addresses that are filtered by hw when in non promisc / non allmulti mode.

Always running in promisc / allmulti is certainly possible, though it means receiving unwanted traffic.
But relying on promisc / allmulti may hide some network misconfiguration, or some other network equipment misbehaving, as grout would handle traffic that it should not in theory.

The request here is to add per iface lists of unicast and mcast addresses for which traffic is expected.

For a dpdk port backed interface, such lists will be associated with calls to rte_eth_dev_mac_addr_add, rte_eth_dev_mac_addr_del for unicast and rte_eth_dev_set_mc_addr_list. If adding a unicast/mcast address fails, then fallback would be to enable promisc / allmulti.

Associated with this, there is a need to track if enabling promisc/allmulti is a consequence of those unicast/mcast addresses or a request from the user (think of the case when the user enables promisc/allmulti via grcli, and later disables it).
The Linux kernel solution is to maintain a count of promisc / allmulti users (reflected by the "promiscuity" / "allmulti" counters one can find with "ip -s -d link").

Allow mirroring traffic from a port to a linux tap interface so that we can run regular tcpdump on it.

Example:

[root@dio brouter]$ br-cli mirror add tap-port0 port 0
[root@dio brouter]$ tcpdump -nni tap-port0 -c 5
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap-port0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:36:31.483702 IP 192.168.1.33.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0 (Cache flush) TXT "deviceid=DC:A6:32:CC:CD:37" "model=Xbmc,1" "srcvers=101.28" "features=0x20F7" (131)
14:36:31.758020 IP6 2a01:cb00:f8b:9700:ead2:ffff:fee4:99e0.53 > 2a01:cb00:f8b:9700:ffd8:872f:c4a:d9d4.35798: 27883 2/0/1 CNAME edge-web.dual-gslb.spotify.com., AAAA 2600:1901:1:c36:: (124)
14:36:31.759541 IP6 2a01:cb00:f8b:9700:ead2:ffff:fee4:99e0.53 > 2a01:cb00:f8b:9700:ffd8:872f:c4a:d9d4.49708: 30401 2/0/1 CNAME edge-web.dual-gslb.spotify.com., A 35.186.224.25 (112)
14:36:32.507441 ARP, Request who-has 192.168.1.1 (ff:ff:ff:ff:ff:ff) tell 192.168.1.16, length 46
14:36:33.324903 IP6 2001:41d0:a:69e1::1.1107 > 2a01:cb00:f8b:9700:ffd8:872f:c4a:d9d4.40526: Flags [P.], seq 4102294619:4102294705, ack 3835940537, win 501, options [nop,nop,TS val 1300040159 ecr 4009689886], length 86
5 packets captured
6 packets received by filter
0 packets dropped by kernel
[root@dio brouter]$ br-cli mirror del tap-port0

Some module may require getting notifications of additions and removals of interfaces.
For example, a LLDP module may need to register an associated mcast address it wants to receive traffic from.

When releasing a DPDK port and asking for detaching/freeing its associated HW resources, care must be taken not to break port "siblings" that were sharing those HW resources.

See testpmd or OVS:
https://git.dpdk.org/dpdk/tree/app/test-pmd/testpmd.c#n3674
https://github.com/openvswitch/ovs/blob/main/lib/netdev-dpdk.c#L1747

We need a way to keep the nexthop cache up to date by sending periodic arp requests.