Alexander Motin wrote:
>I have uploaded that patch back. Not sure is it correct at this moment,
>there was some changes, but that time it worked fine.
Thanks a lot. I've installed the patch with some changes. I'm using the
7-STABLE (ng_base.c,v 1.135.2.10) at a production NAS. Corresponding patch
Alexander Motin wrote:
Hi.
Vladimir V. Kobal wrote:
I'm interested in the information of further development of Subject. I have
a bottleneck: swi_net limited by one CPU core time. There was a thread
http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html .
Patch http://people.free
Hi.
Vladimir V. Kobal wrote:
> I'm interested in the information of further development of Subject. I have
> a bottleneck: swi_net limited by one CPU core time. There was a thread
> http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html .
> Patch http://people.freebsd.org/~mav/netgr
Hello,
I'm interested in the information of further development of Subject. I have
a bottleneck: swi_net limited by one CPU core time. There was a thread
http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html .
Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not avail
On Sun, 30 Mar 2008, Alexander Motin wrote:
My initial leaning would be that we would like to avoid adding too many
more threads that will do per-packet work, as that leads to excessive
context switching.
Netgraph uses queueing only as last resort, when direct call is not possible
due to loc
Robert Watson wrote:
> FYI, you might be interested in some similar work I've been doing
> in the rwatson_netisr branch in Perforce, which:
> Adds per-CPU netisr threads
Thanks. Netgraph from the beginning uses concept of direct function
calls, when level of parallelism limited by data source. I
On Sun, 30 Mar 2008, Alexander Motin wrote:
I have implemented a patch (for the HEAD) making netgraph to use several own
threads for event queues processing instead of using single swinet. It
should significantly improve netgraph SMP scalability on complicated
workloads that require queueing b
Hi,
Have you thought about nodes that lock the same mutex must be run on the same
thread else for example one thread will run while another will just waits for
a mutex ?
You can achieve this by grouping nodes into a tree, and the node at the top of
the tree decides on which thread the nodes in
Hans Petter Selasky wrote:
Have you thought about nodes that lock the same mutex must be run on the same
thread else for example one thread will run while another will just waits for
a mutex ?
Usually different nodes does not share data, keeping them inside
node/hook private data, so I don't
Hi.
I have implemented a patch (for the HEAD) making netgraph to use several
own threads for event queues processing instead of using single swinet.
It should significantly improve netgraph SMP scalability on complicated
workloads that require queueing by implementation (PPTP/L2TP) or stack
s
10 matches
Mail list logo
