netdev - Re: [PATCH] skbuff: Add new tc classify variable

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]

Date:	Wed, 8 Feb 2012 09:54:49 +0100
From:	Florian Westphal <fw@...len.de>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Simon Wunderlich <simon.wunderlich@...03.tu-chemnitz.de>,
	netdev@...r.kernel.org
Subject: Re: [PATCH] skbuff: Add new tc classify variable

Stephen Hemminger <shemminger@...tta.com> 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@...03.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 is 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.
> 
> The problem then is not the use of marks but having to add a filter rule for
> each mark. We need something like u32 hash but for marks to build a table
> of mark -> class id.  The current method uses a linear list of filter rules,
> which is an obvious bottleneck with lots of classes.

Maybe.  But marks might already be used e.g. for policy routing or for
additional metadata (such as encoding higher level data).

And even if you do your 'mark identifies the traffic class' very late in
your iptables ruleset -- as soon as you've got tunnels configured,
the encapsulated packets end up travellign through the ruleset again
with a "classid mark" set -- which might interfere with the ruleset.

IOW, using -j CLASSIFY does have advantages regardless of the "tc mark filter"
performance issue Simon has.

There is also the SO_PRIORITY setsockopt which userspace might be using to pick a
particular traffic class...
--
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