On 17 March 2015 at 15:00, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > On Mar 17, 2015, at 2:01 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Fri, Mar 13, 2015 at 04:52:00PM -0700, Jarno Rajahalme wrote: > > xlate_actions() now considers an optional recirculation context (via > 'xin') and restores OpenFlow pipeline metadata (registers, 'metadata', > etc.) based on it. The recirculation context may contain an action > set and stack to be restored and further actions to be executed upon > recirculation. It also contains a table_id number to be used for rule > lookup in cases where no post-recirculation actions are used. > > The translation context internal metadata is restored using a new > internal action: UNROLL_XLATE action stores the translation context > data visible to OpenFlow controllers via PACKET_IN messages. This > includes the current table number and the current rule cookie. > UNROLL_XLATE actions are inserted only when the remaining actions may > generate PACKET_IN messages. > > These changes allow the post-MPLS recirculation to properly continue > with the pipeline metadata that existed at the time of recirculation. > > The internal table is still consulted for bonds. > > Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > > > I'm a little concerned about ukey_create_from_dpif_flow(), which seems > to get called whenever the datapath does not support ufids. It seems > to reject recirculation actions in that case. Does that mean that > userspace becomes incompatible (if any recirculation is attempted) > with older datapaths? I think that is what happens, but I don't think > that is the intent. > > > The only user of key_create_from_dpif_flow() has this comment just above: > > /* Usually we try to avoid installing flows from revalidator > threads, > * because locking on a umap may cause handler threads to block. > * However there are certain cases, like when ovs-vswitchd is > * restarted, where it is desirable to handle flows that exist in > the > * datapath gracefully (ie, don't just clear the datapath). */ > > It seems to me that the dpif-layer always provides the ufid, by hashing from > the flow key. By looking at lib/dpif-netlink.c parse_odp_packet(), it seems > that the upcall’s ufid is always hashed from the datapath key, regardless of > the presence of an FLOW_ATTR_UKEY. So there should not be a problem here. > Maybe Joe could confirm this?
Sorry, missed this email earlier. Correct, the dpif layer is expected to always provide a UFID, regardless of support further down. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
