On Fri, May 16, 2014 at 5:31 AM, Jesse Gross <je...@nicira.com> wrote: > On Wed, May 14, 2014 at 6:33 PM, Han Zhou <zhou...@gmail.com> wrote: >> On Thu, May 15, 2014 at 8:07 AM, Jesse Gross <je...@nicira.com> wrote: >>> On Tue, May 13, 2014 at 6:29 PM, Han Zhou <zhou...@gmail.com> wrote: >>>> Hi Jesse, >>>> >>>> On Wed, May 14, 2014 at 5:05 AM, Jesse Gross <je...@nicira.com> wrote: >>>>> On Tue, May 13, 2014 at 12:20 AM, Zhou, Han <hzh...@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 _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
