On Sat, Jan 26, 2013 at 03:16:24PM -0800, Ethan Jackson wrote:
> > Did you consider reference-counting the backer ports instead of doing a
> > search per-port-destruction?
>
> I did. I'm not sure it's necessary though. This isn't in the fast
> path, so the performance benefit doesn't really help
> Did you consider reference-counting the backer ports instead of doing a
> search per-port-destruction?
I did. I'm not sure it's necessary though. This isn't in the fast
path, so the performance benefit doesn't really help. I think it's
less complex to put all of this logic into a single funct
Hi Jarno,
Sorry it's taken me so long to get back to this. I'm in the process
of fixing the code up to send out for final review, and hence going
through the old comments.
> The last line makes the odp_to_ofport_map a "multimap", when multiple tunnels
> with the same ODP port number are inserted
On Wed, Jan 09, 2013 at 03:43:47PM -0800, Ethan Jackson wrote:
> With this patch, ovs-vswitchd uses flow based tunneling
> exclusively. I.E. each kind of tunnel shares a single tunnel
> backer in the datapath. Tunnel headers are set by userspace using
> the ipv4_tunnel datapath action. There are
On Jan 10, 2013, at 1:43 , ext Ethan Jackson wrote:
> @@ -1531,12 +1550,19 @@ port_construct(struct ofport *port_)
>
> port->odp_port = dpif_port.port_no;
>
> -/* Sanity-check that a mapping doesn't already exist. This
> - * shouldn't happen. */
> -if (odp_port_to_ofp_port(ofpr
With this patch, ovs-vswitchd uses flow based tunneling
exclusively. I.E. each kind of tunnel shares a single tunnel
backer in the datapath. Tunnel headers are set by userspace using
the ipv4_tunnel datapath action. There are still some significant
pieces of work to do, but the basic building bl
