[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 Rodney W. Grimes changed: What|Removed |Added CC||n...@freebsd.org -- You are re

[Bug 131876] [socket] FD leak by receiving SCM_RIGHTS by recvmsg with small control message buffer

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131876 Rodney W. Grimes changed: What|Removed |Added CC||n...@freebsd.org -- You are re

[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 Mark Johnston changed: What|Removed |Added Assignee|n...@freebsd.org |ma...@freebsd.org -- You are rec

[Bug 131876] [socket] FD leak by receiving SCM_RIGHTS by recvmsg with small control message buffer

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131876 Mark Johnston changed: What|Removed |Added Assignee|n...@freebsd.org |ma...@freebsd.org -- You are rec

[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 --- Comment #18 from Mark Johnston --- (In reply to Mark Johnston from comment #17) > since sosend_generic() already puts a hard bound on the size of control > messages, I don't see why it needs to go through the trouble of performing an

[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #17

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #29 from Vladimir --- (In reply to Eugene Grosbein from comment #28) No, just wanted to confirm. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #28 from Eugene Grosbein --- (In reply to Vladimir from comment #27) Yes. Have you missed comment #11 describing possible solutions including this? -- You are receiving this mail because: You are the assignee for the bug. ___

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #27 from Vladimir --- Do you mean something like net.isr.dispatch=deferred ? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mai

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #26 from Eugene Grosbein --- (In reply to ricsip from comment #24) Please use our mailing lists or web forums for general support questions of discussion and leave Bugzilla for bug reports. Again, the problem has nothing to do

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #25 from Jan Bramkamp --- Does Linux use RSS to achieve this performance or does it drain the NIC queue in a single interrupt and load balance the rest? Did you try the netisr workaround? -- You are receiving this mail because

[Bug 203856] [igb] PPPoE RX traffic is limitied to one queue

2018-07-25 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856 --- Comment #24 from ricsip --- (In reply to Eugene Grosbein from comment #23) Hi Eugene, as I was not satisfied with the outcome here, I installed an ipfire linux distrib on my APU2 to see what performance it can achieve versus the low p