netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: davem@davemloft.net, jhs@mojatatu.com, john.fastabend@gmail.com,
	eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net, sched: add clsact qdisc
Date: Thu, 07 Jan 2016 12:58:32 +0100	[thread overview]
Message-ID: <568E52E8.1010804@iogearbox.net> (raw)
In-Reply-To: <568E395F.8020504@stressinduktion.org>

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@iogearbox.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@kernel.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

  reply	other threads:[~2016-01-07 11:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06  1:00 [PATCH net-next] net, sched: add clsact qdisc Daniel Borkmann
2016-01-06  2:40 ` Cong Wang
2016-01-07  3:53 ` Alexei Starovoitov
2016-01-07 10:09   ` Hannes Frederic Sowa
2016-01-07 11:58     ` Daniel Borkmann [this message]
2016-01-07 14:29       ` Jamal Hadi Salim
2016-01-07 14:42       ` Hannes Frederic Sowa
2016-01-07 15:16         ` Daniel Borkmann
2016-01-07 16:29 ` Eric Dumazet
2016-01-07 16:52   ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568E52E8.1010804@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=jhs@mojatatu.com \
    --cc=john.fastabend@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).