As discussed during our meeting, NVIDIA asked to move blocked and natted bits from ct_label to ct_mark
Hi Alaa, Would it be OK to make this BZ public? That, is remove the "mellanox" group? Thanks, Dumitru
(In reply to Dumitru Ceara from comment #1) > Hi Alaa, > > Would it be OK to make this BZ public? That, is remove the "mellanox" group? > > Thanks, > Dumitru Hi, Dumitru. Sure, no problem.
Hey Alaa, it was agreed some mtgs ago that Han was going to look into this, so I'll reassign this bz to you to reflect that. There is a bz account to Han Zhou but well, I'm not sure it is his.
Right. Also, copying some info from the mail-thread: ```` Hardware offload won't work for flows that match on ct_label with a mask. We currently do that in OVN because we use ct_label for a few things: - match on ecmp_reply_eth address (48 bits) - match on ecmp_reply_port (16 bits) - match on ct_label.blocked (1 bit) - match on ct_label.natted (1 bit) The recommendation was to move the bits we match against with a mask (i.e., blocked, natted and ecmp_reply_port) to ct_label because the hardware supports masked matches of ct_label (32 bits). ````
note to self: internal ticket SDN-915
Upstream OVN fix: https://github.com/ovn-org/ovn/commit/a075230e4a0fcc166251271db1c8ae01b993c9cf And dependencies: https://github.com/ovn-org/ovn/commit/c2eeb2c98ea860dbbc7eee5e9bae8a65769b0da3 https://github.com/ovn-org/ovn/commit/bf55f7a655abb7aa0c3e5d537e79595ae13e89f2 https://github.com/ovn-org/ovn/commit/8ce847737f2db7b82b2e0296ff3b39551393d839 https://github.com/ovn-org/ovn/commit/3357440a3f1e8426953f96b41f72b88b43b86c42 https://github.com/ovn-org/ovn/commit/9eb7b4ec75e6773eb8f1770cc03f2fb0d391262a
Sorry but I forgot, what are the plans again here now? Get it into downstream on the next version and test it?
(In reply to Marcelo Ricardo Leitner from comment #7) > Sorry but I forgot, what are the plans again here now? Get it into > downstream on the next version and test it? We have two options: 1. Let it be picked up by FDP when we rebase on top of upstream ovn22.06.0 (scheduled on June 3rd). This is a personal guess but I think this won't be picked up before OCP 4.12. 2. Have it backported upstream to the upstream LTS branch (branch-22.03), and then pick it up in the next FDP release (22.D). AFAIK we're passed feature freeze in OCP 4.11 so this potentially won't be picked up before OCP 4.12 either. Han Zhou (NVidia) mentioned that he'll be looking into doing the backport to the upstream LTS branch (point 2 above).
Fix merged upstream to main, branch-22.03 and backport posted for branch-21.12: https://patchwork.ozlabs.org/project/ovn/list/?series=301671&state=*
Hi folks. Can we be sure that the fix will be included in OCP 4.11? Late last week Numan included the fix in the downstream branches, but that's where my knowledge ends.
(In reply to Marcelo Ricardo Leitner from comment #11) > Hi folks. Can we be sure that the fix will be included in OCP 4.11? > Late last week Numan included the fix in the downstream branches, but that's > where my knowledge ends. Hi Marcelo, It's already in there: https://github.com/openshift/ovn-kubernetes/blob/f88113aa1c9a59936ce4d09f383f829a8f9f2c22/Dockerfile#L36 Since: https://github.com/openshift/ovn-kubernetes/commit/7d557e065cae715cab1863b35e944c0dc934d371 I don't think we have an OVN 22.06 errata including this yet though. Once that happens this BZ will also be moved to MODIFED. Thanks, Dumitru
run the basic ovn hw-offload test case on ovn22.03-22.03.0-52, no new issue found. set VERIFIED
FWIW, the request for OCP 4.10 to include this fix is being tracked at: https://bugzilla.redhat.com/show_bug.cgi?id=2097221
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (ovn bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:5446