Messages in this thread | | | Date | Fri, 26 Nov 2021 11:14:31 -0800 | From | Jakub Kicinski <> | Subject | Re: [PATCH v2 net-next 21/26] ice: add XDP and XSK generic per-channel statistics |
| |
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.
| |