[ovs-dev] [PATCH ovn] ofctrl.c: Update installed OVS flow cookie when lflow is changed.

Ben Pfaff blp at ovn.org
Thu Jan 16 19:33:48 UTC 2020

On Sun, Jan 12, 2020 at 02:48:10PM -0800, Han Zhou wrote:
> On Sun, Jan 12, 2020 at 2:10 PM Han Zhou <hzhou at ovn.org> wrote:
> >
> > When an old lflow is replaced by a new lflow, if the OVS flows
> > translated by the old and new lflows have same match, ofctrl will
> > update existing OVS flow instead of deleting and adding a new one.
> >
> > However, when updating the existing flows, the cookie was not updated
> > by current implementation, which results in discrepency between lflows
> > and OVS flows, making debugging difficult and confuses tools such as
> > ovn-trace. This patch fixes it.
> >
> > Note: since command OFPFC_MODIFY_STRICT in FLOW_MOD message doesn't
> > support updating flow cookie after OpenFlow 1.1, this patch changes
> > to use OFPFC_ADD command, which effectively modifies existing flow
> > if a match is found.
> >
> > Signed-off-by: Han Zhou <hzhou at ovn.org>
> Hi Ben,
> I need your help to confirm that it is ok to replace OFPFC_MODIFY_STRICT
> with OFPFC_ADD for flow update, so that flow cookies can be updated. It
> seems there is no other way to update cookie after OF1.1.

I think you are right.  The basic issue is that the OF1.1 flow_mod wire
format (which is also used unmodified by all later versions of OpenFlow)
has only one field for a flow cookie.  This means that this field can be
used for matching on a flow cookie or updating a flow cookie, but not
(reasonably) used for both purposes.  "modify_strict" matches on cookie,
so it doesn't update it; "add" sets a cookie, so it doesn't match on it.

> Although I see this in Documentation/topics/design.rst, which mentioned
> that NXM supports updating cookie with OFPFC_MODIFY_STRICT when cookie is
> not 'UNIT64_MAX'.

The NXM wire format does allow for this.  It is just as borked as the
other protocols in terms of the number of cookie fields, that is, just
one.  (That's because the same people designed it as the plain OpenFlow
wire format, with the same lack of insight.)  But later one it was
extended to allow for a special NXM "field" that matches on the cookie.
If this is used, then we magically have two fields instead of one and
both purposes can be satisfied.

> ---------------
> The following table shows the handling of different protocols when receiving
> ``OFPFC_MODIFY`` and ``OFPFC_MODIFY_STRICT`` messages.  A mask of 0
> indicates
> either an explicit mask of zero or an implicit one by not specifying the
> ``NXM_NX_COOKIE(_W)`` field.
> ==============  ======  ======  =============  =============
>                 Match   Update   Add on miss    Add on miss
>                 cookie  cookie     mask!=0        mask==0
> ==============  ======  ======  =============  =============
> OpenFlow 1.0      no     yes    (add on miss)  (add on miss)
> OpenFlow 1.1     yes      no         no             yes
> OpenFlow 1.2     yes      no         no             no
> NXM              yes     yes\*       no             yes
> ==============  ======  ======  =============  =============
> \* Updates the flow's cookie unless the ``cookie`` field is ``UINT64_MAX``.
> ---------------
> However, it didn't work when I try using OFPFC_MODIFY_STRICT, even if I set
> fm.cookie = <new cookie> and fm.cookie_mask = UINT64_MAX. So I had to
> change it to OFPFC_ADD to make it work.

Probably, that's because OVS doesn't really fully support the Nicira
extension flow mod in OpenFlow versions later than 1.0.  I guess that
you were modifying ovn-controller, which uses OpenFlow 1.3.  OVS doesn't
ever generate Nicira extension flow mods in OF1.3.  

In turn, that's because I didn't realize until this very moment that
there were NXM features that are not in OF1.3.  Honestly, I'd rather not
use Nicira extension flow mods outside of OF1.0.  They were supposed to
be a nasty kluge because OF1.0 was inadequate and not evolving quickly
enough.  OF1.3 is pretty good and I don't want to go back to a place
where OVS is a huge pile of extensions on top of the official protocols.

> I am not familiar with OF standard and its implementation in OVS, but the
> change worked well with my tests. Could you help explain what's the side
> effect of using OFPFC_ADD instead of OFPFC_MODIFY_STRICT?

I think it's pretty much what's listed in the table.  The reset of the
counters is the biggest thing.

More information about the dev mailing list