Ok. I agree.


On Wed, Dec 9, 2020 at 12:35 PM Ben Pfaff <b...@ovn.org> wrote:

> I respect the desire for symmetry, but it might not justify the effort
> of adding the new feature.
>
> On Wed, Dec 09, 2020 at 11:52:32AM -0500, Vasu Dasari wrote:
> > There is no reason for duplication, other than the reason for
> symmetricity
> > of APIs, "send_flow_rem"(which already exists) and "send_flow_add"(could
> be
> > added).
> >
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Wed, Dec 9, 2020 at 11:41 AM Ben Pfaff <b...@ovn.org> wrote:
> >
> > > On Wed, Dec 09, 2020 at 10:37:42AM -0500, Vasu Dasari wrote:
> > > > Ben,
> > > >
> > > > Thanks for the response.
> > > >
> > > > I expect the Learning event to come to the controller when a "learn"
> > > > happens. In this case(as in tutorial), when a learn event happens, a
> new
> > > > mac entry is added to table 10. Controller just needs to know that a
> > > learn
> > > > event happened on this {port, Mac, Vlan}. This information is
> > > sufficiently
> > > > populated in new flow information being added to table "10". So, I am
> > > > leaning towards using a flow-monitoring on the table to see when an
> entry
> > > > is added or removed to rely on MAC entry got added or removed to the
> > > > switching pipeline.
> > > >
> > > > "learn" action has options like "limit" which limits number of
> entries
> > > > added to a table, "send_flow_rem" which tells the controller when a
> flow
> > > is
> > > > removed, etc. All these flags are applied on top of the flows that
> are
> > > > added. I was hoping to see an option like "send_flow_add" which
> tells the
> > > > controller when a flow is added. Maybe this could be an enhancement
> to
> > > > "learn" action. What do you think?
> > >
> > > It sounds like flow monitoring already covers that.  Is there a reason
> > > to duplicate the functionality?
> > >
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to