[ovs-dev] Support for in_phy_port

Simon Horman horms at verge.net.au
Tue Nov 26 06:46:23 UTC 2013


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 <horms at 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.



More information about the dev mailing list