Re: CFT: if_bridge performance improvements

2020-04-24 Thread Xin Li
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

Re: CFT: if_bridge performance improvements

2020-04-24 Thread Kristof Provost
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

Re: CFT: if_bridge performance improvements

2020-04-22 Thread peter . blok
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 @@

Re: CFT: if_bridge performance improvements

2020-04-22 Thread Xin Li
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)

Re: CFT: if_bridge performance improvements

2020-04-22 Thread Kristof Provost
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

Re: CFT: if_bridge performance improvements

2020-04-22 Thread Xin Li
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

Re: CFT: if_bridge performance improvements

2020-04-21 Thread k simon
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

Re: CFT: if_bridge performance improvements

2020-04-21 Thread Jan Bramkamp
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

Re: CFT: if_bridge performance improvements

2020-04-16 Thread Kristof Provost
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

Re: CFT: if_bridge performance improvements

2020-04-16 Thread Pavel Timofeev
вт, 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

CFT: if_bridge performance improvements

2020-04-14 Thread 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 test setups). This work is ready for wider testing