On Fri, 26 Nov 2021 19:47:17 +0100 Toke Høiland-Jørgensen wrote: > > Fair. In all honesty I said that hoping to push for a more flexible > > approach hidden entirely in BPF, and not involving driver changes. > > Assuming the XDP program has more fine grained stats we should be able > > to extract those instead of double-counting. Hence my vague "let's work > > with apps" comment. > > > > For example to a person familiar with the workload it'd be useful to > > know if program returned XDP_DROP because of configured policy or > > failure to parse a packet. I don't think that sort distinction is > > achievable at the level of standard stats. > > > > The information required by the admin is higher level. As you say the > > primary concern there is "how many packets did XDP eat". > > Right, sure, I am also totally fine with having only a somewhat > restricted subset of stats available at the interface level and make > everything else be BPF-based. I'm hoping we can converge of a common > understanding of what this "minimal set" should be :) > > > Speaking of which, one thing that badly needs clarification is our > > expectation around XDP packets getting counted towards the interface > > stats. > > Agreed. My immediate thought is that "XDP packets are interface packets" > but that is certainly not what we do today, so not sure if changing it > at this point would break things? I'd vote for taking the risk and trying to align all the drivers.
