On Fri, Jan 17, 2014 at 11:33:45AM +0900, Simon Horman wrote: > 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
My message above was concluding that we do need to do something, and I ran out of time at that point. I'm going to reconsider the patch. I don't really like it at first glance, so I'm going to see if I can think of a way I like better. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
