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: <20160204231927.GA2347@salvia>
Date:	Fri, 5 Feb 2016 00:19:27 +0100
From:	Pablo Neira Ayuso <pablo@...filter.org>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	John Fastabend <john.fastabend@...il.com>, amir@...ai.me,
	ogerlitz@...lanox.com, jhs@...atatu.com,
	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 Thu, Feb 04, 2016 at 10:16:56AM +0100, Jiri Pirko wrote:
> Wed, Feb 03, 2016 at 10:27:32AM CET, john.fastabend@...il.com wrote:
> >
> >Also 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. Again future work.
> >
> >Any comments/feedback appreciated.
> 
> I like this being thin and elegant solution. However, ~2 years ago when I
> pushed openvswitch kernel datapath offload patchset, people were yelling
> at me that it is not generic enough solution, that tc has to be able
> to use the api (Jamal :)), nftables as well.

I would be glad to join this debate during NetDev 1.1 too.

I think we should provide a solution that allows people uses both
tc and nftables, this would require a bit of generic infrastructure on
top of it so we don't restrict users to one single solution, in other
words, we allow the user to select its own poison.

> Now this patch is making offload strictly tc-based and nobody seems to
> care :) I do. I think that we might try to find some generic middle layer.

I agree and I'll be happy to help to push this ahead. Let's try to sit
and get together to resolve this.

See you soon.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ