netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Florian Westphal <fw@strlen.de>, netdev@vger.kernel.org
Cc: alexei.starovoitov@gmail.com, daniel@iogearbox.net
Subject: Re: [PATCH -next 0/3] tc state machinery cleanups
Date: Fri, 15 May 2015 07:36:40 -0400	[thread overview]
Message-ID: <5555DA48.6010208@mojatatu.com> (raw)
In-Reply-To: <1431679850-31896-1-git-send-email-fw@strlen.de>

Hi Florian,

On 05/15/15 04:50, Florian Westphal wrote:
> This series prepares removal of tc_verd member from sk_buff.
>
> It simplifies tc state machinery to what is required to keep current
> mirred/ifb combinations working.
>
> I tested a few scenarios, namely:
>
> 1 - htb based shaping on egress
> 2 - netem attached to ifb with mirred redirect from ingress qdisc
> 3 - mirred to different egress device
> 4 - mirred to ifb egress device with qdiscs set up on ifb
>      to provide illusion of 'single' transmit interface for traffic shaping
>
> After this series tc_verd is only used by ifb to skip actions on egress.
>
> Part #2 of this series will remove tc_verd completely.
>

The major goal here is to release some of the bits that are
no longer in use. I am for that but struggling with the unintended
consequence of changing readability or subtle meanings.
I brought this up last time when you removed the 1-bit macro.
Think of someone who read the code 6  months ago.
It would be useful to keep readability for the rest of the code the
way it was - change the definition of the macros.
This sounds doable because 8 contigous bits are going to be available.
Note: The macros are fugly - but there are better tools these days to
make them easier to read so de-uglifying could be part of the goal.
Therefore, I suggest the initial effort should be to find ways to
co-locate the bits and save the 8  bits and unless necessary keep
the code readability.

More on readability and subtle meanings:
A noun like "skb_tc_state" is not a good choice. Those two bits
carry location indicators and are intended to define source
and destination endpoints.

Also note: ifb and mirred are using the location metadata
bits - they are _not_ the owners of those bits or the only
potential users. Any of the blocks can consume or produce the metadatum
in order to aid policy traversal. You can use those two as examples
of existing blocks that do so - but annotating the code as such is
inaccurate.

cheers,
jamal

  parent reply	other threads:[~2015-05-15 11:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15  8:50 [PATCH -next 0/3] tc state machinery cleanups Florian Westphal
2015-05-15  8:50 ` [PATCH -next 1/3] net: sched: remove FROM INGRESS/EGRESS Florian Westphal
2015-05-15  8:50 ` [PATCH -next 2/3] net: sched: remove AT INGRESS/EGRESS Florian Westphal
2015-05-15 16:23   ` Alexei Starovoitov
2015-05-15 17:21     ` Florian Westphal
2015-05-15 20:09       ` Alexei Starovoitov
2015-05-15 22:22         ` Florian Westphal
2015-05-15 22:43         ` Jamal Hadi Salim
2015-05-15  8:50 ` [PATCH -next 3/3] net: core: use skb_tc_state to skip ingress classifiers Florian Westphal
2015-05-15 11:36 ` Jamal Hadi Salim [this message]
2015-05-15 11:59   ` [PATCH -next 0/3] tc state machinery cleanups Florian Westphal
2015-05-15 13:11   ` Daniel Borkmann
2015-05-18  3:34 ` David Miller

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=5555DA48.6010208@mojatatu.com \
    --to=jhs@mojatatu.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=fw@strlen.de \
    --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).