Peter Teoh wrote:
sorry to ask some question again, and I am really appreciative of any
answers however briefly given. i also must apologized for asking
these questions with minimal searching and googling....it is
non-trivial to search when u don't know all the keywords....but a
oneliner answer to help start the process is much appreciated.
On Fri, Nov 13, 2009 at 8:23 AM, James Carlson <carls...@workingcode.com> wrote:
Peter Teoh wrote:
Can someone help me understand this?
a. what is the difference between squeue and netstack?
A netstack instance is allocated for the global zone (and all shared
stack zones), plus one for each exclusive IP stack instance zone.
When IP stack instances were added, the formerly static storage duration
variables related to networking were moved into the netstack structure.
(A few were left as system-wide globals, but most moved.)
That's what allows an exclusive IP stack instance zone to have its own
set of IP interfaces.
The squeue is a synchronization object used by FireEngine. There's
roughly an squeue per CPU and interface on the system.
synchronization in what sense? FIFO sense? ie, a kind of FIFO
queue, where packets are stacked and dequeue in the same order it is
stacked?
Synchronization in the sense of a serialization mechanism. Basically, a
thread "enters"
an squeue. While in the squeue, other threads trying to enter
the queue end up enqueuing their messages. The thread that is
already in the squeue may (or may not) drain the messages before
leaving. You really need to read the paper on fireengine
at
http://hub.opensolaris.org/bin/download/Community+Group+networking/WebHome/fewppublic.pdf.
Also, there is a long comment at the beginning of
usr/src/uts/common/inet/squeue.c
explaining their operation.
max
An squeue belongs to exactly one netstack. A netstack may have one or
many squeues.
since synchronization is per squeue, therefore there exists an
"squeue" lock for each squeue, correct? and since different squeue
have their individual lock, it is possible to have concurrent
transmission by different squeue at the same time? i suspect no?
because if yes, the squeue should be per-interface, or per-hardware
network card queue. For those network card with multiqueue, then we
can have squeue number to equal the number of queues in the multiqueue
NIC.
it also puzzle me how this sync-lock is used for. for example, in:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/mdb/common/modules/genunix/net.c#1082
Look at all the netstat_xxxxx functions. this is where mdb implement
its "::netstat" dcmds, and as it enumerate through the different
connection, there is absolutely no locking acquired....is it possible
that while reading and printing the information (inside mdb's netstat)
the connection gets deleted/dropped, or "dissociated" as mentioned
earlier, and continuing access it to print other fields will result in
memory corruption?
there is also no reference to squeue primitives in the net.c program
(above URL). so as netstat enumerate through all the connection
(each connection means conn_t primitives), these connection may come
from different squeue, correct?
generally,
what is the implication if it is disassociated - can we still pump
information through the connection? (sorry for talking rubbish.....i
am really newbie...)
No more data is possible. The user is long gone. We're in clean-up
mode -- the connection will eventually be freed up.
Disassociating from the netstack means that we no longer need to refer
to the zone that created the connection.
b. squeue is per-cpu right? so different cpu will have difference
squeue?
Yes.
so i supposed there must be a handler function for the
squeue processing?
what is the name, and they are different for reading/writing right?
You'll need to read through the ip_squeue source code, and any
FireEngine documents you can google. It's non-trivial.
if they are per-cpu, is there load balancing to rebalance the queue
when it become imbalanced due to different speed of processing?
No.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
