Re: TC stats / hw offload question

Edward Cree
2019-02-18T18:56:18Z

On 14/02/19 12:39, Jamal Hadi Salim wrote:
> On 2019-02-11 6:44 a.m., Edward Cree wrote:
>> My end goal is to implement TC offload in some hw we're designing
>>   here at Solarflare.  So I'm trying to determine what hardware is
>>   expected/required to do.
>> It might be possible to design our new hw so that we can attach a
>>   counter to every action, if that's what TC wants.
>
> It makes sense to have a counter on every action - even if it is
> for debugging purposes. The two most basic actions are "drop" or
> "accept". In TC speak the default action is "classid x:y" which
> typically is to select a queue or give the flow some identity
Perhaps I was insufficiently clear; we're only looking at the switching
side of things (e.g. OVS offload) right now; we don't yet have a plan
for 'delivery' filters (I imagine we'll probably initially port over
our ethtool ntuple filter handling from ef10, though we may end up
going down the TC route there).
So I think at the moment 'classid' isn't relevant (?)

> Note, your counters should also be shareable; example, count all
> the drops in one counter across multiple flows as in the following
> case where counter index 1 is used.
>
> tc flower match foo action drop index 1
> tc flower match bar action drop index 1
[...]
> allow them to specify
> the counter index (assuming you architecture has an indexed table
> of counters).
Our architecture allocates objects (including counters) and returns
opaque handles to them, so we'd need a software table to connect
counter index to FW counter ID.
Also, sharing counters in hw causes extra work for the driver code
that keeps track of which encap actions are getting hit (so it can
keep the neighbour entries alive).  Maybe summing the shared
counters in sw is easier than that, I'm not sure (or maybe encap
action counters should just be kept separate from the counters we
report to TC).

TBH I'm coming to the conclusion that what we should do for the first
version of our driver is just to create a counter per rule and report
it against the first action (only), and for now ignore the index (or
maybe require it to be set to some distinguished value, like 0, to
mean 'allocate', so that as a future extension we can support
shareable counters).

-Ed