All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Alexei Starovoitov <ast@plumgrid.com>,
	Cong Wang <cwang@twopensource.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	John Fastabend <john.r.fastabend@intel.com>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [RFC 2/3] tc: deprecate TC_ACT_QUEUED
Date: Thu, 23 Apr 2015 16:45:23 -0400	[thread overview]
Message-ID: <553959E3.9070209@mojatatu.com> (raw)
In-Reply-To: <55381F14.4070708@plumgrid.com>

On 04/22/15 18:22, Alexei Starovoitov wrote:
> On 4/21/15 10:02 PM, Cong Wang wrote:
>> On Tue, Apr 21, 2015 at 12:27 PM, Alexei Starovoitov
>> <ast@plumgrid.com> wrote:
>>> TC_ACT_QUEUED was always an alias of TC_ACT_STOLEN.
>>> Get rid of redundant checks in all qdiscs.
>>> Instead do it once.
>>
>> The current code can be easily extended, while your code not.
>> I don't see the need of this change.
>
> well, iproute2 doesn't use TC_ACT_QUEUED action at all and
> TC_ACT_STOLEN is used by mirred. All in-tree qdiscs alias them.
> If you're saying that some future actions together with
> some future qdiscs may take advantage of that, then why they didn't
> use it over the last 10 years?
> Having both that do the same thing is only confusing.
> I think having one value to indicate 'stolen' condition makes TC
> code easier to understand.
> Jamal, what's your take on this?


Sorry - I am on travel so not very helpful/responsive.
Several things:

1) the _XMIT semantics are useful on the egress side because in fact
we do have queues and they can be attached to qdiscs etc.
The TC_ACT_XXX codes were _intentional_ since ingress works as a
classifier shell. The fact that qdiscs dealt with these codes directly
allows for specialized handling. Moving them to a generic function
seems to defeat that purpose. So I am siding with Cong on this.
You probably have some other motivation for doing this which is not 
clear yet? Are you planning to queue things on ingress?

2) the ACT_QUEUED vs STOLEN was supposed to have semantics of something
that was stolen (eg redirection should definetely have been returning
STOLEN not QUEUED); something that queues for later re-injection
(with any/all metadata) was intended to use QUEUED. I believe netfilter
may have  followed suit and introduced similar codes (so it would be
interesting to see how they use them). In any case, it is clear it is
not being used - but i want to point the reason it was there
(which may still be useful; problem is TheLinuxWay is cutnpaste where
someone repeats the code that exists).

cheers,
jamal

  parent reply	other threads:[~2015-04-23 20:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 19:27 [RFC 0/3] tc cleanup? Alexei Starovoitov
2015-04-21 19:27 ` [RFC 1/3] tc: fix return values of ingress qdisc Alexei Starovoitov
2015-04-22  4:59   ` Cong Wang
2015-04-22 22:04     ` Alexei Starovoitov
2015-04-22 23:29       ` Cong Wang
2015-04-23  8:46         ` Thomas Graf
2015-04-21 19:27 ` [RFC 2/3] tc: deprecate TC_ACT_QUEUED Alexei Starovoitov
2015-04-22  5:02   ` Cong Wang
2015-04-22  7:43     ` Daniel Borkmann
2015-04-22 22:22     ` Alexei Starovoitov
2015-04-22 23:39       ` Cong Wang
2015-04-23  2:46         ` Alexei Starovoitov
2015-04-23  7:13           ` Daniel Borkmann
2015-04-23 18:12           ` Cong Wang
2015-04-23 18:21             ` Daniel Borkmann
2015-04-23 18:30               ` Cong Wang
2015-04-23 20:45       ` Jamal Hadi Salim [this message]
2015-04-23 21:20         ` Florian Westphal
2015-04-23 22:13         ` Alexei Starovoitov
2015-04-23 22:33           ` Cong Wang
2015-04-23 22:51           ` Jamal Hadi Salim
2015-04-24  0:59             ` Alexei Starovoitov
2015-04-24  3:37               ` Cong Wang
2015-04-24  8:12                 ` Daniel Borkmann
2015-04-27 12:31               ` Jamal Hadi Salim
2015-04-21 19:27 ` [RFC 3/3] tc: cleanup tc_classify Alexei Starovoitov
2015-04-22  5:05   ` Cong Wang
2015-04-22 22:27     ` Alexei Starovoitov
2015-04-22 23:38       ` Cong Wang
2015-04-23  8:49         ` Thomas Graf

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=553959E3.9070209@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=ast@plumgrid.com \
    --cc=cwang@twopensource.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=john.r.fastabend@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.