Both paper and explanation were most helpful. Thank you. Solved the issue.
> I'll try to explain a typical dataflow... > > A packet arrives at the Host, goes to the vswitch. If there's no matching > entry in the datapath flows CACHE, implemented in the ovs kernel datapath > module, then the packet is sent to the user space controller - vswitchd. > However, If there's a cached entry then it's switched according to the > matching action. > > When the packet arrives the user space vswitchd (due to a cache miss as > explained above), this is the entity that implements the openflow stack. > The openflow implementation in the user space code uses multiple tables, > priorities etc. to decide on what is the ACTION associated with the new > flow, and then it translates the multiple tables/priorities etc into a > DATAPATH flow - single flow (a collapse of all the relevant fields from > the relevant openflow tables that lead to the specific action. So no now > the result of the openflow vswitchd for the relevant flow at hand, is a > single flow-spec (flat classifier - not multiple tables etc) and an > action. At this point the ovswitchd installs this flow+action into the > datapath module in the kernel and subsequent packets will be switched by > the vswitch in the kernel. > > I hope this helps. > > - Tal > > -----Original Message----- > From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of > dsa...@cs.technion.ac.il > Sent: Sunday, November 15, 2015 2:09 PM > To: discuss@openvswitch.org > Subject: Re: [ovs-discuss] find the goto table instruction in the code > > > Pardon my ignorance then, but it seems I got it wrong when I thought the > main flow tables were in the Kernel. Then, if the main flows are stored in > userspace, does that mean the data packets arrive directly to the > userspace client code and treated there? Instead of arriving to some > listener process in the kernel? I thought that packets arrive to the > kernel code directly and if they, for example, are redirected to another > port, the userspace doesn't even know the packet arrived or existed and no > upcalls are generated. > > Can you shed some light please? > >>> On Nov 12, 2015, at 4:52 AM, dsa...@cs.technion.ac.il wrote: >>> >>> Hi to all, >>> >>> I want to locate the code (I imagine it is inside of the Kernel >>> module >>> datapath) where when a flow is found, the instructions are executed, >>> it finds the "goto table" instruction and redirects the packet to >>> another table. >> >> "goto table" is an entirely userspace concept. The kernel flows are a >> cache of recently seen flows and their associated actions with all the >> table jumps removed. Here's an entry from the FAQ that help explain >> it: >> >> -=-=-=-=-=-=-=-=-=- >> Q: I hear OVS has a couple of kinds of flows. Can you tell me about >> them? >> >> A: Open vSwitch uses different kinds of flows for different purposes: >> >> • OpenFlow flows are the most important kind of flow. OpenFlow >> controllers use these flows to define a switch's policy. OpenFlow >> flows support wildcards, priorities, and multiple tables. >> >> When in-band control is in use, Open vSwitch sets up a few "hidden" >> flows, with priority higher than a controller or the user can >> configure, that are not visible via OpenFlow. (See the "Controller" >> section of the FAQ for more information about hidden flows.) >> >> • The Open vSwitch software switch implementation uses a second kind >> of flow internally. These flows, called "datapath" or "kernel" flows, >> do not support priorities and comprise only a single table, which >> makes them suitable for caching. (Like OpenFlow flows, datapath flows >> do support wildcarding, in Open vSwitch 1.11 and later.) OpenFlow >> flows and datapath flows also support different actions and number ports >> differently. >> >> Datapath flows are an implementation detail that is subject to change >> in future versions of Open vSwitch. Even with the current version of >> Open vSwitch, hardware switch implementations do not necessarily use >> this architecture. >> >> Users and controllers directly control only the OpenFlow flow table. >> Open vSwitch manages the datapath flow table itself, so users should >> not normally be concerned with it. >> -=-=-=-=-=-=-=-=-=- >> >> --Justin >> >> >> > > > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
