Hello everyone, We had a discussion on ovs-discuss that we wanted to bring here [1]:
Assume a physical network connected to a OVN Logical_Switch and then multiple Logical_Routers like so: +----------------+ | Logical Router | | lr001 +-+ +----------------+ | | +----------------+ | | Logical Router | | +----------------+ +------------------+ | lr002 +-+-+ Logical Switch +-+ Phyiscal Network | +----------------+ | | ls-ext | | | | +----------------+ +------------------+ ... | | +----------------+ | | Logical Router | | | lr300 +-+ +----------------+ If now a multicast packet comes in to ls-ext from the physical network (e.g. for our case a arp request or a neighbor discovery) it is flooded to all attached lsp's. The logical routers then try to lookup the source of the arp request/nd in their arp/neighbor table and insert it if it is not found. For the picture above that means that a single arp packet can trigger 300 lookup_arp and put_arp actions and each put_arp would result in a controller action. The outcome would be the same for all 300 logical routers: Each of them would insert the mac/ip binding in the MAC_Binding table and for each of them flows would be added. This leads to load on the ovn-controllers and the southbound database. Also some of the put_arp action can easily be lost due to the queue limit to the ovn-controller. In the mailinglist thread mentioned above ([1]) there was the discussion to move this learning process to the Logical Switch. This would mean that: 1. we only need to handle the learning in one location (and therefor only do it once) 2. the MAC_Binding table in the southbound database does not contain the (roughly) same entry 300 times However we where unsure if there is anything speaking against such an approach. >From my naive understanding I would propose the following changes: 1. move the whole lr_in_lookup_neighbor (table 1) and lr_in_learn_neighbor (table 2) from the logical router pipeline to the logical switch pipeline between ls_in_hairpin (table 18) and ls_in_arp_rsp (table 19) 2a. Leave the arp resolve stage in the logical routers: teach add_neighbor_flows to not only learn from the Mac_Binding table based on logical_ports but also based on the datapaths these ports are connected to 2b. Or move the arp resolve stage to the logical switches: 1) move lr_in_arp_resolve (table 17) and lr_in_arp_request (table 21) from the logical router to the logical switch pipeline 2) clarify what we would then use as a source address from arp requests that would then originate from the logical switch pipeline 3) clarify how we signal to the logical switch that it should actually do the arp lookup (as static mac_bindings for individual routers probably still need to work). I would for now tend to just move the learning stage to the logical switches while keeping the arp resolution stage on the logical router side. I guess I have overlooked something important in here as well, so it would be great if I could get feedback on your views on this. Thanks [1]: https://mail.openvswitch.org/pipermail/ovs-discuss/2023-March/052268.html -- Felix Huettner Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev