netdev - Re: [RFC PATCH v3] cgroup: net_cls: traffic counter based on classification control cgroup

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] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2013 15:50:30 +0400
From:	Alexey Perevalov <a.perevalov@...sung.com>
To:	Daniel Wagner <wagi@...om.org>
Cc:	cgroups@...r.kernel.org, Glauber Costa <glommer@...allels.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH v3] cgroup: net_cls: traffic counter based on
 classification control cgroup

Hello all,

also I got local benchmark result for 100 test.

It looks more trully


     *Local*    Communication    latencies    in    microseconds 
smaller    is    better

   2p/0K ctxsw     Pipe        AF Unix      UDP      RPC/UDP TCP    
RPC/TCP TCP conn
Kernel    without patch    Average values:        3.2809 9.12381    
8.2354    16.327    18.825    24.274    22.759 30.64
Kernel    with patch    Average values:             3.4718 9.61495    
8.5778    19.442    19.807    31.835    23.824 30.85

     *Local*    Communication    bandwidths    in    MB/s bigger    
is    better
Pipe          AF Unix    TCP          File reread    Mmap reread         
Bcopy (libc)    Bcopy (hand)    Mem read    Mem write
Kernel    without patch    Average values:        2119.25 6853.49    
3499.27      4421.796    7543.785             6176.899     3483.647     
      5603.29       6541.38
Kernel    with patch    Average values:             1966.7 6825.42    
3413.67      4426.936    7534.443 6170.924      3481.583          
5602.75       6520.42

Performance degradation exists. But I thing it can be solved, for 
example, by adding incrementation and searching appropriate cgroup to 
delayed timer (add_timer).


On 01/14/2013 12:09 PM, Daniel Wagner wrote:
> Hi Alexey,
>
> On 11.01.2013 17:59, Alexey Perevalov wrote:
>> I'm sorry for previous email with attachments.
>
> It seems something went wrong with the patch, e.g. indention is wrong 
> and also I see '^M$' line endings. I assume you are sending your 
> patches through an exchange server which is likely not to work.
>
>> I would like to represent next version of patch I sent before
>> cgroup: "net_cls: traffic counter based on classification control 
>> cgroup"
>>
>> The main idea is the same as was. It keeping counter in control groups,
>> but now uses atomic instead resource_counters.
>
> +#if IS_ENABLED(CONFIG_NET_CLS_COUNTER)
> + if (copied > 0)
> + count_cls_rcv(current, copied, ifindex);
> +#endif
> +
> release_sock(sk);
> return copied;
>
> Normally, distros will enable most config flags. Maybe you could use
> a jump label to reduce the cost for the users which have 
> CONFIG_NET_CLS_COUNTER enabled and do not use it?
>
>> I have a performance measurement for this patch. It was done by lmbench
>> on physical machine.
>> Results are not so representative for 20 tests and some numbers are real
>> weird.
>
> Could you explain in the commit message how your patch is designed? I 
> see you are using a RB tree. What's the purpose of it?
>
>> Daniel Wagner wrote what he is doing something similar, but using
>> namespaces.
>
> I am trying a different approach on this problem using iptables. I am 
> playing around with a few patches which allow to install a iptables rule
> which matches on the security context, e.g.
>
> iptables -t mangle -A OUTPUT -m secmark --secctx \
> unconfined_u:unconfined_r:foo_t:s0-s0:c0.c1023 -j MARK --set-mark 1
>
> So far it looks promising, but as I me previous networking experience 
> is, that something will not work eventually.
>
>> Proposed by me approach is used in upcoming Tizen release, but little
>> bit different version.
>
> Thanks,
> Daniel
>
> -- 
> 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
>


-- 
Best regards,
Alexey Perevalov,
Technical Leader,
phone: +7 (495) 797 25 00 ext 3969
e-mail: a.perevalov@...sung.com <mailto:a.perevalov@...sumng.com>

Mobile group, Moscow Samsung Research Center
12 Dvintsev street, building 1
127018, Moscow, Russian Federation
--
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