[ovs-dev] [RFC PATCH 1/1]: Enhance conjunctive match support in OVN

Numan Siddique nusiddiq at redhat.com
Wed Feb 7 03:57:37 UTC 2018


On Feb 7, 2018 1:06 AM, "Ben Pfaff" <blp at ovn.org> wrote:

On Wed, Feb 07, 2018 at 12:12:38AM +0530, Numan Siddique wrote:
> On Tue, Feb 6, 2018 at 11:31 PM, Ben Pfaff <blp at ovn.org> wrote:
>
> > On Fri, Feb 02, 2018 at 09:06:39PM +0530, nusiddiq at redhat.com wrote:
> > > From: Numan Siddique <nusiddiq at redhat.com>
> > >
> > > Presently, if a logical flow has possible conjunctive matches, OVN
> > expression
> > > parser has support for that. But certain fields like ip4.src, ip4.dst
> > are not
> > > considered as dimensions in the conjunctive matches.
> > >
> > > In order to support all the possible fields as dimensions, this patch
> > has added
> > > a new expression type 'EXPR_T_CONJ'. After a expression is simplified
by
> > > expr_simplify(), before calling expr_normalize(), a new function
> > > expr_eval_conj() is called, which evaluates for possible dimensions
for
> > > conjunctive matches.
> > >
> > > For example if the match expression is
> > > "ip4 && ip4.src == {10.0.0.4, 10.0.0.5, 10.0.0.6} &&
> > >  ip4.dst == {20.0.0.4, 20.0.0.5, 20.0.0.6}"
> > >
> > > expr_simplify() would have generated the expression as -
> > >
> > > AND(CMP(IP4),
> > >     OR((CMP(ip4.src == 10.0.0.4), CMP(ip4.src == 10.0.0.5),
> > >         CMP(ip4.src == 10.0.0.6)),
> > >     OR((CMP(ip4.dst == 20.0.0.4), CMP(ip4.src == 20.0.0.5),
> > >         CMP(ip4.src == 20.0.0.6))).
> > >
> > > expr_eval_conj() would return a new expression something like
> > >
> > > CONJ(AND(CMP(IP4),
> > >          OR((CMP(ip4.src == 10.0.0.4), CMP(ip4.src == 10.0.0.5),
> > >              CMP(ip4.src == 10.0.0.6))),
> > >      AND(CMP(IP4),
> > >          OR((CMP(ip4.dst == 20.0.0.4), CMP(ip4.dst == 20.0.0.5),
> > >              CMP(ip4.dst == 20.0.0.6))))
> > >
> > > expr_normalize() would normalize each individual 'AND' clause in the
> > CONJ and
> > > expr_to_matches() would add the necessary conjunctive matches.
> > >
> > > TODO: If the proposed approach is reasonable, then test cases and
> > necessary
> > > code comments needs to be added.
> >
> > I think I like this approach, but I also think that it's worthwhile
> > trying to figure out whether it's possible to do it without adding the
> > extra EXPR_T_CONJ type and the extra processing step.  I started playing
> > with that idea yesterday.  I think it's possible, but I didn't actually
> > finish implementing it.
> >
> >
> That's great. Looking forward for those patches whenever they are ready
:).

Oh, I didn't want to take over the series from you, I'm suggesting a
possible direction.  Is that a direction you could try to go?


Ok. Got it. I will try to explore in that direction.

Thanks
Numan


More information about the dev mailing list