RE: Some performance measurements on the FreeBSD network stack

From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time, if i remember well), but there was a large gain with multiple concurrent processes. Yes, that sounds about right when we did the tests a

RE: Some performance measurements on the FreeBSD network stack

Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=1592641 --Qing

RE: Some performance measurements on the FreeBSD network stack

I have a patch that has been sitting around for a long time due to review cycle latency that caches a pointer to the rtentry (and llentry) in the the inpcb. Before each use the rtentry is checked against a generation number in the routing tree that is incremented on every routing

RE: Kernel panic rtfree 2

Hi, Could you please let me know if the patch fixes your crash problem ? Thanks, --Qing -Original Message- From: Li, Qing Sent: Friday, August 12, 2011 6:29 PM To: Li, Qing; Luiz Otavio O Souza; Andrey Smagin Cc: freebsd-current@freebsd.org Subject: RE: Kernel panic rtfree 2

RE: Kernel panic rtfree 2

Hi, I think I know what the problem is. It is due to the RADIX_MPATH code. I hope to have a fix soon. --Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Luiz Otavio O Souza Sent: Friday, August 12, 2011 8:05

RE: Kernel panic rtfree 2

Hi, Please re-enable RADIX_MPATH option in your kernel config file, and try the following patch: http://people.freebsd.org/~qingli/radix_mpath.c.diff and let me know if it works out for you. I performed very limited testing. Thanks, --Qing

RE: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)

Hi, I've started my work with not point-to-point interfaces and I've found two problems. The first one - snip When I've done more investigation, it looks similar to http://svnweb.freebsd.org/base?view=revisionrevision=201543 So, I propose the following patch. I agree with

RE: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)

Hi, I've continued with work on two NIC on same NET. Now, with point-to-point interfaces too and I have more small fixes which I submitted today: http://www.freebsd.org/cgi/query-pr.cgi?pr=159600 The fix is not entirely correct. The rtinitflags() could set RTF_HOST flag when the

immediate panic in vm

The latest -current panics immediately on start-up. Running -current in VMware, I get: snip ... panic: mtx_init: mtx_lock not aligned for netir_mtx: 0x8114791c ... snip Has anyone else seen this? Any pointers ? Thanks, -- Qing ___

RE: immediate panic in vm

I saw the panic before r215212. --Qing -Original Message- From: Dimitry Andric [mailto:d...@freebsd.org] Sent: Wednesday, November 17, 2010 2:16 PM To: John Baldwin Cc: freebsd-current@FreeBSD.org; Li, Qing Subject: Re: immediate panic in vm On 2010-11-17 23:04, John Baldwin

RE: immediate panic in vm

Andric Cc: John Baldwin; Li, Qing; freebsd-current@freebsd.org Subject: Re: immediate panic in vm On Wed, Nov 17, 2010 at 11:15:40PM +0100, Dimitry Andric wrote: On 2010-11-17 23:04, John Baldwin wrote: On Wednesday, November 17, 2010 2:56:28 pm Li, Qing wrote: panic: mtx_init: mtx_lock

ECMP and route ownership

As I am revising the ECMP code and reviewing the work done by Ingo Flaschberger, I come to the conclusion that I need to make one more enhancement to ECMP. I want to implement the inetCidrRouteProto concept as the 2nd variable that differentiates among the ECMP routes. I have already started on

RE: Panic @r207844; current process: flowcleaner Fatal trap 12: page fault while inkernel mode

Hi David, I will take a look later this afternoon PST. Thanks, -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of David Wolfskill Sent: Monday, May 10, 2010 11:26 AM To: Ed Schouten Cc: curr...@freebsd.org

RE: Error 127.0.0.1: no route to host

Without the route.h patch, I can't ping 127.0.0.1 or the local or remote address of the OpenVPN tunnel (on tap0). In fact, you can't even build OpenVPN from ports as it'll fail its self-test. Please see my previous clarification email on the what and the why about the route.h.diff

RE: Error 127.0.0.1: no route to host

...@freebsd.org] On Behalf Of Michael Butler Sent: Wednesday, March 10, 2010 4:19 AM To: Doug Barton Cc: freebsd-current@freebsd.org Subject: Re: Error 127.0.0.1: no route to host -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/09/10 21:00, Doug Barton wrote: On 03/09/10 12:14, Li, Qing wrote

RE: Error 127.0.0.1: no route to host

comments are welcome. -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Li, Qing Sent: Tuesday, March 09, 2010 11:05 AM To: Renato Botelho; FreeBSD Current Subject: RE: Error 127.0.0.1: no route

RE: Error 127.0.0.1: no route to host

Thanks for the report, I am looking at it and will get back to you. -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Renato Botelho Sent: Tuesday, March 09, 2010 10:47 AM To: FreeBSD Current Subject: Error

RE: Error 127.0.0.1: no route to host

This error was caused by my commit r204902 from yesterday. Please try patch at http://people.freebsd.org/~qingli/route.h.diff -- Qing -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Li, Qing Sent: Tuesday