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:
struct whatever *w;
m = m_pullup(m, sizeof(*w));
if (m ==
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
>>> also visible over the loopback i
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:
>
>struct whatever *w;
>
>m = m_pullup(m, sizeof(*w));
>if (m == NULL)
>
Hi,
> On Tue, 07 Apr 2009 05:07:57 +0530
> Ashish SHUKLA said:
आशीष> I'm running FreeBSD 8.0-CURRENT and is having problems with the libc's
आशीष> getaddrinfo() function. It seems it is not able to resolve addresses for
आशीष> SOCK_RAW socket type and ICMPv6 protocol.
आशीष> #v+
आशीष> abb
Hi everyone,
I'm running FreeBSD 8.0-CURRENT and is having problems with the libc's
getaddrinfo() function. It seems it is not able to resolve addresses for
SOCK_RAW socket type and ICMPv6 protocol.
#v+
abbe [~] monte-cristo% uname -a
FreeBSD monte-cristo.france 8.0-CURRENT FreeBSD 8.0-CURRENT #
Posteitaliane
Gentile Cliente,
BancoPosta premia il suo account con un bonus di fedeltà.
Per ricevere il bonus è necesario accedere ai servizi online entro 48
ore dalla ricezione di questa e-mail .
Imp
On Mon, 6 Apr 2009, Ivan Voras wrote:
I think we're talking slightly at cross purposes. There are two
transfers of interest:
(1) DMA of the packet data to main memory from the NIC
(2) Servicing of CPU cache misses to access data in main memory
By the time you receive an interrupt, the DMA is
On Mon, 6 Apr 2009, sth...@nethelp.no wrote:
Ok, both versions had: < so->so_rcv.sb_hiwat)
http://svn.freebsd.org/viewvc/base?view=revision&revision=166403
changed it for IPv4 the first time,
http://svn.freebsd.org/viewvc/base?view=revision&revision=172795
changed it a second time for IPv4.
--- On Mon, 4/6/09, Ivan Voras wrote:
> From: Ivan Voras
> Subject: Re: Advice on a multithreaded netisr patch?
> To: freebsd-net@freebsd.org
> Date: Monday, April 6, 2009, 8:35 AM
> Robert Watson wrote:
> > On Mon, 6 Apr 2009, Ivan Voras wrote:
>
> >> So, a mbuf can reference data not yet
--- On Mon, 4/6/09, Ivan Voras wrote:
> From: Ivan Voras
> Subject: Re: Advice on a multithreaded netisr patch?
> To: freebsd-net@freebsd.org
> Date: Monday, April 6, 2009, 8:35 AM
> Robert Watson wrote:
> > On Mon, 6 Apr 2009, Ivan Voras wrote:
>
> >> So, a mbuf can reference data not yet
--- On Mon, 4/6/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: Monday, April 6, 2009, 8:09 AM
> On Mon, 6 Apr 2009, Barney Cordoba wrote:
>
> > Is there a way
Robert Watson wrote:
> On Mon, 6 Apr 2009, Ivan Voras wrote:
>> So, a mbuf can reference data not yet copied from the NIC hardware?
>> I'm specifically trying to undestand what m_pullup() does.
>
> I think we're talking slightly at cross purposes. There are two
> transfers of interest:
>
> (1)
On Mon, 6 Apr 2009, Barney Cordoba wrote:
Is there a way to give a kernel thread exclusive use of a core? I know you
can pin a kernel thread with sched_bind(), but is there a way to keep other
threads from using the core? On an 8 core system it almost seems that the
randomness of more cores i
On Mon, 6 Apr 2009, Ivan Voras wrote:
I'd like to understand more. If (in netisr) I have a mbuf with headers, is
this data already transfered from the card or is it magically "not here
yet"?
A lot depends on the details of the card and driver. The driver will take
cache misses on the descri
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
--- On Sun, 4/5/09, Robert Watson wrote:
> From: Robert Watson
> Subject: Re: Advice on a multithreaded netisr patch?
> To: "Ivan Voras"
> Cc: freebsd-net@freebsd.org
> Date: Sunday, April 5, 2009, 6:17 PM
> On Sun, 5 Apr 2009, Ivan Voras wrote:
>
> >> The argument is not that they are sl
> Ok, both versions had:< so->so_rcv.sb_hiwat)
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=166403
>
> changed it for IPv4 the first time,
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=172795
>
> changed it a second time for IPv4.
>
> Noone changed the
The following reply was made to PR bin/131365; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/131365: commit references a PR
Date: Mon, 6 Apr 2009 10:09:37 + (UTC)
Author: rrs
Date: Mon Apr 6 10:09:20 2009
New R
18 matches
Mail list logo