[ovs-discuss] VXLAN problems

[Han Zhou]

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.

Best regards,
Han