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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 3 Feb 2016 07:21:29 -0500 From: Jamal Hadi Salim <jhs@...atatu.com> To: Or Gerlitz <ogerlitz@...lanox.com>, John Fastabend <john.fastabend@...il.com> Cc: amir@...ai.me, jiri@...nulli.us, jeffrey.t.kirsher@...el.com, netdev@...r.kernel.org, davem@...emloft.net Subject: Re: [net-next PATCH 0/7] tc offload for cls_u32 on ixgbe On 16-02-03 05:31 AM, Or Gerlitz wrote: > On 2/3/2016 12:21 PM, John Fastabend wrote: >> Thanks, we will need at least a v2 to fixup some build errors >> with various compile flags caught by build_bot and missed by me. > Hi John, > > You didn't mark that as RFC... but we said this direction/approach yet > to be talked @ netdev next-week, so.. can you clarify? > > I suggest not to rush and asking pulling this, lets have the tc workshop > beforehand... > Yes, the tc workshop is a good place for this. I think we can spill some of it into the switchdev workshop (which is a nice flow since that happens later). Some comments: 1) "priorities" for filters and some form of "index" for actions is is needed. I think index (which tends to be a 32 bit value is what Amir's patches refered to as "cookie" - or at least some hardware can be used to query the action with). Priorities maybe implicit in the order in which they are added. And the idea of appending vs exclusivity vs replace (which netlink already supports) is important to worry about (TCAMS tend to assume an append mode for example). 2) I like the u32 approach where it makes sense; but sometimes it doesnt make sense from a usability pov. I work with some ASICs that have 10 tuples that are fixed. Yes, a user can describe a policy with u32 but flower would be more usable say with flower (both programmatic and cli) 3) The concept of "hook address" is important to be able to express. Amir's patches seemed to miss that (and John brought it up in an email). It could be as simple as ifindex + hookid. With ifindex of 0 meaning all ports and maybe hookid of 0 meaning all hooks. Hook semantics are as mentioned by John (as it stands right now in/egress) 4) Why are we forsaking switchdev John? This is certainly re-usable beyond NICs and SRIOV. 5)What happened to being both able to hardware and/or software? Anyways, I think Seville would be a blast! Come one, come all. cheers, jamal
Powered by blists - more mailing lists