[ovs-dev] [PATCHv2 2/3] dpif-netdev: Always serialise recirculation in upcall key.

Joe Stringer joestringer at nicira.com
Thu May 15 04:34:38 UTC 2014


On 13 May 2014 17:43, Joe Stringer <joestringer at nicira.com> wrote:

> On 13 May 2014 16:44, Andy Zhou <azhou at nicira.com> wrote:
>>
>>  > diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
>> > index 926f3d6..bb16e7b 100644
>> > --- a/ofproto/ofproto-dpif.c
>> > +++ b/ofproto/ofproto-dpif.c
>> > @@ -3211,10 +3211,11 @@ rule_dpif_lookup(struct ofproto_dpif *ofproto,
>> struct flow *flow,
>> >      uint8_t table_id;
>> >
>> >      if (ofproto_dpif_get_enable_recirc(ofproto)) {
>> > -        /* Always exactly match recirc_id since datapath supports
>> > -         * recirculation.  */
>> > +        /* Always exactly match recirc_id and dp_hash since the
>> datapath
>> > +         * supports recirculation.  */
>> >          if (wc) {
>> >              wc->masks.recirc_id = UINT32_MAX;
>> > +            wc->masks.dp_hash = UINT32_MAX;
>> How about MPLS use case that does not require dp_hash to be exactly
>> matched?
>>
>
> Hmm, I think I added that part in particular to handle differences when
> megaflows are disabled. Without that, the odp flow sent to the datapath
> includes the dp_hash with a mask of 0. Then, when the datapath dumps the
> flow, because the mask is 0, it doesn't dump it back.
>
> Would it be better to always serialise the dp_hash in
> odp_flow_key_from_flow__(), or add a special case in
> dpif_netdev_flow_dump_next()?
>

I'm working on an alternative approach that would have the
odp_flow_key_from_{flow,mask}() callers pass in a parameter to indicate
whether it is the datapath or not. Based on this, it would pass a mask of
features to odp_flow_key_from_flow__(), to decide what to serialise to odp.
This should allow us to retain compatibility with older kernels but bring
the userspace datapath more in line with that of the kernel. It's
more-or-less a combination of the latter suggestion here and the existing
patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140515/2dab5df6/attachment-0005.html>


More information about the dev mailing list