linux-kernel - Re: [PATCH 0/2] Traffic control cgroups subsystem

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]

Message-ID: <20080910221206.GI20815@postel.suug.ch>
Date:	Thu, 11 Sep 2008 00:12:06 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Ranjit Manomohan <ranjitm@...gle.com>
Cc:	David Miller <davem@...emloft.net>, kaber@...sh.net,
	akpm@...ux-foundation.org, lizf@...fujitsu.com, menage@...gle.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 0/2] Traffic control cgroups subsystem

* Ranjit Manomohan <ranjitm@...gle.com> 2008-09-10 13:44
> On Wed, Sep 10, 2008 at 1:22 PM, David Miller <davem@...emloft.net> wrote:
> >
> > I definitely prefer Thomas Graf's work, this stuff is very ugly
> > and way overengineered.
> >
> 
> Could you be more specific? Thomas' work is almost identical to this
> (except that he does not store the cgroup id into the socket which is
> a trivial change which has downsides which I have pointed out).
> 
> Additionally this approach has only minor modifications to the core
> networking stack. What portions do you consider ugly and over
> engineered and what alternative implementations would you prefer?
> Please see the follow up I have sent to Thomas' proposal about why we
> need this design approach to handle the inbound case.

WRT the inbound case, after some experiments I decided to dismiss the
ingress case at all and stick to something as simple as possible for
egress. The reason for this is that it is a very expensive operation
to associate a packet with a task on classifier level. Taking this
cost, it does not add up with the very limited capabilities of ingress
shaping. Ingress shaping is best effort at best. It works fairly well
with a very limited number of bulk data streams but usualy fails
miserably in common congestion situations where a cgroup classifier
would be useful.

> I'd be ok if you accepted either change since  we just want a standard
> kernel mechanism to do this.

Agreed. I think your approach is very reasonable but considering the
reasons I've given above and in the other thread I found it could be done
in a more simple and direct way.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/