Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 May 2010 05:59:50 -0700 (PDT)
From:      Barney Cordoba <barney_cordoba@yahoo.com>
To:        Jack Vogel <jfvogel@gmail.com>
Cc:        Murat Balaban <murat@enderunix.org>, freebsd-net@freebsd.org, freebsd-performance@freebsd.org, grarpamp <grarpamp@gmail.com>, Vincent Hoffman <vince@unsane.co.uk>
Subject:   Re: Intel 10Gb
Message-ID:  <980105.10457.qm@web63906.mail.re1.yahoo.com>
In-Reply-To: <AANLkTikqlggNUfxVABwxFTrimJYunldRcAJUMWE20gpL@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A--- On Sun, 5/9/10, Jack Vogel <jfvogel@gmail.com> wrote:=0A=0A> From=
: Jack Vogel <jfvogel@gmail.com>=0A> Subject: Re: Intel 10Gb=0A> To: "Barne=
y Cordoba" <barney_cordoba@yahoo.com>=0A> Cc: "Murat Balaban" <murat@enderu=
nix.org>, freebsd-net@freebsd.org, freebsd-performance@freebsd.org, "grarpa=
mp" <grarpamp@gmail.com>, "Vincent Hoffman" <vince@unsane.co.uk>=0A> Date: =
Sunday, May 9, 2010, 1:12 PM=0A> On Sun, May 9, 2010 at 6:43 AM,=0A> Barney=
 Cordoba <barney_cordoba@yahoo.com>wrote:=0A> =0A> >=0A> >=0A> > --- On Sat=
, 5/8/10, Murat Balaban <murat@enderunix.org>=0A> wrote:=0A> >=0A> > > From=
: Murat Balaban <murat@enderunix.org>=0A> > > Subject: Re: Intel 10Gb=0A> >=
 > To: "Vincent Hoffman" <vince@unsane.co.uk>=0A> > > Cc: freebsd-net@freeb=
sd.org,=0A> freebsd-performance@freebsd.org,=0A> "grarpamp"=0A> > <grarpamp=
@gmail.com>=0A> > > Date: Saturday, May 8, 2010, 8:59 AM=0A> > >=0A> > > Mu=
ch of the FreeBSD networking stack has been=0A> made parallel=0A> > > in or=
der to=0A> > > cope with high packet rates at 10 Gig/sec=0A> operation.=0A>=
 > >=0A> > > I've seen good numbers (near 10 Gig) in my tests=0A> involving=
=0A> > > TCP/UDP=0A> > > send/receive. (latest Intel driver).=0A> > >=0A> >=
 > As far as BPF is concerned, above statement does=0A> not hold=0A> > > tr=
ue,=0A> > > since there is some work that needs to be done=0A> here in=0A> =
> > terms=0A> > > of BPF locking and parallelism. My tests show=0A> that th=
ere=0A> > > is a high lock contention around "bpf interface=0A> lock",=0A> =
> > resulting=0A> > > in input errors at high packet rates and with=0A> man=
y bpf=0A> > > devices.=0A> > >=0A> > > I belive GSoC 2010 project, Multique=
ue BPF, is a=0A> milestone=0A> > > for this:=0A> > > http://www.freebsd.org=
/projects/ideas/ideas.html#p-multiqbpf=0A> > >=0A> > > I'm also working on =
this problem myself and will=0A> post a=0A> > > diff whenever=0A> > > I hav=
e something usable.=0A> > >=0A> > >=0A> > > --=0A> > > Murat=0A> > > http:/=
/www.enderunix.org/murat/=0A> > >=0A> > >=0A> > >=0A> > > On Sat, 2010-05-0=
8 at 10:01 +0100, Vincent=0A> Hoffman=0A> > >=0A> > >=A0 wrote:=0A> > > > L=
ooks a little like=0A> > > > http://lists.freebsd.org/pipermail/svn-src-all=
/2010-May/023679.html=0A> > > > but for intel. cool.=0A> > > >=0A> > > > Vi=
nce=0A> > > > On 07/05/2010 23:01, grarpamp wrote:=0A> > > > > Just wonderi=
ng in general these days=0A> how close=0A> > > FreeBSD is to=0A> > > > > fu=
ll 10Gb rates at various packet sizes=0A> from=0A> > > minimum ethernet=0A>=
 > > > > frame to max jumbo 65k++. For things=0A> like BPF,=0A> > > ipfw/pf=
, routing,=0A> > > > > switching, etc.=0A> > > > > http://www.ntop.org/blog=
/?p=3D86=0A> > > > >=0A> _______________________________________________=0A=
> >=0A> > Blah, Blah, Blah. Let's see some real numbers on real=0A> network=
s under=0A> > real loads. Until then, you've got nothing.=0A> >=0A> > BC=0A=
> >=0A> >=0A> >=0A> Blah blah blah, you're one to talk, do you EVER do anyt=
hing=0A> but=0A> criticize others? Nothing is right.=0A> =0A> Jack=0A=0ATho=
se who expect pats on the back for not getting the job done have no=0Achanc=
e of succeeding. Without criticism you only have delusion.=0A=0AI'm not cri=
ticizing the work, even though its worthy of criticism. I'm =0Acriticizing =
touting successes without any real-world evidence to support=0Athe claim.=
=0A=0ABC=0A=0A=0A      



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?980105.10457.qm>