freebsd with flexible iflib nic queues
e7e5f78e7b
The taskq_t's active thread list is sorted based on its tqt_ent->tqent_id field. The list is kept sorted solely by inserting new taskq_thread_t's in their correct sorted location; no other means is used. This means that once inserted, if a taskq_thread_t's tqt_ent->tqent_id field changes, the list runs the risk of no longer being sorted. Prior to the introduction of the taskq_dispatch_prealloc() interface, this was not a problem as a taskq_ent_t actively being serviced under the old interface should always have a static tqent_id field. Thus, once the taskq_thread_t is added to the taskq_t's active thread list, the taskq_thread_t's tqt_ent->tqent_id field would remain constant. Now, this is no longer the case. Currently, if using the taskq_dispatch_prealloc() interface, any given taskq_ent_t actively being serviced _may_ have its tqent_id value incremented. This happens when the preallocated taskq_ent_t structure is recursively dispatched. Thus, a taskq_thread_t could potentially have its tqt_ent->tqent_id field silently modified from under its feet. If this were to happen to a taskq_thread_t on a taskq_t's active thread list, this would compromise the integrity of the order of the list (as the list _may_ no longer be sorted). To get around this, the taskq_thread_t's taskq_ent_t pointer was replaced with its own static copy of the tqent_id. So, as a taskq_ent_t is pulled off of the taskq_t's pending list, a static copy of its tqent_id is made and this copy is used to sort the active thread list. Using a static copy is key in ensuring the integrity of the order of the active thread list. Even if the underlying taskq_ent_t is recursively dispatched (as has its tqent_id modified), this static copy stored inside the taskq_thread_t will remain constant. Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #71 |
||
|---|---|---|
| cmd | ||
| config | ||
| include | ||
| lib | ||
| module | ||
| patches | ||
| scripts | ||
| .gitignore | ||
| AUTHORS | ||
| autogen.sh | ||
| ChangeLog | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| DISCLAIMER | ||
| INSTALL | ||
| Makefile.am | ||
| Makefile.in | ||
| META | ||
| PKGBUILD-spl-modules.in | ||
| PKGBUILD-spl.in | ||
| README.markdown | ||
| spl_config.h.in | ||
| spl-modules.spec.in | ||
| spl.spec.in | ||
The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. This can be particularly useful when you want to track upstream Solaris development closely and don’t want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives.
To build packages for your distribution:
$ ./configure
$ make pkg
Full documentation for building, configuring, and using the SPL can be found at: http://zfsonlinux.org