netdev - Re: TC stats / hw offload question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <702dd5b7-c6ed-b669-8270-d44f5ff4fb30@mojatatu.com>
Date:   Thu, 14 Feb 2019 07:39:28 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Edward Cree <ecree@...arflare.com>, netdev <netdev@...r.kernel.org>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Or Gerlitz <gerlitz.or@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        PJ Waskiewicz <pjwaskiewicz@...il.com>,
        Anjali Singhai Jain <anjali.singhai@...el.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: Re: TC stats / hw offload question

On 2019-02-11 6:44 a.m., Edward Cree wrote:

>> Hasnt been necessary thus far.
>> Is your end goal to match and count?
> 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
(one should be able to use the same action on h/w ingress as well
to select a rx DMA ring for example, but that seems uncommon).

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

>   But since the
>   other vendors don't seem to do that, I wondered if there was a
>   reason, or if perhaps the counter resources (and PCI bw to read
>   them) could be saved if all those separate counters aren't really
>   needed.  

Probably nobody has paid attention or asked as you did.
Will let the h/w folks speak for themselves. My understanding
based on experience is counters are cheap. Most modern NICs
and ASICs have a gazillion of them at their disposal.

> Right now the design we are considering would only count
>   packets as-matched, i.e. before any edits.  That's fine for encap
>   — you can calculate the bytes correction in SW — but not for decap
>   since in principle the length of the RXed outer headers could
>   vary (e.g. you might have IP options there).
>

ok, so not much in terms of other types of actions.
But for abstraction sake maybe use "flowid x:y" and have counters
associated with that. Or even make this optional and only attach
a counter if someone says "action ok" and allow them to specify
the counter index (assuming you architecture has an indexed table
of counters).

cheers,
jamal