On 2020-05-22 12:16 p.m., Vlad Buslov wrote:
On Thu 21 May 2020 at 20:02, Jakub Kicinski <k...@kernel.org> wrote:
On Thu, 21 May 2020 17:36:12 +0300 Vlad Buslov wrote:
Hi Edward, Cong,


Do you really need to dump classifiers? If you care about stats
the actions could be sufficient if the offload code was fixed
appropriately... Sorry I had to say that.

Technically I need neither classifier nor action. All I need is cookie
and stats of single terminating action attached to filter (redirect,
drop, etc.). This can be achieved by making terse dump output that data
for last extension on filter. However, when I discussed my initial terse
dump idea with Jamal he asked me not to ossify such behavior to allow
for implementation of offloaded shared actions in future.



Trying to recollect our discussion (please forgive me if i am
rehashing). old skule hardware model typically is ACL style with one
action - therefore concept of tying a counter with with
a classifier is common.

Other hardware i am familiar with tends to have a table of counters.
More an array with indices.
In the shared case using the same counter index from multiple
tables implies it is shared. Note "old skule" does not have
a concept of sharing.

So i was more worried about assuming the "old skule" model
at the expense of other hardware models.
We should be able to dump different tables from hardware.
Mostly these could be tables of actions. And counter tables
look like a gact action.

From s/w:
If what is needed is to just dump explicit stats a gact
action with a cookie and an index would suffice.
i.e tc match foobar \
action continue cookie blah index 15 \
action ...
action mirred redirect ...

of course this now adds extra cycles in the s/w datapath but
advantage is it means you can cheaply either get
individual counters (get action gact index 15) or dump all gact actions
and filter in user space for your cookie. Or introduce a dump
cookie filter in the kernel (similar to the "time since" action
dump filter).

cheers,
jamal

Speaking about shared action offload, I remember looking at some RFC
patches by Edward implementing such functionality and allowing action
stats update directly from act, as opposed to current design that relies
on classifier to update action stats from hardware. Is that what you
mean by appropriately fixing offload code? With such implementation,
just dumping relevant action types would also work. My only concern is
that the only way to dump actions is per-namespace as opposed to
per-Qdisc of filters, which would clash with any other cls/act users on
same machine/hypervisor.


[...]


Reply via email to