Yea I saw that but my question is ...should I be changing that? I am sort
of new to ovs. is there any other way to connect switches?

Since the same packet is being forwarded by all switches it reaches that
recursion limit. so apart from increasing this limit ..do we have another
solution?


Thanks for all the input! Im learning a lot

KP


On Thu, Aug 14, 2014 at 1:38 PM, Ben Pfaff <b...@nicira.com> wrote:

> You can increase MAX_RESUBMIT_RECURSION in ofproto-dpif-xlate.c.
>
> On Thu, Aug 14, 2014 at 01:22:55PM -0400, Krishna Pratap wrote:
> > yes Ben, you maybe right. I saw it in log file when i enabled debugging .
> >
> >
> *2014-08-12T10:55:26.658Z|00070|ofproto_dpif_xlate(handler_1)|ERR|resubmit
> > actions recursed over 64 times*
> >
> > Is there a way to work around this? how can i remove this limit to see if
> > it crashes or not. are there any other way to connect switches together
> > apart from patch ports and Veth pairs?
> >
> > Thanks,
> > KP
> >
> >
> >
> > On Thu, Aug 14, 2014 at 1:01 PM, Ben Pfaff <b...@nicira.com> wrote:
> >
> > > On Wed, Aug 13, 2014 at 6:57 PM, Flavio Leitner <f...@redhat.com>
> wrote:
> > > > If it's kernel DP, then patch ports are internal ports which during
> TX
> > > > inserts the packet (skb) into the CPU backlog queue
> > > (enqueue_to_backlog())
> > > > for later processing.  Later on, the backlog queue is processed
> > > > (process_backlog()) and the packet is actually received by the other
> > > port.
> > >
> > > I missed that we're talking about patch ports.  That explains the whole
> > > issue.
> > >
> > > Patch ports are implemented in userspace regardless of the datapath in
> use.
> > > They do not exist as ports visible from the kernel (definitely not as
> > > internal
> > > ports).  Hops across patch ports are "optimized out" in userspace, but
> the
> > > recursion is limited to 64 levels, hence the issue you're seeing.
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Krishna Pratap Singh
>



-- 
Best Regards,
Krishna Pratap Singh
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to