[ovs-dev] [PATCH v2] openvswitch: Userspace tunneling.

[Ben Pfaff]

On Thu, Nov 06, 2014 at 09:36:19AM -0800, Pravin Shelar wrote:
> On Wed, Nov 5, 2014 at 4:44 PM, Ben Pfaff <blp at nicira.com> wrote:
> > On Sun, Nov 02, 2014 at 09:29:28PM -0800, Pravin B Shelar wrote:
> > I don't understand why struct udp_header is now marked as packed, or
> > why struct gre_base_hdr is marked as aligned on a 4-byte boundary, or
> > why struct vxlanhdr is marked as packed.
> >
> I thought I will fix it later, but since it is pointed out by Jarno
> and you I will fix it in next iteration.

Thanks.

I think that it is a good idea to get this right from the beginning,
because we tend not to find these issues otherwise until the next LTS
release when I upload to Debian and thereby get testing on RISC
systems.  And that only finds instances exercised by the tests.

> > I am surprised that the user has the ability to enable and disable
> > tunnel push-pop, in ofproto-dpif.c.  I would think that ofproto-dpif
> > should find out whether the datapath supports it.  (It is easy to find
> > out, currently, since only dpif-netdev supports it.)
> >
> There are two flags, ofproto checks backer support and uses the user
> bit to turn on tunneling (ref: ovs_native_tunneling_is_on())
> User control only for testing kernel datapath action otherwise
> tunnel.at test fails since dummy datapath generate tunnel push pop
> action rather than tunnel set action. Do you think we should make user
> command specific to dummy datapath?

If it's easy to make it specific to dummy, and that makes sense to you,
then I would move it, otherwise this is OK, we already have some unixctl
commands for testing.

> > Is tnl_port_build_header() on a fast-path?  If so, then maybe the
> > 'rwlock' in that file should become a fatlock.
> >
> tnl_port_build_header() is not called from fast path. but in DPDK slow
> path is also called in PMD thread context I will convert it to fat rw
> lock. in long term we should RCUfy it.

OK, thanks.