On Mon, Nov 25, 2013 at 10:48:36PM -0800, Ben Pfaff wrote: > On Tue, Nov 26, 2013 at 03:46:23PM +0900, Simon Horman wrote: > > On Mon, Nov 25, 2013 at 05:24:23PM -0800, Ben Pfaff wrote: > > > On Mon, Nov 25, 2013 at 05:22:47PM -0800, Jesse Gross wrote: > > > > On Mon, Nov 25, 2013 at 4:04 PM, Simon Horman <ho...@verge.net.au> > > > > wrote: > > > > > On Mon, Nov 25, 2013 at 10:09:30AM -0800, Ben Pfaff wrote: > > > > >> On Mon, Nov 25, 2013 at 10:09:55PM +0900, Simon Horman wrote: > > > > >> > as far as I can tell no one is actively working on the following > > > > >> > item in > > > > >> > OPENFLOW-1.1+. So I have made a start it. > > > > >> > > > > > >> > * The new in_phy_port field in OFPT_PACKET_IN needs some kind > > > > >> > of > > > > >> > implementation. It has a sensible interpretation for tunnels > > > > >> > but in general the physical port is not in the datapath for > > > > >> > OVS > > > > >> > so the value is not necessarily meaningful. We might have to > > > > >> > just fix it as the same as in_port. > > > > >> > [required for OF1.1; optional for OF1.2+] > > > > >> > > > > >> Sounds good! I hope you're planning to do something simple. > > > > > > > > > > My main plan is to allow communication of the in_phy_port field > > > > > between ovs-vswtichd and the datapath by adding a new netlink key. > > > > > Then to expose that in packet_in messages. I also have it in mind > > > > > to allow matching on the in_phy_port, but probably later. > > > > > > > > > > As for determining the in_phy_port. My plan is to determine the vport > > > > > that > > > > > tunneled packets arrive on in their encapsulated form and use that as > > > > > the > > > > > in_phy_port. I plan to not set the in_phy_port for non-tunnelled > > > > > packets; > > > > > to set it to the same as in_port for non-tunnelled; or some > > > > > combination of > > > > > the two depending on how the code pans out. > > > > > > > > How do you plan on getting the physical vport? It seems a little > > > > challenging because the port might not be attached to OVS at all or at > > > > the very least it is likely not attached to the same bridge. > > > > > > That's one main reason I haven't bothered with this: it seems unlikely > > > to be useful. > > > > That is a good point and not one that I think I have a good answer too. > > > > I think it should be reasonably straight forward in the case where the > > physical port is attached to the same bridge. But that case seems > > to be unlikely. And in the more likely case that it isn't then > > I'm not sure it can be done. > > > > After my enthusiasm in my previous email I now think that I will > > put this work on hold. > > OK. > > Short of work on this, I will eventually implement it trivially to fix > it the same as in_port.
Ok, that much I think I can do :) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
