Hi all, Below is a short proposal for improving the results of ofproto/trace in regards to ct actions.
Feedback welcome. Eric. --->8--- ### Problem statement - ofproto/trace fails in regard to conntrack states and address/port translations - conntrack is used heavily in OVN - makes debugging flows very difficult ### Suggestion: use ../lib/conntrack We can pass traced packets to OVS's ../lib/conntrack whenever a ct action is encountered. This is the same code used for ct actions in the userspace datapath. This means we'll leverage the same code for tracing as we do for actual userspace packet processing. ### Issues #### When using kernel datapath there is no conntrack state in userspace When using the kernel datapath the conntrack implementation is in the kernel. This means there is no conntrack state available for userspace to perform the tracing. We'll need a way to seed the conntrack table during tracing - with support for multiple zones. #### Tracing causes changes to the live conntrack table One side affect to passing traced packets to ../lib/conntrack is that they may affect the states of conntrack entries that were added via actual traffic. In reality, this is likely not a deal breaker as we're only using ofproto/trace if we're debugging. There are some options to avoid conntrack state changes: 1. implicitly duplicate the conntrack table before running a trace - a second advantage to this is to avoid lock contention with openvswitch 2. user seeds a conntrack table zone and that zone is used for tracing #### Divergence from kernel datapath It's acknowledged that the userspace conntrack implementation may differ from the kernel implementation. It's believed that they're "close enough" nowadays. We could allow the user to manually override states or other (e.g. ct_next_dport), but we'll avoid this at all cost. #### ../lib/conntrack needs packet data As it is today, ../lib/conntrack needs full packet data. This can either be changed or even simpler we build a dummy packet when doing a trace. This can be built based on the flow. ### Plan Forward This can be done in steps. 1. call ../lib/conntrack for ct actions - only useful if datapath is userspace - side effect that it will change conntrack table state 2. allow seeding userspace conntrack table - enables ct tracing if datapath is kernel - new API with support for multiple zones - ideally input would be `conntrack -L` output - really useful for testsuite 3. conntrack table duplication - in order to avoid changing the real conntrack table state ### Questions #### When using kernel datapath, why not pass the traced packet to the kernel datapath? This would require new kernel APIs. Which means it would only work on new kernels and/or using the out-of-tree modules. It would also delay the implementation. There has also been upstream talk about a proper tracing tool to address other issues, i.e. hashing. This would warrant new kernel APIs, but the ct improvements discussed here can be done without kernel support. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev