On Fri, Apr 18, 2014 at 10:52 AM, Jesse Gross <je...@nicira.com> wrote: > On Fri, Apr 18, 2014 at 10:39 AM, Andy Zhou <az...@nicira.com> wrote: >> On Fri, Apr 18, 2014 at 9:28 AM, Jesse Gross <je...@nicira.com> wrote: >>> I don't understand the other change about accepting a hash mask even >>> when there isn't a hash value. Can you explain this? >> It is not necessary now. I was thinking of the case Pravin suggested that >> we do a masked action. A hash value may be zero after applying a mask. >> In this case, the hash value won't be exported on a post recirculation miss, >> but >> its mask can be supplied on flow installation. We can remove it if this is >> not >> the direction we want to go. > > I don't know if Pravin was actually suggesting a maskable action - his > questions seemed more on the match side. I can't really come up with a > use case either. > Thanks for clarifying. I will remove it from this patch since there is not a clear use case to allow dp_hash mask alone.
> I think that the value being special/disallowed in the hash should be > entirely internal to the kernel. In this case it's fine to do it > because the hash is opaque anyways, so who's so say that we just don't > have a hash with this property. However, I think if we started getting > into cases like this where a zero value might come up then we should > probably either use a bit to indicate that the hash is valid or always > send it. That's not a bad idea. I some how don't like sending 'new' attributes to an older user space, even if it will not cause harm because of the compatibility layer as your previous email suggested. We could go down this road if you think this is significantly better than removing it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
