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
