netdev - Re: multi bpf filter will impact performance?

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

Date:	Wed, 1 Dec 2010 11:48:46 +0800
From:	Rui <wirelesser@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: multi bpf filter will impact performance?

On Tue, Nov 30, 2010 at 10:34 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le mardi 30 novembre 2010 à 22:21 +0800, Rui a écrit :
>
>> does it mean each incoming packet will issue a softirq?
>
> Hmm, if your machine is loaded, one cpu is probably looping inside
> ksoftirqd. You can probably check with "top" command.
>
>> possible to know the corresponding sock,then to run only one filter?
>>
>
> We could add a SKF_AD_CPU filter, thats a couple of lines ;)
>
> tcpdump   .... "cpu 0 and udp ..."
>
>> >
>> >> Q2. performance is bad? any idea to improve it?
>> >>
>> >
>> > multiqueue card : split each IRQ on a separate cpu.
>> >
>> > If not multiqueue card : use RPS on a recent kernel to split the load on
>> > several cpus.
>> >
>> > Use a filter against the queue, instead of doing a hash code yourself in
>> > the bpf. (code added in commit d19742fb (linux-2.6.33)
>> >
>> > (you need to tweak libpcap to use SKF_AD_QUEUE instruction)
>> >
>> > commit d19742fb1c68e6db83b76e06dea5a374c99e104f
>> > Author: Eric Dumazet <eric.dumazet@...il.com>
>> > Date:   Tue Oct 20 01:06:22 2009 -0700
>> >
>> >    filter: Add SKF_AD_QUEUE instruction
>> >
>> >    It can help being able to filter packets on their queue_mapping.
>> >
>> >    If filter performance is not good, we could add a "numqueue" field
>> >    in struct packet_type, so that netif_nit_deliver() and other functions
>> >    can directly ignore packets with not expected queue number.
>> >
>> >    Lets experiment this simple filter extension first.
>> >
>> >
>> >
>> >
>> >
>> >
>> yes, I will try SKF_AD_QUEUE  with kernel 2.6.33.
>>
>> and I am testing the performance when traffic falls at the same
>> rx-queue (same src ip and dst ip traffic),
>> in this situation,I need to find another way to hash the traffic.
>
> Hmm, in this case, all trafic is handled by one cpu in ksoftirqd.
> and RPS wont be able to help you, since the skb hash will be the same
> for all packets.
>
> It would need a change in __skb_get_rxhash() to compute rxhash with the
> hash you use  (if udp dest port is 2152, then use ether[66-73] or
> ether[62-69] as the jhash parameter, while we currently only use udp
> addr/port information to compute the rxhash)
>
> Then, you could use RPS to spread the load into 4 separate cpus.
>
>
>
>
one more question is

if  RPS can spread the load into 4 separate cpus, how about the
"packet_rcv(or tpacket_rcv)" ? will they run in parallel?

as I use 'tcpdump(PACKET_MMAP)' to copy the packet to user space, I
expect there are simultaneous packet_rcv running in each CPU to put
the packet into ringbuffer.

thank you
rui
--
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