From: Glauber Costa <glommer@parallels.com>
To: Alexey Perevalov <a.perevalov@samsung.com>
Cc: netdev@vger.kernel.org, cgroups@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Daniel Wagner <wagi@monom.org>
Subject: Re: [net-next RFC v2] net_cls: traffic counter based on classification control cgroup
Date: Tue, 27 Nov 2012 15:03:06 +0400 [thread overview]
Message-ID: <50B49DEA.7010000@parallels.com> (raw)
In-Reply-To: <50B49C6C.8030604@samsung.com>
On 11/27/2012 02:56 PM, Alexey Perevalov wrote:
> Hello.
>
> It's second version of patch I already sent to netdev.
>
> The main goal of this patch it's counting traffic for process placed to
> net_cls cgroup (ingress and egress).
> It's based on res_counters and holds counter per network interfaces.
>
> Description of patch.
> It handles packets in net/core/dev.c for egress and in
> /net/ipv4/tcp.c|udp.c for ingress.
> These places were chosen because we need to know also network interface.
>
> Cgroup fs interface provides following files additional to existing
> net_cls files:
> net_cls.ifacename.usage_in_bytes
> Containing rcv/snd lines.
> Also this patch adds to net_cls ability to handle a network device
> registration.
>
> It could be included or excluded in compile time.
> I moved the menu entry for "Control group classifier" from network/QoS to
> General Option/Control Group.
>
> I'm waiting for you comments.
>
Daniel Wagner is working on something a lot similar.
Maybe you should be in contact, in case you are not yet.
A few general comments:
1) res_counters are incredibly expensive. If you are more interested in
counting than you are in limiting, they may not be your best choice.
2) When Daniel exposed his use case to me, it gave me the impression
that "counting traffic" is something that is totally doable by having a
dedicated interface in a separate namespace. Basically, we already count
traffic (rx and tx) for all interfaces anyway, so it suggests that it
could be an interesting way to see the problem.
AFAIK, Daniel is still measuring this. But it would be great to know if
that could work for your use case as well.
Thanks.
next prev parent reply other threads:[~2012-11-27 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 10:56 [net-next RFC v2] net_cls: traffic counter based on classification control cgroup Alexey Perevalov
2012-11-27 11:03 ` Glauber Costa [this message]
[not found] ` <50B49DEA.7010000-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-27 13:02 ` Daniel Wagner
[not found] ` <50B4B9E2.4030200-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2012-11-28 5:21 ` Alexey Perevalov
[not found] ` <50B59F54.8080401-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-11-28 8:09 ` Daniel Wagner
[not found] ` <50B5C6AB.6040208-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2012-11-28 11:18 ` Alexey Perevalov
[not found] ` <50B5F2EE.6050204-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-11-29 14:36 ` Daniel Wagner
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=50B49DEA.7010000@parallels.com \
--to=glommer@parallels.com \
--cc=a.perevalov@samsung.com \
--cc=cgroups@vger.kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=netdev@vger.kernel.org \
--cc=wagi@monom.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).