Missed this the first time around for some reason. Minor comments inline.
On 1 April 2015 at 22:14, Neil McKee <neil.mc...@inmon.com> wrote:
> 1) We can use the concurrent hash-map of flows that the revalidator
> threads are sharing. The upcall knows the 128-bit ufid for the flow, so
> we can get directly to the compiled actions like this:
>
> struct udpif_key *ukey = ukey_lookup(updif, upcall->ufid);
> if(ukey) {
> struct nladdr *actions = ofpbuf_data(ukey->actions);
> ....
> }
>
> This seems to work most of the time, but the way the revalidator threads
> are spinning and flushing seems to make ukey_lookup() fail sometimes and
> return NULL. Is there a different way to query that would avoid this
> problem? If this method was reliable we could probably eliminate all the
> code that builds and stores the sFlow userdata-cookie, and we would have a
> mechanism that would work not just for tunnels, but for MPLS and other
> actions too.
You could turn up the 'dpif' debug level and ensure that you are
actually seeing the UFIDs you expect (and log an error with the UFID
when lookup fails).
I'm not sure that you can guarantee the UFID is 'correct' (ie, same as
the installed flow) for the action upcall case currently. The UFID
doesn't originate in the kernel, so for all upcalls the dpif generates
it based on the flow key and passes it up to ofproto-dpif. If the flow
mangles the packet before performing sample(userspace()), then won't
the flow key be different from the original flow?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
