Date: Thu, 1 Mar 2007 21:11:05 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Keith Arner" <vornum@gmail.com> Cc: freebsd-smp@freebsd.org Subject: Re: INP_INFO_WLOCK(&tcbinfo) bottleneck Message-ID: <3bbf2fe10703011211i6b0ad2b6gf75067ca17d0ac3b@mail.gmail.com> In-Reply-To: <8e552a500703010645x61d9b064w21c475ecc00a0e0e@mail.gmail.com> References: <8e552a500703010645x61d9b064w21c475ecc00a0e0e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/3/1, Keith Arner <vornum@gmail.com>: > I'm working on a project that needs high throughput, low latency TCP > traffic. > I'd like to be able to parallelize as much of the processing as possible, > across > several cores. > > I've done some early investigation in FreeBSD with direct dispatch enabled > (`sysctl net.isr.direct=1`). What I've discovered is that the system tends > to bottleneck with a lot of contention for INP_INFO_WLOCK(&tcbinfo). > Looking at the source code, it's apparent why this is; both tcp_input() > and tcp_usr_send() hold this mutex for the majority of their processing, > which effectively means that TCP input and output becomes single threaded. > (Though I see that this is relaxed in the output path in -CURRENT.) > > I see from Robert Watson's todo list (at http://wiki.freebsd.org/NetworkTodo > ) > that using a read/write lock over the pcb list is a work in progress. Are > there > any patches available that reflect whatever work has been done so far? Or > even any descriptions of what has been tried, and what the hard parts are? > > Keith Currently, the main problem for this is that somewhere (TM) there mutex gets recursed and recursion is not handled alredy for rwlocks, so kernel starts panicing. Patch for recursion in rwlock is not trivial, but there are ongoing discussions on it. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10703011211i6b0ad2b6gf75067ca17d0ac3b>