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. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
