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
| ||
|
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
Powered by blists - more mailing lists