On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote:
> I have been running some performance tests on UDP sockets,
> using the netsend program in tools/tools/netrate/netsend
> and instrumenting the source code and the kernel do return in
> various points of the path. Here are some results wh
On 25. Apr 2012, at 15:45 , K. Macy wrote:
> a) Where is the possible leak in the legacy path?
It's been somewhere in ip_output() in one of the possible combinations
go through the code flow. I'd probably need to apply a patch to a tree
to get there again. It's been more than 6 months for me as
> Because there were leaks, there were 100% panics for IPv6, ... at least on
> the version I had seen in autumn last year.
>
> There is certainly no one more interested then me on these in, esp. for v6
> where the removal of route caching a long time ago made nd6_nud_hint() a NOP
> with dst and rt
On Wed, Apr 25, 2012 at 01:22:06PM +0400, Maxim Konovalov wrote:
> Hi,
>
> On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote:
>
> > 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 ou
Hi,
On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote:
> 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
On 24. Apr 2012, at 17:42 , Li, Qing wrote:
>>>
>>> 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 r
> >
> > 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
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
> >
> >
>>
>
> 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 t
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo wrote:
> On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
>> >
>> >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 remem
On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
> >
> >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 conc
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote:
> On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote:
>>>
>> >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),
>>>b
On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote:
>>
> >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 proce
>
>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 te
On Tue, Apr 24, 2012 at 03:16:48PM +0200, Andre Oppermann wrote:
> On 19.04.2012 22:46, Luigi Rizzo wrote:
> >On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
> >>On 19.04.2012 15:30, Luigi Rizzo wrote:
> >>>I have been running some performance tests on UDP sockets,
> >>>using the n
On 19.04.2012 22:46, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code
Most of these issues are well known. Addressing the bottlenecks is
simply time consuming due to the fact that any bugs introduced during
development potentially impact many users.
-Kip
On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd wrote:
> Hi,
>
> This honestly sounds like it's begging for an
> i
Hi,
This honestly sounds like it's begging for an
instrumentation/analysis/optimisation project.
What do we need to do?
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send
On Fri, 20 Apr 2012, K. Macy wrote:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote:
The small penalty when flowtable is disabled but compiled in is
probably because the net.flowtable.enable flag is checked
a bit deep in the code.
The advantage with non-connect()ed sockets is huge. I don
Comments inline below:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
>> On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
>> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> >> This is indeed a big problem. ?I'm
On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
> On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
> >> >> This is indeed a big problem. ?I'm working (rough edges remain) on
> >> >> changing the routing table locking to an r
On Thursday, April 19, 2012 4:46:22 pm Luigi Rizzo wrote:
> What might be moderately expensive are the critical_enter()/critical_exit()
> calls around individual allocations.
> The allocation happens while the code has already an exclusive
> lock on so->snd_buf so a pool of fresh buffers could be a
On 20.04.2012 08:35, Luigi Rizzo wrote:
On Fri, Apr 20, 2012 at 12:37:21AM +0200, Andre Oppermann wrote:
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has a
On 20.04.2012 10:26, Alexander V. Chernikov wrote:
On 20.04.2012 01:12, Andre Oppermann wrote:
On 19.04.2012 22:34, K. Macy wrote:
If the number of peers is bounded then you can use the flowtable. Max
PPS is much higher bypassing routing lookup. However, it doesn't scale
>
From my experience
On 20.04.2012 01:12, Andre Oppermann wrote:
On 19.04.2012 22:34, K. Macy wrote:
This is indeed a big problem. I'm working (rough edges remain) on
changing the routing table locking to an rmlock (read-mostly) which
This only helps if your flows aren't hitting the same rtentry.
Otherwise you s
On Fri, Apr 20, 2012 at 12:37:21AM +0200, Andre Oppermann wrote:
> On 20.04.2012 00:03, Luigi Rizzo wrote:
> >On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
> >>On 19.04.2012 22:46, Luigi Rizzo wrote:
> >>>The allocation happens while the code has already an exclusive
> >>>lock on
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has already an exclusive
lock on so->snd_buf so a pool of fresh buffers could be attached
there.
Ah, there it
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
> On 19.04.2012 22:46, Luigi Rizzo wrote:
...
> >What might be moderately expensive are the critical_enter()/critical_exit()
> >calls around individual allocations.
>
> Can't get away from those as a thread must not migrate away
> wh
On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann wrote:
> On 19.04.2012 23:17, K. Macy wrote:
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.
>
> Yes, but the lookup requires a lock? Or is every entry replicated
> to every CPU? So a number of concurrent CPU's sending to the same
> UDP destination would content on that lock?
No. In the default case it's per CPU, thus no serialization is
required. But yes, if your transmitting thread ma
On 19.04.2012 23:17, K. Macy wrote:
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.
The rtentry lock isn't obtained anymore. While the rmlock read
lock is hel
On 19.04.2012 22:46, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code
>> This only helps if your flows aren't hitting the same rtentry.
>> Otherwise you still convoy on the lock for the rtentry itself to
>> increment and decrement the rtentry's reference count.
>
>
> The rtentry lock isn't obtained anymore. While the rmlock read
> lock is held on the rtable the rele
On 19.04.2012 22:34, K. Macy wrote:
This is indeed a big problem. I'm working (rough edges remain) on
changing the routing table locking to an rmlock (read-mostly) which
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itse
On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> This is indeed a big problem. ?I'm working (rough edges remain) on
>> >> changing the routing table locking to an rmlock (read-mostly) which
>> >
>>
>> This only helps if your flow
On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
> >> This is indeed a big problem. ?I'm working (rough edges remain) on
> >> changing the routing table locking to an rmlock (read-mostly) which
> >
>
> This only helps if your flows aren't hitting the same rtentry.
> Otherwise you still con
>> This is indeed a big problem. I'm working (rough edges remain) on
>> changing the routing table locking to an rmlock (read-mostly) which
>
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
> On 19.04.2012 15:30, Luigi Rizzo wrote:
> >I have been running some performance tests on UDP sockets,
> >using the netsend program in tools/tools/netrate/netsend
> >and instrumenting the source code and the kernel do return in
> >va
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code and the kernel do return in
various points of the path. Here are some results which
I hope you find interes
On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote:
> I have been running some performance tests on UDP sockets,
> using the netsend program in tools/tools/netrate/netsend
> and instrumenting the source code and the kernel do return in
> various points of the path. Here are some results w
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code and the kernel do return in
various points of the path. Here are some results which
I hope you find interesting.
Test conditions:
- intel i7-870 CPU
41 matches
Mail list logo
