netdev - Re: [RFC PATCH 0/7] tc cls

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]

Date:	Tue, 02 Feb 2016 06:58:22 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
CC:	anjali.singhai@...el.com, jesse.brandeburg@...el.com,
	jhs@...atatu.com, ast@...com, donald.c.skidmore@...el.com,
	horms@...ge.net.au, netdev@...r.kernel.org, tgraf@...g.ch,
	davem@...emloft.net
Subject: Re: [RFC PATCH 0/7] tc cls_u32 hardware interface

On 16-02-02 03:49 AM, Jiri Pirko wrote:
> Mon, Feb 01, 2016 at 02:48:32AM CET, john.fastabend@...il.com wrote:
>> I was waiting for net-next to open to submit this but it seems like
>> a good idea to get an RFC out there for folks to start looking over.
>>
>> This extends the setup_tc framework so it can support more than just
>> the mqprio offload and push other classifiers and qdiscs into the
>> hardware. The series here targets the u32 classifier and ixgbe
>> driver. I worked out the u32 classifier because it is protocol
>> oblivious and aligns with multiple hardware devices I have access
>> to. I did an initial implementation on ixgbe because (a) I have one
>> in my box (b) its a stable driver and (c) it is relatively simple
>> compared to the other devices I have here but still has enough
>> flexibility to exercise the features of cls_u32.
>>
>> I intentionally limited the scope of this series to the basic
>> feature set. Specifically this uses a 'big hammer' feature bit
>> to do the offload or not. If the bit is set you get offloaded rules
>> if it is not then rules will not be offloaded. If we can agree on
>> this patch series there are some more patches on my queue we can
>> talk about to make the offload decision per rule using flags similar
>> to how we do l2 mac updates. Additionally the error strategy can
>> be improved to be hard aborting, log and continue, etc. I think
>> these are nice to have improvements but shouldn't block this series.
>> I am working on similar support for the other Intel devices now
>> as well namely i40e and fm10k.
>>
>> Also in the future work bin by adding get_parse_graph and
>> set_parse_graph attributes as in my previous flow_api work we
>> can build programmable devices and programmatically learn when
>> rules can or can not be loaded into the hardware.
>>
>> Note this series is on a slightly behind net-next stack I think it
>> should apply to the latest but I haven't updated the series for
>> awhile I'll do that soon I was sort of waiting for net-next to
>> open to do this.
>>
>> Any comments/feedback appreciated.
> 
> I like this patchset. I gave it a quick peek and I it looks to me like
> the correct way to go. There are couple of things needed to be decided

Great.

,
> as you described them (e. g. per-rule offload) - we should discuss them
> on netdev conference. I hope you will be there.
> 

I'll be at the conference so we can discuss it there. Although even
without the per-rule flow this set is useful. Like I noted I view that
as an optimization and its much more useful on a NIC where host traffic
is the norm vs a switch where host traffic is most likely the exception.

> I curious about how do you plan to expose the parse graphs get/set ops...

The current stack of patches I have on my dev box use a new netlink
handler. ethtool could work as well but my preference is netlink in
this case.