On Tue, Apr 7, 2009 at 2:35 PM, Julian Elischer wrote:
> Sepherosa Ziehau wrote:
>>
>> On Mon, Apr 6, 2009 at 7:59 PM, Robert Watson wrote:
>>>
>>> m_pullup() has to do with mbuf chain memory contiguity during packet
>>> processing. The usual usage is something along the following lines:
>>>
>>>
On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
This issue is almost entirely independent from things like the cache line
miss issue, unless you hit the uncommon case of having to do work in
m_pullup(), in which case life sucks.
It would be useful to use DTrace to profile a number of the workfull
--- On Mon, 4/6/09, Robert Watson wrote:
> From: Robert Watson
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Ivan Voras"
> Cc: freebsd-net@freebsd.org
> Date: Monday, April 6, 2009, 7:59 AM
> On Mon, 6 Apr 2009, Ivan Voras wrote:
>
> >>> I'd like to understand more. If (in
On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
On Sun, Apr 5, 2009 at 9:34 PM, Ivan Voras wrote:
Robert Watson wrote:
On Sun, 5 Apr 2009, Ivan Voras wrote:
I thought this has something to deal with NIC moderation (em) but
can't really explain it. The bad performance part (not the jump) is
al
On Mon, 6 Apr 2009, Julian Elischer wrote:
while this is true, m_pullup ALWAYS does things so in fact you want to
always put it in a test to see if it is really needed..
Then m_pullup() should be fixed? Keeping the expression of the pullup short
makes the network code a lot more compact, wh
On Tue, 7 Apr 2009, Barney Cordoba wrote:
Have you tried LOCK_PROFILING? It would quickly tell you if driver locks
were a source of significant contention. It works quite well...
When I enabled LOCK_PROFILING my side modules, such as if_ibg, stopped
working. It seems that the ifnet structu
On Tue, Apr 7, 2009 at 8:54 PM, Robert Watson wrote:
>
> On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
>
>> On Sun, Apr 5, 2009 at 9:34 PM, Ivan Voras wrote:
>>>
>>> Robert Watson wrote:
On Sun, 5 Apr 2009, Ivan Voras wrote:
> I thought this has something to deal with NIC moderat
2009/4/7 Sepherosa Ziehau :
> IMHO, 82571 is too widely used to be
> ignored.
+1 :)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Mon, 6 Apr 2009, sth...@nethelp.no wrote:
Can you try changing it to < sb_max) for IPv6 as well and see if
things work (better) for you?
I changed it, and that worked like a dream. Now I get basically the
same throughput with IPv4 and IPv6. There are of course still issues
like lots of IPv6
> > I changed it, and that worked like a dream. Now I get basically the
> > same throughput with IPv4 and IPv6. There are of course still issues
> > like lots of IPv6 tunnels that add extra latency - but that's not the
> > fault of FreeBSD.
> >
> > Anyway, thanks for your work. Below is a context d
Barney Cordoba wrote:
--- On Mon, 4/6/09, Robert Watson wrote:
From: Robert Watson
Subject: Re: Advice on a multithreaded netisr patch?
To: "Ivan Voras"
Cc: freebsd-net@freebsd.org
Date: Monday, April 6, 2009, 7:59 AM
On Mon, 6 Apr 2009, Ivan Voras wrote:
I'd like to understand more. I
In article ,
Robert Watson writes:
>m_pullup() has to do with mbuf chain memory contiguity during packet
>processing.
Historically, m_pullup() also had one other extremely important
function: to make sure that the header data you were about to modify
was not stored in a (possibly shared) cluster
--- On Tue, 4/7/09, Sepherosa Ziehau wrote:
> From: Sepherosa Ziehau
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Robert Watson"
> Cc: freebsd-net@freebsd.org, "Ivan Voras"
> Date: Tuesday, April 7, 2009, 9:57 AM
> On Tue, Apr 7, 2009 at 8:54 PM, Robert Watson
> wrote:
>
--- On Tue, 4/7/09, Robert Watson wrote:
> From: Robert Watson
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Barney Cordoba"
> Cc: freebsd-net@freebsd.org, "Ivan Voras"
> Date: Tuesday, April 7, 2009, 8:56 AM
> On Tue, 7 Apr 2009, Barney Cordoba wrote:
>
> >> Have you tri
Barney Cordoba wrote:
> 1) Multiple TX queues are not supported. There's some hokey code to
> test, but it doesn't properly separate flows to the queues.
> 2) 2 Rx queues don't work, so only 1 and 4 work
> 3) With 4 queues, it just sucks up CPU under heavy load on 4 cpus. It will
> blow 4 cpus at
--- On Tue, 4/7/09, Ivan Voras wrote:
> From: Ivan Voras
> Subject: Re: Advice on a multithreaded netisr patch?
> To: freebsd-net@freebsd.org
> Date: Tuesday, April 7, 2009, 5:59 PM
> Barney Cordoba wrote:
>
> > 1) Multiple TX queues are not supported. There's
> some hokey code to
> > test,
On Tue, 7 Apr 2009, Barney Cordoba wrote:
When I enabled LOCK_PROFILING my side modules, such as
if_ibg, stopped working. It seems that the ifnet structure or something
changed with that option enabled. Is there a way to sync this without
having to integrate everything into a specific kernel
--- On Tue, 4/7/09, Robert Watson wrote:
> From: Robert Watson
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Barney Cordoba"
> Cc: freebsd-net@freebsd.org, "Ivan Voras"
> Date: Tuesday, April 7, 2009, 6:52 PM
> On Tue, 7 Apr 2009, Barney Cordoba wrote:
>
> >>> When I enab
--- On Tue, 4/7/09, Robert Watson wrote:
> From: Robert Watson
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Barney Cordoba"
> Cc: freebsd-net@freebsd.org, "Ivan Voras"
> Date: Tuesday, April 7, 2009, 6:52 PM
> On Tue, 7 Apr 2009, Barney Cordoba wrote:
>
> >>> When I enab
In , Hajimu UMEMOTO wrote:
[...]
No, I believe it was already fixed. Please, re-cvsup and try it.
I re-cvsup'ed it and it worked, thanks for the reply.
--
Ashish SHUKLA
pgpS3tehrnmGR.pgp
Description: PGP signature
20 matches
Mail list logo
