| Message ID | 20170501195807.31051-1-joe@ovn.org |
|---|---|
| State | Accepted |
| Headers | show |
Acked-by: Jarno Rajahalme <jarno@ovn.org> > On May 1, 2017, at 12:58 PM, Joe Stringer <joe@ovn.org> wrote: > > If there is no active ukey for a particular datapath flow, and it is > dumped from the datapath, then the revalidator threads will assemble a > ukey based on the datapath flow. This will allow tracking of the stats > for proper attribution, and future validation of the flow. > > However, until now when creating the ukey in this context, the ukey's > 'reval_seq' has been set to the current udpif's reval_seq. This implies > that the flow has been validated against the current flow table. > However, this is not true - The flow appeared in the datapath without > any prior knowledge in this OVS instance so we should set up the > reval_seq of the ukey to ensure that the flow will be validated during > the current dump/revalidation cycle. > > Refer also revalidate_ukey(). > > Fixes: 23597df05226 ("upcall: Create ukeys in handler threads.") > Signed-off-by: Joe Stringer <joe@ovn.org> > --- > ofproto/ofproto-dpif-upcall.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c > index 18be901d0b8a..2e23fe702281 100644 > --- a/ofproto/ofproto-dpif-upcall.c > +++ b/ofproto/ofproto-dpif-upcall.c > @@ -1612,7 +1612,7 @@ ukey_create_from_dpif_flow(const struct udpif *udpif, > } > > dump_seq = seq_read(udpif->dump_seq); > - reval_seq = seq_read(udpif->reval_seq); > + reval_seq = seq_read(udpif->reval_seq) - 1; /* Ensure revalidation. */ > ofpbuf_use_const(&actions, &flow->actions, flow->actions_len); > *ukey = ukey_create__(flow->key, flow->key_len, > flow->mask, flow->mask_len, flow->ufid_present, > -- > 2.11.1 >
On 1 May 2017 at 13:05, Jarno Rajahalme <jarno@ovn.org> wrote:
> Acked-by: Jarno Rajahalme <jarno@ovn.org>
Thanks, applied to master and branch-2.[567].
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index 18be901d0b8a..2e23fe702281 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -1612,7 +1612,7 @@ ukey_create_from_dpif_flow(const struct udpif *udpif, } dump_seq = seq_read(udpif->dump_seq); - reval_seq = seq_read(udpif->reval_seq); + reval_seq = seq_read(udpif->reval_seq) - 1; /* Ensure revalidation. */ ofpbuf_use_const(&actions, &flow->actions, flow->actions_len); *ukey = ukey_create__(flow->key, flow->key_len, flow->mask, flow->mask_len, flow->ufid_present,
If there is no active ukey for a particular datapath flow, and it is dumped from the datapath, then the revalidator threads will assemble a ukey based on the datapath flow. This will allow tracking of the stats for proper attribution, and future validation of the flow. However, until now when creating the ukey in this context, the ukey's 'reval_seq' has been set to the current udpif's reval_seq. This implies that the flow has been validated against the current flow table. However, this is not true - The flow appeared in the datapath without any prior knowledge in this OVS instance so we should set up the reval_seq of the ukey to ensure that the flow will be validated during the current dump/revalidation cycle. Refer also revalidate_ukey(). Fixes: 23597df05226 ("upcall: Create ukeys in handler threads.") Signed-off-by: Joe Stringer <joe@ovn.org> --- ofproto/ofproto-dpif-upcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)