> > > > > > > > > > > > If we can do that, isn't it much more simpler to make > > > > > > vnet_hdr_support by default? > > > > > > > > > > Yes, For compatibility filters and COLO still work with the > > > > > original > > > > "vnet_hdr_support". > > > > > For new users, they can enable the new "auto_vnet_hdr" to avoid > > > > > some > > > > issues. > > > > > > > > Question still, so we have > > > > > > > > 1) enable vnet_hdr_support by default > > > > 2) add auto_vnet_hdr and enable it by default > > > > > > > > Using 1) seems much more simpler and can solve this issue. If we > > > > depends on the default behaviour, it should be almost the same. If > > > > we want to teach the mgmt, both should work. Any other advantages > > > > of > > 2)? > > > > > > Using 1) we can't ensure user configure parts of module by itself. > > (vnet_hdr_support = off). > > > In this case, filter data already wrong and the filters can't report > > > any > > transfer error here. > > > > So I think the point is we can't ensure the user configure parts of > > module in any case even if auto_vnet_hdr is introduced. E.g user can > > choose to disable it manually. That's why I think it should not differ > > too much from making vnet_hdr_support enabled by default. >
Rethink about it. Using 1) make things much more simpler except the user config it manually. I will follow your comments make V6 to 1). Thanks Chen >
