Re: Multiple netgraph threads

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. In that point multiple netisr threads will give benefits.

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 locking or stack limitations. For example, while working with kernel sockets (*upcall)() I have got many issues which make impossible to freely use received data without queueing as upcall() caller holds some locks leading to unpredicted LORs in socket/TCP/UDP code.
In case of such forced queueing, node becomes an independent data source which can be pinned to and processed by whatever specialized thread or netisr, when it will be able to do it more effectively.

--
Alexander Motin
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Multiple netgraph threads
    ... In that point multiple netisr threads will give benefits. ... while working with kernel sockets I have got many issues which make impossible to freely use received data without queueing as upcallcaller holds some locks leading to unpredicted LORs in socket/TCP/UDP code. ... In case of such forced queueing, node becomes an independent data source which can be pinned to and processed by whatever specialized thread or netisr, when it will be able to do it more effectively. ...
    (freebsd-net)
  • Re: Multiple netgraph threads
    ... In that point multiple netisr threads will give benefits. ... while working with kernel sockets I have got many issues which make impossible to freely use received data without queueing as upcallcaller holds some locks leading to unpredicted LORs in socket/TCP/UDP code. ... In case of such forced queueing, node becomes an independent data source which can be pinned to and processed by whatever specialized thread or netisr, when it will be able to do it more effectively. ...
    (freebsd-hackers)