On Thu, 23 May 2019 17:40:08 +0100, Edward Cree wrote: > On 23/05/2019 17:11, Jakub Kicinski wrote: > > On Thu, 23 May 2019 09:19:49 -0400, Jamal Hadi Salim wrote: > >> That would still work here, no? There will be some latency > >> based on the frequency of hardware->kernel stats updates. > > I don't think so, I think the stats are only updated on classifier > > dumps in Ed's code. > Yep currently that's the case, but not as an inherent restriction (see > my other mail).
I think we can all agree that the current stats offload only reporting up-to-date HW stats when classifiers are dumped makes slight mockery of the kernel API guarantees. I feel like HW vendors found a subset of the ABI to poke things in and out of the hardware, and things work correctly if you limit yourself to that very subset. So you only get up-to-date stats if you dump classifiers, if you dump actions - no dice. Whether it's on you to fix this is debatable :) Since you're diving into actions and adding support for shared ones, I'd say it's time to rectify the situation. Let's look at it this way - if you fix the RTM_GETACTION you will necessarily add the cookie and all the other stuff you need in your upcoming driver :) > > But we can't be 100% sure without seeing driver code. > Would it help if I posted my driver code to the list? It's gonna be > upstream eventually anyway, it's just that the driver as a whole > isn't really in a shape to be merged just yet (mainly 'cos the > hardware folks are planning some breaking changes). But I can post > my TC handling code, or even the whole driver, if demonstrating how > these interfaces can be used will help matters. From my perspective - you answered the question so I'm at 100% now ;)
