[ovs-dev] Support for in_phy_port

Simon Horman horms at verge.net.au
Mon Dec 2 02:41:11 UTC 2013


On Wed, Nov 27, 2013 at 09:12:12AM +0900, Simon Horman wrote:
> 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 <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.
> > 
> > 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 :)

Hi,

I am wondering if you would like me to add support for matching on
in_phy_port, which appears to be optional.  I am quite happy to do so, and
indeed I have most of the pieces in place to do so. However if not I wonder
if there is anything much to be done at all as the spec states that
in_phy_port may be omitted if it is the same as phy_port: our current plan
is for that to always be the case.



More information about the dev mailing list