|
Liu Yongfeng
|
Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Liu Yongfeng
02/26/2020 11:09 AM
post120270
|
Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Altera Cyclone V SoC, dual core, Cortex-A9 architecture, QNX 6.5.0SP1, the network driver snpsmac3504 supports two
interfaces on the SoC, named wm0 and wm1. io-pkt is started with "io-pkt-v4 -ptcpip -d snpsmac3504 name=wm". We can see
three threads, "io-pkt main" ,"io-pkt #0x00" and "io-pkt #0x01".
When we send flood packets to wm0, with little traffic on wm1, "io-pkt #00" consumes nearly 100% CPU time of one CPU
core, and "io-pkt #01" is ALWAYS IDLE, whenever there is flood traffic on wm0 or not.
When we send flood packets to wm1, with little traffic on wm0, both "io-pkt #00" and "io-pkt #01" consumes nearly 100%
CPU time of two CPU cores, which is as expected, because we use short valid packets at a ultra high speed.
There are applications in the system which send and receive packets from wm0/wm1 in non-blocking mode. For flood on wm0,
we can find so many socket calls blocked for more than hundreds of milliseconds hand shaking with "io-pkt #00". But for
flood on wm1, no blocking found for socket calls, sometimes "io-pkt #00" service the socket call, sometimes "io-pkt #01
" services the socket call, which is perfect as expected for a multi-core system.
But how to explain the single-thread behaviour for wm0?
Thanks and regards
|
|
|
|
|
|
Nick Reilly
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Nick Reilly
02/26/2020 12:46 PM
post120271
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
io-pkt does most of its processing in "Stack Context", this is all the protocol handling plus the resource manager. In
addition it does "Interrupt Worker" processing, this is usually the driver receive processing where it manages the Rx
descriptor ring and then sends the packet to the actual protocol handling code - once the EtherType is processed the
packet is put on the appropriate protocol queue for the "Stack Context" to handle.
In your case, "Stack Context" processing is happening on "io-pkt #0x00", wm0 Rx "Interrupt Worker" processing is also
happening on "io-pkt #0x00" and wm1 "Interrupt Worker" processing is happening on "io-pkt #0x01".
Unfortunately you are running 6.5.0, in later versions we have recently added an option to io-pkt to address your
scenario:
-D - Run the resource manager/protocol layer stack context in
a dedicated posix thread. By default this is off. This
option can offer a performance improvement if you are
sending and receiving TCP/IP traffic from applications on
a multi-core system.
This was added to 6.6.0 and later with Issue ID 2599867
I suggest you contact your QNX support representative to see if you can move to 6.6.0 or later, or to see if you can get
this issue added to 6.5.0
|
|
|
|
|
|
Liu Yongfeng
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Liu Yongfeng
02/27/2020 2:58 AM
post120273
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Hello Reilly,
Thank you very much for your prompt reply.
I have to correct my statement on the testing steps in my initial post, that is, before we did flood test on one
interface, we pulled out cable of the other.
I investigated the tracelog carefully, and now I can confirm that, for wm1, both "io-pkt#00" and "io-pkt#01" can freely
switch between "stack context" processing thread and "Interrupt worker" thread, since we only have two worker threads,
there is only one "interrupt worker" thread at any time, but both threads are possible to be the one and only "interrupt
worker" thread, just as the document says.
But for wm0, "io-pkt#00" is always the "interrupt worker" thread and "stack context" thread, and "io-pkt#01" does
NOTHING, it is always in idle state even when application socket call is blocked waiting for a io-pkt thread to service.
So, does the design of io-pkt in 6.5.0SP1 might cause this situation to happen ?
Thanks and regards
|
|
|
|
|
|
Nick Reilly
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Nick Reilly
02/27/2020 8:54 AM
post120274
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Yes, this is the design of io-pkt in 6.5.0. We have improved it in later versions.
|
|
|
|
|
|
Liu Yongfeng
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Liu Yongfeng
02/27/2020 10:44 AM
post120278
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Thank you again for your response. This helps a lot.
|
|
|
|
|
|
Liu Yongfeng
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Liu Yongfeng
03/03/2020 9:55 AM
post120290
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Hello Reilly,
I upgraded my system to 6.6.0, but I can't find the "-D" option for io-pkt. So, is the improvement you mentioned not
published ? How can I get it?
|
|
|
|
|
|
Nick Reilly
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Nick Reilly
03/03/2020 10:26 AM
post120291
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
It was added to io-pkt after 6.6.0 was released. Please contact your QNX support and ask them for the patch containing
the fix for Issue ID 2599867
|
|
|
|
|
|
Liu Yongfeng
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
|
|
Liu Yongfeng
03/03/2020 10:28 AM
post120292
|
Re: Why io-pkt acts single-threaded on one interface, but multi-threaded on the other interface?
Thanks for your prompt response.
|
|
|
|
|
|
