Peter Teoh wrote: > On Fri, Nov 13, 2009 at 8:23 AM, James Carlson <[email protected]> > wrote: >> 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 as in "locking." It allows the data structures to be protected properly against multiple threads accessing the same data at the same time. There's also some queuing associated with it, but that's for commands issued against the squeue. It'd be better to search for and read the "FireEngine" documents. >> 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? All correct. > 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. Drivers are expected to be MT-hot. Those that aren't will have to arrange for their own protection. There's special code (due to "Crossbow" -- search google for documents) that handles the mapping of squeues to underlying hardware features, for those devices that have those sorts of special features. > 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? You're looking at mdb. That's a red herring. That's a user-space debugger, so there's no actual locking at all going on -- the user space program just reads out batches of kernel memory, and then tries to interpret it. If you're attached to a live system (rather than a system dump, which is really mdb's reason for being), then the structures may be in flux while they're being read. And you might get garbled results. Things are different inside the kernel itself, where correct results are crucial. > 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? You're looking in the wrong place to find synchronization. Look in the kernel code under usr/src/uts/common. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
