RE: [PATCH V5 1/3] net/filter: Optimize transfer protocol for filter-mirror/redirector

[Zhang, Chen]

> > > > > >
> > > > > > 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

>