netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,
	Patrick McHardy <kaber@trash.net>,
	Jamal Hadi Salim <hadi@cyberus.ca>,
	Johannes Berg <johannes@sipsolutions.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	Marek Lindner <lindner_marek@yahoo.de>,
	Sven Eckelmann <sven@narfation.org>,
	netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org,
	coreteam@netfilter.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] skbuff: Add new tc classify variable
Date: Tue, 7 Feb 2012 20:33:49 +0000	[thread overview]
Message-ID: <CAA93jw7NPVm_YUFdnM1aD6bzz5vbmuF3osaHS5xE+-xCutiAbw@mail.gmail.com> (raw)
In-Reply-To: <20120207201633.GB26533@pandem0nium>

On Tue, Feb 7, 2012 at 7:57 PM, Simon Wunderlich <
simon.wunderlich@s2003.tu-chemnitz.de> wrote:

> On Tue, Feb 07, 2012 at 11:05:22AM -0800, Stephen Hemminger wrote:
> > On Tue,  7 Feb 2012 19:39:08 +0100
> > Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> >
> > I don't understand why this is better, we already have mark to do this.
> > Your method saves adding a tc filter to map mark to classid, but that i=
s
> hardly
> > a huge burden.
>
> Unfortunately, it is. We have previously built our trees by setting marks
> with iptables
> and matching the masks with tc and the u32 matcher, but we got a rather
> big performance
> impact as soon as the number of users grow. The target platform are WiFi
> access points.
> By using the proposed patch, the performance stays nearly constant at a
> growing number
> of users.
>

To put things in more general terms, the overspecialized behavior and use
of magic numbers in the wireless stack

... from net/wireless/util.c/*

Given a data frame determine the 802.1p/1d tag to use. */
unsigned int cfg80211_classify8021d(struct sk_buff *skb)
{
        unsigned int dscp;

        /* skb->priority values from 256->263 are magic values to
         * directly indicate a specific 802.1d priority.  This is used
         * to allow 802.1d priority to be passed directly in from VLAN
         * tags, etc.
         */
        if (skb->priority >=3D 256 && skb->priority <=3D 263)
                return skb->priority - 256;

        switch (skb->protocol) {
        case htons(ETH_P_IP):
                dscp =3D ipv4_get_dsfield(ip_hdr(skb)) & 0xfc;
                break;
        case htons(ETH_P_IPV6):
                dscp =3D ipv6_get_dsfield(ipv6_hdr(skb)) & 0xfc;
                break;
        default:
                return 0;
        }

        return dscp >> 5;
}


and the related select queue function calling this
which maps the 4 hardware queues wireless has, onto 4 mq subqdiscs...

overrides most anything you might want to do with iptables doing
classification directly, especially if you want to put things
into different hw queues.

and furthermore makes using other qdiscs than mq, such as the htb rate
limiter, problematic, as well as sch_mq has no ability to put in a top
level filter, anyway because stuff ends up in the 1:1,1:2,1:3,1:4
automagically...

Reducing the namespace to 'marks' vs classes is ok for some uses, I guess,
but how to handle the hw queues and the select_queue problem?

And while I'm at the problems that wireless has, having one (or 4) queues
per actual end-point rather than 4 hardware queues would make it possible
to address the bufferbloat problem with wireless and sanely calculating
aggregation values....

My thought on that was to be tossing a station identifier into the cb, but
that seems to alsobe a cross layer violation.

I like the idea of separating "priority" from "classification" and from
"hw queues" but a unifying metaphor and space in the skb seems
to be THE problem.




--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

  reply	other threads:[~2012-02-07 20:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-07 18:39 [PATCH] skbuff: Add new tc classify variable Simon Wunderlich
2012-02-07 18:58 ` David Miller
2012-02-07 20:16   ` Simon Wunderlich
2012-02-07 20:33     ` Dave Taht [this message]
2012-02-08  9:21     ` Eric Dumazet
2012-02-08 14:48       ` jamal
2012-02-07 19:05 ` Stephen Hemminger
2012-02-07 19:57   ` Simon Wunderlich
2012-02-07 21:45     ` Stephen Hemminger
2012-02-08  8:54       ` Florian Westphal

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=CAA93jw7NPVm_YUFdnM1aD6bzz5vbmuF3osaHS5xE+-xCutiAbw@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=hadi@cyberus.ca \
    --cc=johannes@sipsolutions.net \
    --cc=kaber@trash.net \
    --cc=lindner_marek@yahoo.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=netfilter@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=simon.wunderlich@s2003.tu-chemnitz.de \
    --cc=sven@narfation.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).