https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189088
Mark Linimon changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #6 from Mark Linim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206932
Mark Linimon changed:
What|Removed |Added
Resolution|--- |Overcome By Events
Stat
On 8 Jul 2020, at 12:52, Kajetan Staszkiewicz wrote:
I have forgot to mention my system: it's FreeBSD 11.3-RELEASE-p9
I have also managed to replicate this (or a similar) issue on a test
system built with lock debugging and I got this:
Jul 8 10:32:07 hwlb-aw-01 kernel: lock order reversal:
Jul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #28 from Michael Tuexen ---
(In reply to Mark Johnston from comment #27)
OK, great. I think reducing the stack space worth the effort. It is not that
hard, will improve also the handling of pathological parameter configurations.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Mark Johnston changed:
What|Removed |Added
Resolution|Overcome By Events |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #26 from Michael Tuexen ---
(In reply to Mark Johnston from comment #25)
Increasing the stack size is a workaround. The plan was to rewrite the handling
such that only one buffer is needed. That is why I left the bug open. Since
On Thu, Jul 09, 2020 at 11:13:00AM -0400, Mark Johnston wrote:
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head. One
> caveat i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Resoluti
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Resoluti
On Fri, Jul 10, 2020 at 8:45 AM Patrick Lamaiziere
wrote:
> Hello,
>
> That is mostly for the record but it looks like the intel X520 is not
> very good and generates a high level of interrupts.
>
> On a router / firewall with 500 Kpps in input (dropped by pf) is enough to
> put the CPUs at
> 100
Hello
This interface is 14.8 Mpps, but such capacity is only possible
without a firewall performing filtering.
The more firewall rules on your router, the less forwarding capacity
the card will have, due to having to process the packet in CPU to
match the rules and then forward the packet.
In the
> On 10. Jul 2020, at 12:29, Doug Hardie wrote:
>
>> On 10 July 2020, at 02:39, Michael Tuexen wrote:
>>
>> Hi Eugene,
>>
>> you are completely right. However, it requires that the program needs to run
>> with root privileges just to be able to communicate.
>> In the context of userland stack,
> On 10 July 2020, at 02:39, Michael Tuexen wrote:
>
> Hi Eugene,
>
> you are completely right. However, it requires that the program needs to run
> with root privileges just to be able to communicate.
> In the context of userland stack, this is one of the most important issues.
> In case of SCT
> On 10. Jul 2020, at 02:06, Eugene Grosbein wrote:
>
> 10.07.2020 2:44, Doug Hardie wrote:
>
>>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>>
>>> Hi,
>>>
>>> I spent some time working on making it possible to load the SCTP stack
>>> as a kernel module, the same as we do today with IPSe
14 matches
Mail list logo
