Hi all,
a respin of the rest of unmerged patches in the series based on latest
discussions. I believe most of concerns discussed are addressed here or
in the mailing list (but let me know if I missed something), but see
below.
There was a suggestion to introduce a new table=73 for activation flows,
where learn() would be used to activate pipeline for activated ports.
This approach would make activation flows stay forever. I prefer
cleaning such flows after activation to reduce the size of tables /
jumps through pipeline, esp. because multi-chassis binding may be
non-transitory (as in the case of live migration) but permanent (as in
port mirroring). Let me know if that's acceptable.
One other concern that is *not* addressed here is the request to
avoid flow deletion in pinctl.c RARP activation handler, instead leaving
the job to main thread.
This is technically doable but will require passing the job through a
global list (=complicate the code). Before I do that, I'd like to
understand why flow mod openflow message is not acceptable in pinctl. Is
it to keep all flow operations logically isolated in the main thread? Or
is there some race condition concern about two threads managing (these
specific) flows? I'd like to understand if code complexity is worth it.
Ihar
===
v5: moved activation flows from table=8 to table=0.
v5: removed pause=true from rarp activation flow since we don't rely on
continuations.
v5: make rarp handle resubmit() admitted RARP packet to table=8. This
allows to avoid holding pending packets / waiting for flows deleted
etc.
v5: when cloning packets destined to a local binding to additional
chassis, clone them to tunnels in table=37, not table=38, to stay
consistent with tables' intent.
v5: dropped patch that added chassis-mirroring-enabled option. The
option doesn't resolve the ARP flipping issue. Instead, just
document the behavior of localnet attached switches when ports are
multi-chassis.
v5: (minor) set match's port and dp key inside
put_remote_port_redirect_overlay.
v4: redesign to reuse requested-chassis option
v4: support >2 chassis per port
v4: allow to disable tunneling enforcement when n_chassis >= 2
v3: re-sent as a single series
v2: added ddlog implementation
v2: re-inject RARP packet after vswitch updates flows
v1: split into pieces
v1: renamed options: migration-destination ->
requested-additional-chassis,
migration-unblocked ->
additional-chassis-activated
v1: introduced options:activation-strategy=rarp to allow for other
strategies / having default no-op strategy
v1: implement in-memory port-activated tracking to avoid races
v1: numerous code cleanup / bug fixes
v1: special handling for localnet attached switches
v0: initial draft (single patch)
===
Ihar Hrachyshka (5):
Tag all packets that arrived from a tunnel as LOCAL_ONLY
Update port-up on main chassis only
Support LSP:options:requested-chassis as a list
Clone packets to both port chassis
Implement RARP activation strategy for ports
NEWS | 3 +
controller/binding.c | 284 +++++++++--
controller/binding.h | 5 +
controller/if-status.c | 15 +-
controller/if-status.h | 1 +
controller/lport.c | 42 +-
controller/ovn-controller.c | 4 +-
controller/physical.c | 327 +++++++++++--
controller/pinctrl.c | 228 ++++++++-
controller/pinctrl.h | 5 +
include/ovn/actions.h | 9 +
lib/actions.c | 40 +-
northd/northd.c | 72 ++-
northd/ovn-northd.c | 7 +-
ovn-nb.xml | 40 +-
ovn-sb.ovsschema | 17 +-
ovn-sb.xml | 87 +++-
tests/ovn.at | 948 ++++++++++++++++++++++++++++++++++++
utilities/ovn-trace.c | 3 +
19 files changed, 1994 insertions(+), 143 deletions(-)
--
2.34.1
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
