On 4/24/20 06:42, Kristof Provost wrote:
> On 22 Apr 2020, at 18:15, Xin Li wrote:
>> On 4/22/20 01:45, Kristof Provost wrote:
>>> On 22 Apr 2020, at 10:20, Xin Li wrote:
Hi,
On 4/14/20 02:51, Kristof Provost wrote:
> Hi,
>
> Thanks to support from The FreeBSD Foundation
On 22 Apr 2020, at 18:15, Xin Li wrote:
On 4/22/20 01:45, Kristof Provost wrote:
On 22 Apr 2020, at 10:20, Xin Li wrote:
Hi,
On 4/14/20 02:51, Kristof Provost wrote:
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to
work on
improving the throughput of if_bridge.
It change
Just using pf is enough to provoke this panic. I had the same back trace. This
patch from Kristof fixed it for me.
diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 373fa096d70..83c453090bb 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2529,7 +2529,6 @@ bridge_input(st
On 4/22/20 01:45, Kristof Provost wrote:
> On 22 Apr 2020, at 10:20, Xin Li wrote:
>> Hi,
>>
>> On 4/14/20 02:51, Kristof Provost wrote:
>>> Hi,
>>>
>>> Thanks to support from The FreeBSD Foundation I’ve been able to work on
>>> improving the throughput of if_bridge.
>>> It changes the (data path)
On 22 Apr 2020, at 10:20, Xin Li wrote:
Hi,
On 4/14/20 02:51, Kristof Provost wrote:
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to
work on
improving the throughput of if_bridge.
It changes the (data path) locking to use the NET_EPOCH
infrastructure.
Benchmarking shows
Hi,
On 4/14/20 02:51, Kristof Provost wrote:
> Hi,
>
> Thanks to support from The FreeBSD Foundation I’ve been able to work on
> improving the throughput of if_bridge.
> It changes the (data path) locking to use the NET_EPOCH infrastructure.
> Benchmarking shows substantial improvements (x5 in te
Hi,
Interesting, maybe ng_eiface + if_bridge is a good idea .
Simon
20200422
On 4/21/20 8:51 PM, Jan Bramkamp wrote:
On 16.04.20 08:34, Pavel Timofeev wrote:
вт, 14 апр. 2020 г., 12:51 Kristof Provost :
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to work
on improving
On 16.04.20 08:34, Pavel Timofeev wrote:
вт, 14 апр. 2020 г., 12:51 Kristof Provost :
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to work
on improving the throughput of if_bridge.
It changes the (data path) locking to use the NET_EPOCH infrastructure.
Benchmarking shows s
On 16 Apr 2020, at 8:34, Pavel Timofeev wrote:
Hi!
Thank you for your work!
Do you know if epair suffers from the same issue as tap?
I’ve not tested it, but I believe that epair scales significantly
better than tap.
It has a per-cpu mutex (or more accurately, a mutex in each of its
per-cpu str
вт, 14 апр. 2020 г., 12:51 Kristof Provost :
> Hi,
>
> Thanks to support from The FreeBSD Foundation I’ve been able to work
> on improving the throughput of if_bridge.
> It changes the (data path) locking to use the NET_EPOCH infrastructure.
> Benchmarking shows substantial improvements (x5 in tes
Hi,
Thanks to support from The FreeBSD Foundation I’ve been able to work
on improving the throughput of if_bridge.
It changes the (data path) locking to use the NET_EPOCH infrastructure.
Benchmarking shows substantial improvements (x5 in test setups).
This work is ready for wider testing now.
11 matches
Mail list logo