[ovs-dev] [RFC PATCH 2/5] odp-util: Enable communicating outer tunnel to/from the kernel.

Kyle Mestery (kmestery) kmestery at cisco.com
Fri Sep 28 22:56:42 UTC 2012


On Sep 28, 2012, at 5:54 PM, Jesse Gross wrote:
> On Fri, Sep 28, 2012 at 3:44 PM, Kyle Mestery (kmestery)
> <kmestery at cisco.com> wrote:
>> On Sep 28, 2012, at 5:40 PM, Jesse Gross wrote:
>>> On Fri, Sep 28, 2012 at 11:59 AM, Kyle Mestery (kmestery)
>>> <kmestery at cisco.com> wrote:
>>>> On Sep 28, 2012, at 1:12 PM, Jesse Gross wrote:
>>>>> Now that both the kernel and userspace can handle information about
>>>>> the tunnel outer headers this adds userspace support for communicating
>>>>> between the two.  At the moment userspace doesn't know how to do
>>>>> anything with the extra information on receive and will only generate
>>>>> actions containing tun_id.  However, both sides know how to ignore the
>>>>> extra information.
>>>>> 
>>>>> Signed-off-by: Jesse Gross <jesse at nicira.com>
>>>> 
>>>> 
>>>> The patch I just submitted overlaps with this patch a little bit. I think there wasn't
>>>> a really set delineation between what I was doing and what you were doing, so
>>>> we may have to merge this patch with mine. I think we both pretty much made
>>>> similar changes though, so it shouldn't be too bad. Acking this patch for now,
>>>> assuming we'll work through the merge bits.
>>> 
>>> I agree the changes are pretty similar.  My inclination is that it's a
>>> little easier to use the version in my patch if that's OK with you for
>>> a couple of reasons:
>>> * I'm not sure that the change logically belongs in the second patch
>>> of your series.  It could be moved into the first patch though.
>>> * There isn't much benefit to userspace supporting both models of
>>> kernel tunnel implementation because the kernel will reject any
>>> actions that it doesn't understand.  As a result, once this patch goes
>>> in we will immediately require a new version of the kernel module.
>>> Ideally I'd like to push that requirement back as late as practical so
>>> that we can start applying patches without worrying about breaking
>>> compatibility more than necessary.  However, when we do put it in, we
>>> might as well go all the way and drop support for the old mechanism in
>>> userspace.
>> 
>> That makes sense to me. Do you want me to rebase my first patch and fold this
>> one into that? I can then rework my second patch based on this. Or even, we
>> could move this patch as a second patch in my series, and I could just rebase
>> my third patch.
> 
> I actually don't think that much needs to be done - this patch depends
> on the previous patch to do all the userspace flow changes and we
> don't really want to roll all of them together.  I would just drop the
> odp-util.c changes from your second patch and then your patches fit in
> right before my series.  That will avoid the conflict and shouldn't
> have any dependency problems.
> 
OK, got it.

> I haven't had a chance to review your patches that closely yet but my
> impression is that the bulk of the second patch doesn't have any
> changes visible to userspace.  Is that right?

That's correct.


More information about the dev mailing list