On Fri, Nov 13, 2009 at 2:28 PM, [email protected] < [email protected]> wrote:
> 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 <[email protected]> >> 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 thank you Max for the guidance. following your lead: inside squeue.c: 78 * 79 * Once created, squeues are never deleted. Hence squeue pointers are 80 * always valid. This means that functions outside the squeue can still 81 * refer safely to conn_sqp and their is no need for ref counts. 82 * if squeue are attached to a particular network card interface, and then the RJ45 wire is hotplugged removed, and the reattached to another RJ45 port, won't that create a problem - as all the threads queued are never requeued on the other interface? And this persistent existence of the squeue pointer could be a problem - in all possible manifestation (DoS, memory leak etc). > > > > 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 <[email protected]> >>> >>> >>> >> >> >> >> >> > > -- Regards, Peter Teoh
_______________________________________________ networking-discuss mailing list [email protected]
