On Mon, Dec 21, 2015 at 03:03:42PM -0500, Russell Bryant wrote: > On 12/21/2015 02:52 PM, Ben Pfaff wrote: > > On Mon, Dec 21, 2015 at 10:39:29AM -0500, Russell Bryant wrote: > >> On 12/21/2015 09:55 AM, Numan Siddique wrote: > >>> On 12/21/2015 08:13 PM, Russell Bryant wrote: > >>>> On 12/21/2015 09:27 AM, Numan Siddique wrote: > >>>> What problem are you addressing here? It seems we would want the flows > >>>> created, even when the port is not up yet. Otherwise, when the port > >>>> does come up, ovn-controller has an incomplete logical flow table. I > >>>> think the logical flow table should be independent of port state and > >>>> location. > >>>> > >>>> Thanks, > >>>> > >>> Presently when I create a port (neutron port-create) , i can get response > >>> to arping for the port ip, > >>> even if it is not bound to any VM. > >>> I thought of addressing this trivial problem. As soon as the port does > >>> come up, northd would > >>> add the necessary ARP reply logical flow. But I get your point now. > >> > >> Got it. Thanks for clarifying the issue. > >> > >> I wonder what the desired behavior should be here ... I'm tempted to > >> just say the existing behavior is OK. I wonder what others think. > > > > It is surprising behavior to get an ARP response from a port that is not > > up. I think that it will confuse users and administrators trying to > > troubleshoot. > > > > I don't know the best way to handle this, but this seems like a > > reasonable place to start. > > > > OK, thanks for the feedback Ben. If you're good with this patch, it's > fine with me. I don't have any better ideas for how to handle it if we > don't want the ARP response when ports aren't up. > > The main downside is the increase in churn of the logical flow table. > For every new port, we now update the logical flow table twice instead > of just once. > > Just brainstorming here ... > > We could have logical flow pre-requisites, where we could say to only > process this logical flow if a given logical port is bound to a chassis > (is up). That way the logical flows don't change and ovn-controller > handles the change based on port state. > > That's a good bit more complicated than this patch, so maybe we should > just merge this and keep it as something that could be revisited later > if optimizing here seems worthwhile.
That's roughly my thought process too. First get stuff correct, then worry about making it faster where it is necessary. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
