[ovs-discuss] VXLAN problems

Han Zhou zhouhan at gmail.com
Tue May 20 02:41:27 UTC 2014


On Fri, May 16, 2014 at 5:31 AM, Jesse Gross <jesse at nicira.com> wrote:
> On Wed, May 14, 2014 at 6:33 PM, Han Zhou <zhouhan at gmail.com> wrote:
>> On Thu, May 15, 2014 at 8:07 AM, Jesse Gross <jesse at nicira.com> wrote:
>>> On Tue, May 13, 2014 at 6:29 PM, Han Zhou <zhouhan at gmail.com> wrote:
>>>> Hi Jesse,
>>>>
>>>> On Wed, May 14, 2014 at 5:05 AM, Jesse Gross <jesse at nicira.com> wrote:
>>>>> On Tue, May 13, 2014 at 12:20 AM, Zhou, Han <hzhou8 at ebay.com> wrote:
>>>>>> In fact, MTU specified by VM doesn't make any sense in a virtualized
>>>>>> environment. Maybe you can try this patch if you are interested:
>>>>>>
>>>>>> http://openvswitch.org/pipermail/dev/2014-May/040027.html
>>>>>
>>>>> This message seems to be have been taken by my spam filter, so I don't
>>>>> have the original copy. However, while it is good to prototype
>>>>> implementations in OVS, I don't think that it is really feasible to
>>>>> include these types of changes to the OVS VXLAN implementation at this
>>>>> time. The protocol isn't designed to be independently extensible so
>>>>> usage of reserve bits needs to be done by the authors rather than in
>>>>> an ad hoc manner.
>>>>
>>>> Thanks for your comments. I agree that it is kind of ad-hoc, and
>>>> that's why I posted the patch as RFC to collect comments first.
>>>> But considering the dramatic performance gains, I think it should be
>>>> valuable for the community. Would it be helpful if we implement it
>>>> with a configurable parameter and make it disabled by default? I think
>>>> many people will benefit from this. What's your suggestion?
>>>
>>> I think doing this will result in a VXLAN implementation that is
>>> complicated and difficult to maintain. You'll need to maintain this as
>>> an out of tree patch unless you can show a larger degree of support.
>>
>> Jesse, in fact it will be simply checking a configured flag in sending
>> side (in function handle_offloads()) to decide whether setting the S
>> bit and GSO information. All the other part of code can be kept the
>> same. So it should not be difficult to maintain, and can be merged to
>> kernel tree. And I will be happy to maintain and support if this
>> feature is valuable.
>
> Imagine if instead you wanted to unilaterally use some reserved bits
> in the TCP header and hide it behind a configuration parameter. I
> think most people would consider this to be unreasonable.
>
> Sorry, I'm not applying this at this time.

Jesse, I get your point. I put this optimization in github for those
who might be interested:
https://github.com/hzhou8/openvswitch/commit/9a7deb8b432ce83a9c09d7d4ff85fa050f7dd2be

I will check with VXLAN authors to see if it can be a formal solution.
Thanks for your feedbacks.

Best regards,
Han



More information about the discuss mailing list