On Sep 3, 2012, at 3:56 PM, Jesse Gross wrote: > Hi Kyle, > > Sorry again about the long delay in getting back to you on this and > thanks for being so patient. I definitely intend to be much quicker > about future patches. > No worries on my end! I was just hoping to try and start getting some of these pushed up in the next few weeks.
> I think your approach of doing incremental changes is a good one since > the full set of changes is pretty large. The one thing that I think > we should be careful about is trying not to break compatibility too > many times. Since my intention is to switch wholesale over to this > new mechanism and drop the old, we'll have to do it at least once, > which is why we never sent the tunneling code upstream. However, we This all makes sense and I agree with the approach here. > should avoid doing it more than that, which is obviously the downside > of smaller incremental changes. Do you have a rough idea of the order > in which you plan to procede? My inclination is that we should get > all of the kernel changes in so that both the old and new mechanisms > work fully, start adding userspace code that incrementally relies on > more and more of the new code, and then drop the old kernel code. > This is exactly the approach that I want to proceed with. I see in a separate email you provided a bunch of feedback. I'll go through that tonight and work on an updated patch for tomorrow. Once we get the initial set of patches up, I'll proceed to the userspace portions of the changes. Thanks, Kyle > On Fri, Aug 31, 2012 at 7:02 PM, Kyle Mestery (kmestery) > <kmest...@cisco.com> wrote: >> Jesse: >> >> Are you going to have a chance to review these next week? Can you also >> comment on if you want to iterate over all of Simon's original patches, or go >> down the path I started with these patches, which was to try and get the >> initial tun_key changes in, leaving existing functionality in place, before >> moving on to the rest of the series? >> >> Thanks! >> Kyle >> >> On Aug 29, 2012, at 8:17 PM, Simon Horman wrote: >> >>> On Wed, Aug 29, 2012 at 10:00:45AM -0400, Kyle Mestery wrote: >>>> This is a first pass at providing a tun_key which can be >>>> used as the basis for flow-based tunnelling. The tun_key >>>> includes and replaces the tun_id in both struct ovs_skb_cb >>>> and struct sw_tun_key. >>>> >>>> In ovs_skb_cb tun_key is a pointer as it is envisaged that it will grow >>>> when support for IPv6 to an extent that inlining the structure will result >>>> in ovs_skb_cb being larger than the 48 bytes available in skb->cb. >>>> >>>> As OVS does not support IPv6 as the outer transport protocol for tunnels >>>> the IPv6 portions of this change, which appeared in the previous revision, >>>> have been dropped in order to limit the scope and size of this patch. >>>> >>>> This patch allows all existing tun_id behaviour to still work. However, >>>> when the userspace code is updated to make use of the new tun_key, the >>>> old behaviour will be deprecated and removed. >>>> >>>> Signed-off-by: Kyle Mestery <kmest...@cisco.com> >>>> Cc: Simon Horman <ho...@verge.net.au> >>>> --- >>>> V2: >>>> - Fix blank line addition/removal found by Simon. >>>> - Fix hex printing output found by Simon. >>> >>> Thanks >>> >>> Acked-by: Simon Horman <ho...@verge.net.au> >> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
