[ovs-discuss] Early addition of flows in the kernel.

[jimson chacko]

Hi,

Can you give an example flow which has one entry in the user space and
multiple entries in the kernel ?

Ok. Now I know OVS is designed to push the flows in the kernel only during
handle_upcalls. But there are exceptions. One is when the flow is deleted.
One is when a flow (which is already present in the kernel) is modified. In
these cases the effect is immediate. That is, vswitchd will sync the flow
deletion/modification to the kernel without waiting for packets. Am I
correct ?

Regards
Jimson

On Tue, Oct 13, 2015 at 9:51 AM, Jesse Gross <jesse at nicira.com> wrote:

> Please don't drop the mailing list or top post.
>
> Yes. Please see here for more information on the design of OVS:
> http://openvswitch.org/support/papers/nsdi2015.pdf
>
> On Mon, Oct 12, 2015 at 6:30 PM, jimson jimson <jimsonchacko at gmail.com>
> wrote:
> > You mean to say one user space flow can result in many in the kernel?
> > ________________________________
> > From: Jesse Gross
> > Sent: ‎13-‎10-‎2015 05:37 AM
> > To: jimson chacko
> > Cc: discuss at openvswitch.org
> > Subject: Re: [ovs-discuss] Early addition of flows in the kernel.
> >
> > On Mon, Oct 12, 2015 at 5:17 AM, jimson chacko
> > <jimsonchacko at gmail.com> wrote> Hi,
> >>
> >> As per my understanding, OVS inserts the flow in the kernel when an
> >> exception packet is handled by the vswitchd (ofcourse when matching flow
> >> is
> >> present in the vswitchd).
> >>
> >> Is it possible to push the flow into the kernel as soon as the flow gets
> >> added to vswitchd ? This enables in avoiding the exception mechanism and
> >> hence faster processing.
> >
> > No.
> >
> >> Can you briefly let me know why the design was kept so ?
> >
> > It's not possible to do in a general and efficient manner. The flows
> > kept by the kernel are significantly simpler than the ones in
> > userspace to make them easier to process. The consequence is that they
> > are less expressive and you can potentially need a lot more of them to
> > cover the entire space, which is prohibitively expensive.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20151013/3496bf84/attachment-0002.html>