Re: [net-next RFC v2] net_cls: traffic counter based on classification control cgroup

[Daniel Wagner <wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>]

Hi Alexey

On 28.11.2012 12:18, Alexey Perevalov wrote:
> On 11/28/2012 12:09 PM, Daniel  Wagner wrote:
>>>>> 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.
>>>> Moving applications into separate net namespaces is for sure a valid
>>>> solution.
>>>> Though there is a one drawback in this approach. The namespaces need
>>>> to be
>>>> attached to a bridge and then some NATting. That means every
>>>> application
>>>> would get it's own IP address. This might be okay for your certain use
>>>> cases but I am still trying to work around this. Glauber and I had some
>>>> discussion about this and he suggested to allow the physical networking
>>>> device to be attached to several namespaces (e.g. via macvlan). Every
>>>> namespace would get the same IP address. Unfortunately, this would
>>>> result in
>>>> the same mess as several physical devices on a network get the same
>>>> IP address assigned.
>>> Is I truly understand what to make statistics works we need to put
>>> process to separate namespace?
>> If a process lives in its own network namespace then you can
>> count the packets/bytes on the network interface level. The side effect
>> is that is that each namespace is obviously a new network and has to be
>> treated as such.
>>
>>> Approach to keep counter in cgroup hasn't such side effects, but it has
>>> another ).
>> cgroups are not for free. Currently a lot of effort is put into getting
>> a reasonable performance and behavior into cgroups. In this situation
>> any new feature added to cgroups will need a pretty good justification
>> why it is needed and why it cant be done with existing infrastructure.
> I want to figure out in yours proposed design:
>
>     +------------------------------------------------+
>     |network namespace1: pid1, pid2,...              |
>     |                                                |
> +---------------------------+
>     |   network stack,          network iface        |
> |                           |
>     |       nf hooks                                 +------->| physical
> network          |
>     +------------------------------------------------+        |
> interface            |
> |                           |
> |                           |
>     +------------------------------------------------+
> |                           |
>     |network namespace2: pid1, pid2,...              |
> |                           |
>     | +------->|                           |
>     |   network stack,          network iface        |
> |                           |
>     |       nf hooks                                 |
> |                           |
>     +------------------------------------------------+
> |                           |
> +---------------------------+
>     ...                                                          ^
>     +------------------------------------------------+           |
>     |network namespace3: pid1, pid2,...              |           |
>     |                                                |           |
>     |   network stack,          network iface        +-----------+
>     |       nf hooks                                 |
>     +------------------------------------------------+
>
>
> Question, in case of one physical networking device connected to several
> namespaces,

Currently, a physical device can only live in one namespace. The idea 
was to see if that 'limitation' could be removed, e.g. by modifying macvlan.

> is it allow to tweak network packet scheduler (qdisc instance) using
> traffic control tool for one physical network interface?
> The same question is about netfilter hooks. I have seen the code, it
> seems to me nf hooks is registering per network stack now.

As I said this was just and idea and maybe it is not possible.

> CGroup framework has an notification mechanism based on eventfd. For
> example I can just send notification to user space about network activity.
> Is there such mechanism in standard infrastructure to notify user space
> apps on activity on monitored application (maybe nf_queue)?

My current plan is to use IDLETIMER for this stuff.

cheers,
daniel