From: "Krzysztof Olędzki" <ole@ans.pl>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Michael Chan <mchan@broadcom.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: bnx2/BCM5709: why 5 interrupts on a 4 core system (2.6.33.3)
Date: Tue, 18 May 2010 16:22:00 +0200 [thread overview]
Message-ID: <4BF2A288.7040304@ans.pl> (raw)
In-Reply-To: <1274045180.2299.38.camel@edumazet-laptop>
On 2010-05-16 23:26, Eric Dumazet wrote:
<CUT>
>> My normal workload is TCP and UDP based so if it is only ICMP then there
>> is no problem. Actually I have noticeably more UDP traffic than an
>> average network, mainly because of LWAPP/CAPWAP, so I'm interested in
>> good performance for both TCP and UDP.
>>
>> During my initial tests ICMP ping showed the same behavior like UDP/TCP
>> with iperf, so I sticked with it. I'll redo everyting with UDP and TCP
>> of course. :)
>>
>>>> BTW: With a normal router workload, should I expect big performance drop
>>>> when receiving and forwarding the same packet using different CPUs?
>>>> Bonding provides very important functionality, I'm not able to drop it. :(
>>>>
>>>
>>> Not sure what you mean by forwarding same packet using different CPUs.
>>> You probably meant different queues, because in normal case, only one
>>> cpu is involved (the one receiving the packet is also the one
>>> transmitting it, unless you have congestion or trafic shaping)
>>
>> I mean to receive it on a one CPU and to send it on a different one. I
>> would like to assing different vectors (eth1-0 .. eth1-4) to different
>> CPUs, but with bnx2x+bonding packets are received on queues 1-4 (eth1-1
>> .. eth1-4) and sent from queue 0 (eth1-0). So, for a one packet, two
>> different CPUs will be involved (RX on q1-q4, TX on q0).
>
> As I said, (unless you use RPS), one forwarded packet only uses one CPU.
> How tx queue is selected is another story. We try to do a 1-1 mapping.
OK, but with multi-queue NIC, I can assign each queue to a different
CPU. So, while forwarding packets from a flow, I would like to assign
the same queue on both input and output.
>>> If you have 4 cpus, you can use following patch and have a transparent
>>> bonding against multiqueue.
>>
>> Thanks! If I get it right: with the patch, packets should be sent using
>> the same CPU (queue?) that was used when receiving?
>
> Yes, for forwarding loads.
>
> (You might use 5 or 8 instead of 4, because its not clear to me if bnx2
> has 5 txqueues or 4 in your case)
Thank you. What happens if I set it to a lower/bigger value, than
avaliable txqueues in a NIC?
Best regards,
Krzysztof Olędzki
next prev parent reply other threads:[~2010-05-18 14:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-16 13:33 bnx2/BCM5709: why 5 interrupts on a 4 core system (2.6.33.3) Krzysztof Oledzki
2010-05-16 18:51 ` Michael Chan
2010-05-16 19:24 ` Krzysztof Olędzki
2010-05-16 19:49 ` Krzysztof Olędzki
2010-05-16 20:00 ` Michael Chan
2010-05-16 20:15 ` Eric Dumazet
2010-05-16 20:24 ` Michael Chan
2010-05-16 20:34 ` Krzysztof Olędzki
2010-05-16 20:47 ` Eric Dumazet
2010-05-16 21:06 ` George B.
2010-05-16 21:12 ` Krzysztof Olędzki
2010-05-16 21:26 ` Eric Dumazet
2010-05-18 14:22 ` Krzysztof Olędzki [this message]
2010-05-18 14:26 ` Eric Dumazet
2010-05-18 14:55 ` Krzysztof Olędzki
2010-05-18 15:35 ` Krzysztof Olędzki
2010-05-18 2:11 ` Michael Chan
2010-05-18 16:28 ` Krzysztof Olędzki
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=4BF2A288.7040304@ans.pl \
--to=ole@ans.pl \
--cc=eric.dumazet@gmail.com \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.