[ovs-dev] [PATCH 09/15] tunneling: extend flow_tnl with ipv6 addresses

[Ben Pfaff]

On Wed, Nov 11, 2015 at 11:49:49AM -0200, Thadeu Lima de Souza Cascardo wrote:
> On Tue, Nov 10, 2015 at 02:34:02PM -0800, Ben Pfaff wrote:
> > On Thu, Oct 22, 2015 at 03:29:02PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > > From: Jiri Benc <jbenc-H+wXaHxf7aLQT0dZR+AlfA at public.gmane.org>
> > > 
> > > Note that because there's been no prerequisite on the outer protocol,
> > > we cannot add it now. Instead, treat the ipv4 and ipv6 dst fields in the way
> > > that either both are null, or at most one of them is non-null.
> > > 
> > > [cascardo: abstract testing either dst with flow_tnl_dst_is_set]
> > > 
> > > Signed-off-by: Jiri Benc <jbenc at redhat.com>
> > > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo at redhat.com>
> > > Co-authored-by: Thadeu Lima de Souza Cascardo <cascardo at redhat.com>
> > 
> > One wonders whether it would be worth merging the ip_dst and ipv6_dst
> > fields in struct flow_tnl, using IPv6-mapped IPv4 addresses for the IPv4
> > case.  Did you consider that?
> 
> Yes, I tried that, and had to go back to the way Jiri implemented it. The main
> problem was meta-flow and match. I tried using a union, so meta-flow.inc auto
> generated code would still work. However, when setting IPv4 tunnel addresses,
> the prefix would be all zeroes, not 0:0:0:0:0:0:ffff::. I didn't manage to make
> that work. Maybe now that I have put my head a little more into meta-flow and
> match code, I may find a way to do that. I will take a new look and see if I can
> come back with new code or a better commit message, explaining why that would
> not be the best course in this case.
> 
> When I went back to the original implementation, I knew an explanation about not
> using IPv4-mapped addresses was due, but I must have forgotten after working on
> the testsuite and many rebases.

That all seems reasonable.  I'll look forward to the next revision (I
don't think I've seen one yet but I may just be behind, as usual).