Ben Pfaff <b...@ovn.org> wrote on 03/08/2016 10:07:19 PM:
> From: Ben Pfaff <b...@ovn.org>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: dev@openvswitch.org
> Date: 03/08/2016 10:07 PM
> Subject: Re: [ovs-dev] What looks like a bug in OVSDB change seqno
tracking
>
> On Tue, Mar 08, 2016 at 08:35:10PM -0600, Ryan Moats wrote:
> > While working on finishing up the next version of the incremental flow
> > processing patch, I stubbed
> > my toe on a situation where the port column of rows in the multicast
group
> > table of ovnsb were
> > being updated without the row's change seqno being updated.
> >
> > A quick look at the code base shows that weak references (like the port
> > column) are updated via
> > calls to ovsdb_txn_row_modify while row change seqnos are updated via
calls
> > to ovsdb_idl_row_*
> > and the two code paths don't appear to intersect.
>
> ovsdb_txn_row_modify() is part of ovsdb-server, and ovsdb_idl_row_*() is
> part of ovsdb-client, so they don't intersect per se.
>
> > While I consider such behavior a bug (because it means change seqnos
can't
> > be trusted), I wanted
> > to ping the list to confirm my cursory analysis before delving in to
trying
> > to find a way to address
> > this.
>
> Can you explain how to reproduce the issue?
>
This gets a little complex, but I'll give it a try:
Preparation:
(1) Turn on change tracking for the entire SB database in
ovn/controller/ovn-controller.c
(2) In ovn/controller/physical.c, change SBREC_MULTICAST_GROUP_FOR_EACH to
SBREC_MULTICAST_GROUP_FOR_EACH_TRACKED, lookup the seqnos for each row and
dump them to the log
(3) In ovn/controller/ofctrl.c, change ovn_flow_log to always log messages
and add a line to log the flow that is passed to ofctrl_add_flow
[If need be, I can see about extracting out a patch set that will make all
of the above changes]
Now, run ovn E2E test case with 3 HVs, 1 VIFs/HV, 1 GW, 1LS (case 2014 in
my
setup) - it should pass, but if one looks at the output of
hv1/ovn-controller.log, one should see the following signatures:
Initially, the first multicast row will produce:
2016-03-09T04:38:17.721Z|00105|physical|INFO|multicast row with 0 0 2
2016-03-09T04:38:17.721Z|00106|ofctrl|INFO|considering flow: table_id=33,
priority=100, reg7=0xffff,metadata=0x1, actions=set_field:0x1->
reg5,set_field:0x1->reg7,resubmit(,34),set_field:0xffff->reg7
After the first tunnel port appears, the signature changes to:
2016-03-09T04:38:17.799Z|00150|physical|INFO|multicast row with 0 0 2
2016-03-09T04:38:17.799Z|00151|ofctrl|INFO|considering flow: table_id=33,
priority=100, reg7=0xffff,metadata=0x1, actions=set_field:0x1->
reg5,set_field:0x1->reg7,resubmit(,34),set_field:0xffff->reg7
2016-03-09T04:38:17.799Z|00152|ofctrl|INFO|considering flow: table_id=32,
priority=100, reg7=0xffff,metadata=0x1, actions=set_field:0x1/0xffffff->
tun_id,set_field:0xffff/0xffffffff->tun_metadata0,move:NXM_NX_REG6[0..14]->
NXM_NX_TUN_METADATA0[16..30],output:2,resubmit(,33)
After the second tunnel port appears, the signature changes to:
2016-03-09T04:38:20.028Z|00203|physical|INFO|multicast row with 0 0 2
2016-03-09T04:38:20.028Z|00204|ofctrl|INFO|considering flow: table_id=33,
priority=100, reg7=0xffff,metadata=0x1, actions=set_field:0x1->
reg5,set_field:0x1->reg7,resubmit(,34),set_field:0xffff->reg7
2016-03-09T04:38:20.028Z|00205|ofctrl|INFO|considering flow: table_id=32,
priority=100, reg7=0xffff,metadata=0x1, actions=set_field:0x1/0xffffff->
tun_id,output:3,set_field:0x1/0xffffff->
tun_id,set_field:0xffff/0xffffffff->tun_metadata0,move:NXM_NX_REG6[0..14]->
NXM_NX_TUN_METADATA0[16..30],output:2,resubmit(,33)
Looking at the multicast code, it processes all the values in the
ports column of the multicast group row. The above signature says
to me that the the values in this column have changed, but the
change seqnos for that row didn't change (specifically the mod_seqno
was never set), which leads me to the conclusion that these seqnos
can't be trusted to reveal when rows of a table change...
I'm hoping for a different interpretation...
Ryan (regXboi)
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
