On Thu, Jan 16, 2014 at 05:28:53PM -0800, Ben Pfaff wrote: > On Fri, Jan 17, 2014 at 09:59:49AM +0900, Simon Horman wrote: > > On Thu, Jan 16, 2014 at 04:46:23PM -0800, Ben Pfaff wrote: > > > On Wed, Jan 15, 2014 at 04:13:25PM +0900, Simon Horman wrote: > > > > The key is sourced from the datapath so should not > > > > have more labels than it can handle. > > > > > > > > dpif-netdev supports as many LSEs as can fit in struct flow, > > > > so it is safe to pass SIZE_MAX as the limit there. > > > > > > > > This is an proposed enhancement to > > > > "Implement OpenFlow support for MPLS, for up to 3 labels." > > > > > > > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > > > > > I don't think we'd ever try to install a flow that matches on more > > > MPLS labels than we probed the datapath as supporting. If we do, that > > > sounds like a bug. I think that this change would just make the bug > > > harder to find, by making us suppress the error inside odp-util > > > without actually fixing the bug at the higher layer. > > > > The problem I was trying to address is as follows: > > > > Suppose that the datapath supports one MPLS LSE and sends a that key with > > one MPLS LSE which does not have the BoS bit set. I believe that the > > current code would create a mask with three LSEs masked instead of one. > > But perhaps this is not a problem. > > I think that in that case the proper userspace behavior would be to > parse the flow from the kernel as ODP_FIT_TOO_LITTLE, which means that > userspace should never try to set up a flow. Oh, except that it would > set up a slow-path flow. Ouch. Hmm.
Just to clarify. I am talking about a situation where: 1. The datapath supports fewer LSEs than ovs-vswitchd and; 2. The packet has more LSEs than the datapath supports _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
