[ovs-dev] RFC: ct action ofproto/trace improvements

Eric Garver egarver at redhat.com
Thu Jul 30 18:06:44 UTC 2020


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.



More information about the dev mailing list