On Fri, Nov 13, 2009 at 2:38 PM, James Carlson <[email protected]>wrote:

> 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.
>
>
Erh!!! My error.....toally right, userspace can never touch kernel's locks,
but at the same time I learnt something from your statement - I always
thought that mdb -K running in console mode, is processing the "::dcmds"
commands in kernel mode.   Perhaps I am wrong....from your statements
"::netstat" must be running in kernel mode.   But sometimes command like
single stepping, are running in the kernel mode, but not the command
processing itself....:-).   Thank you for the lesson learnt.



> 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]>
>



-- 
Regards,
Peter Teoh
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to