> Any actual processing of the packet in the same thread significantly hurt the rate > offload the actual packet processing to a different goroutine
As Rajanikanth points out, you'll need to put your work in other goroutines to make use of your other cores for processing them. One goroutine per packet is likely going to cause its own issues. I'd suggest adding a configurable batch size to let you iterate and find the ideal number packets to spin off for processing in a goroutine. Maybe experiment with a few different patterns. For example you might start with a naive goroutine creation on each batch of a significant size ( https://play.golang.org/p/GH16HEJgiy) or implement something like a worker pool model where you send segments of work to available workers ( https://play.golang.org/p/3D_JuWdA4a). Also, given that you attempting to provide as much active time to the packet collector as possible it might be worthwhile to investigate usage of https://golang.org/pkg/runtime/#LockOSThread which allows you to isolate your consumer goroutine to an OS thread and force all other goroutines to operate in other OS threads. On Sat, May 27, 2017 at 9:15 AM Rajanikanth Jammalamadaka < rajanika...@gmail.com> wrote: > Can you offload the actual packet processing to a different goroutine? > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
