I would like to thank you for your time, comments, nitpicking as well as encouraging. One thing needs clarification I think, that is, that those flags describe driver static feature sets - which are read-only. They have nothing in common with driver runtime configuration change yet. Runtime change of this state can be added but it needs a new variable and it can be done later on if someone needs it. Obviously, it is not possible to make everybody happy, especially with XDP_BASE flags set. To be honest, this XDP_BASE definition is a syntactic sugar for me and I can live without it. We can either remove it completely, from which IMO we all and other developers will suffer later on, or maybe we can agree on these two helper set of flags: XDP_BASE (TX, ABORTED, PASS, DROP) and XDP_LIMITED_BASE(ABORTED,PASS_DROP). What do you think? I am also going to add a new XDP_REDIRECT_TARGET flag and retrieving XDP flags over rtnelink interface. I also think that for completeness, ethtool implementation should be kept together with rtnelink part in order to cover both ip and ethtool tools. Do I have your approval or disagreement? Please let me know. Both AF_XDP_ZEROCOPY and XDP_SOCK_ZEROCOPY are good to me. I will pick the one XDP_SOCK_ZEROCOPY unless there are protests. I don't think that HEADROOM parameter should be passed via the flags. It is by nature a number and an attempt to quantize with flags seems to be an unnatural limitation for the future. Thanks Marek
