On Thu, Apr 14, 2016 at 6:19 PM, Prathap T <prathap....@gmail.com> wrote:
> Hi Jesse:
>
>   "Imagine a 1 bit long flow. The flow in the table has the value 0 and
> the mask is 1 (significant). There is also another mask with the value
> 0 (not significant). If a packet came in with the header value of 1
> and it tried the second mask first then the value would become 0,
> matching the flow in table on the basis of a strict comparison.
> However, in reality these flows don't match."
>
> I could guess this, but I could not really understand on when this would
> happen. In the case you have mentioned, dosen't the flow with the
> mask of 1 be of a higher priority then the other one in the userspace?
> dosen't the userspace take care to generate datapath flows that will have
> the masks of higher priority entries, and in the example, it is almost
> impossible to have the 1 bit flow that has a mask with value 0 because of
> priority? Please help me understand.

Priority of flows is defined by the user, not by the structure of the
those flows, so you can't say that one should be chosen over another.
A 1 bit flow is clearly a simplified use case - you can generalize to
mean that you are looking at 1 bit of a longer n-bit flow, where the
rest of the bits might have some combination of masks.

However, the question of priority doesn't even need to come into play
here. You can view this as a binary decision on that one flow - either
it matches or it doesn't. If there is a mask floating around that
causes you to match on a flow when you should not, then the behavior
is incorrect. In the realistic case of multi-bit flows, there might be
plenty of masks floating around that could cause this situation for a
single bit while still having non-overlapping equal priority flows.
(Example: add a second bit where one flow has a 0 value and another
has a 1 value, both masked as significant.)
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to