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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Feb 2016 07:21:29 -0500
From:	Jamal Hadi Salim <>
To:	Or Gerlitz <>,
	John Fastabend <>
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

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.


Powered by blists - more mailing lists