netdev - Re: [PATCH net-next] net, sched: add clsact qdisc

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: <568E52E8.1010804@iogearbox.net>
Date:	Thu, 07 Jan 2016 12:58:32 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:	davem@...emloft.net, jhs@...atatu.com, john.fastabend@...il.com,
	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net, sched: add clsact qdisc

On 01/07/2016 11:09 AM, Hannes Frederic Sowa wrote:
> Hi Daniel and Alexei,
>
> On 07.01.2016 04:53, Alexei Starovoitov wrote:
>> On Wed, Jan 06, 2016 at 02:00:56AM +0100, Daniel Borkmann wrote:
>>>
>>> I decided to extend the sch_ingress module with clsact functionality so
>>> that commonly used code can be reused, the module is being aliased with
>>> sch_clsact so that it can be auto-loaded properly. Alternative would have been
>>> to add a flag when initializing ingress to alter its behaviour plus aliasing
>>> to a different name (as it's more than just ingress). However, the first would
>>> end up, based on the flag, choosing the new/old behaviour by calling different
>>> function implementations to handle each anyway, the latter would require to
>>> register ingress qdisc once again under different alias. So, this really begs
>>> to provide a minimal, cleaner approach to have Qdisc_ops and Qdisc_class_ops
>>> by its own that share callbacks used by both.
>> ...
>>> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
>>
>> we've been going back and forth on the design and this final approach
>> presented seems to be the best, since pros outweigh the cons.
>>
>> Acked-by: Alexei Starovoitov <ast@...nel.org>
>
> One question:
>
> With the advance in lockless qdiscs by John Fastabend, is it possible to push the handle_egress hook further down into sched layer?

Idea was that this is done before we pick txq as stated. F.e., could also
be that we end up not having enqueue handler, thus moving this further down
(not sure if there's a good place?), might make it all more scattered resp.
complex to cover all parts.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html