On 26.08.2013 16:46, Luigi Rizzo wrote:
On Mon, Aug 26, 2013 at 04:27:59PM +0200, Andre Oppermann wrote:
...
1. lle lock to rmlock.
2. if_addr and IN_ADDR locks to rmlocks.
3. routing table locking (rmlocks, and by doing away with rtentry locks and
refcounting
through copy-out on lookup
On Mon, Aug 26, 2013 at 04:27:59PM +0200, Andre Oppermann wrote:
...
>
> 1. lle lock to rmlock.
>
> 2. if_addr and IN_ADDR locks to rmlocks.
>
> 3. routing table locking (rmlocks, and by doing away with rtentry locks and
> refcounting
> through copy-out on lookup and prohibition of having a
On 25.08.2013 16:42, Adrian Chadd wrote:
On 24 August 2013 10:09, Andre Oppermann mailto:an...@freebsd.org>> wrote:
On 24.08.2013 19:04, Adrian Chadd wrote:
I'm very close to starting an mbuf batching thing to use in a few
places like receive,
transmit and
transmit
On 24 August 2013 10:09, Andre Oppermann wrote:
> On 24.08.2013 19:04, Adrian Chadd wrote:
>
>> I'm very close to starting an mbuf batching thing to use in a few places
>> like receive, transmit and
>> transmit completion -> free path. I'd be interested in your
>> review/feedback and testing as i
On 24.08.2013 19:04, Adrian Chadd wrote:
I'm very close to starting an mbuf batching thing to use in a few places like
receive, transmit and
transmit completion -> free path. I'd be interested in your review/feedback and
testing as it sounds
like something you can easily stress test there. :)
Hi!
Can you give us actual numbers? Something that we can easily graph?
Do you have a diff against -HEAD? I'd like to stare at it a bunch and think
about merging some stuff in. :-)
How are you testing it? Is it something I can set up in our lab and
thoroughly thrash?
I'm very close to starting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22.08.2013 00:51, Andre Oppermann wrote:
> On 19.08.2013 13:42, Alexander V. Chernikov wrote:
>> On 14.08.2013 19:48, Luigi Rizzo wrote:
>>> On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi R
On 19.08.2013 13:42, Alexander V. Chernikov wrote:
On 14.08.2013 19:48, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
...
FWIW, appa
From: Andre Oppermann
To: Adrian Chadd
Cc: Barney Cordoba ; Luigi Rizzo
; "freebsd-net@freebsd.org"
Sent: Wednesday, August 21, 2013 2:19 PM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
On 18.08.201
On 14.08.2013 12:21, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:23:02PM +1000, Lawrence Stewart wrote:
I think (check the driver code in question as I'm not sure) that if you
"ifconfig lro" and the driver has hardware support or has been made
aware of our software implementation, it should D
On 18.08.2013 23:54, Adrian Chadd wrote:
Hi,
I think the "UNIX architecture" is a bit broken for anything other than the
occasional (for various traffic levels defining "occasional!") traffic
connection. It's serving us well purely through the sheer force of will of
modern CPU power but I think
From: Luigi Rizzo
To: Barney Cordoba
Cc: "freebsd-net@freebsd.org" ; Adrian Chadd
Sent: Sunday, August 18, 2013 5:16 PM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
On Sun, Aug 18, 2013 at 11:01 PM,
On 14.08.2013 19:48, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
...
FWIW, apparently we already have that infrastrucure in place -
On 14.08.2013 19:40, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
On 14.08.2013 16:05, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
Hello, Luigi.
You wrot
On 14.08.2013 18:00, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:01:05PM +0400, Alexander V. Chernikov wrote:
On 14.08.2013 16:40, Luigi Rizzo wrote:
...
You can save rte&arp, however doing this
gives you perfect chance to crash your kernel if egress interface is
destroyed (like vlan or ng o
On Sun, 18 Aug 2013 14:03:27 -0700, Barney Cordoba wrote:
> Criticism is the bedrock of innovation.
Constructive criticism, with clear design even without code, can be.
Relentless negativity achieves nothing, and fails to compile.
Ian
___
freebsd-net
On Aug 18, 2013, at 4:16 PM, Luigi Rizzo wrote:
> The mistake, i think,
> is to expect that there is one magic solution to handle all the useful
> cases.
AKA: not all the world is Yahoo.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.
Hi,
I think the "UNIX architecture" is a bit broken for anything other than the
occasional (for various traffic levels defining "occasional!") traffic
connection. It's serving us well purely through the sheer force of will of
modern CPU power but I think we can do a lot better.
_I_ think the corr
On Sun, Aug 18, 2013 at 11:01 PM, Barney Cordoba
wrote:
> That's fine, it's a test tool, not a solution. It just seems that it gets
> pushed as if it's some sort of real
> world solution, which it's not. The idea that bringing packets into user
> space to forward them rather
> than just replacing
Criticism is the bedrock of innovation.
From: Vijay Singh
To: Barney Cordoba
Cc: Adrian Chadd ; "freebsd-net@freebsd.org"
Sent: Sunday, August 18, 2013 3:46 PM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
an a kludge in the first place.
BC
From: Adrian Chadd
To: Barney Cordoba
Cc: "freebsd-net@freebsd.org"
Sent: Sunday, August 18, 2013 3:18 PM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
On 18 Aug
> netmap.
>
>
>
> From: Adrian Chadd
> To: Jim Thompson
> Cc: Barney Cordoba ; FreeBSD Net
> ; Luigi Rizzo ; Lawrence Stewart
>
> Sent: Sunday, August 18, 2013 11:57 AM
> Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs
> Lin
On 18 August 2013 11:39, Barney Cordoba wrote:
> Great. Never has the been a better explanation for the word Kludge than
> netmap.
>
Nah. Netmap is a reimplementation of some reasonably well known ways of
pushing bits. Luigi just pushed it up to eleven and demonstrated what
current hardware is c
, not ack coalescing (Re: TSO and FreeBSD vs Linux)
Right. Well, post some profiling data, let's figure this out sometime.
Luigi can do bridging with 2 cores using netmap. So it's technically
possible. There's just a lot of kernel gunk in the way of doing it ye olde
way.
-adrian
Right. Well, post some profiling data, let's figure this out sometime.
Luigi can do bridging with 2 cores using netmap. So it's technically
possible. There's just a lot of kernel gunk in the way of doing it ye olde
way.
-adrian
On 18 August 2013 07:25, Jim Thompson wrote:
>
> On Aug 18, 201
On Aug 18, 2013, at 8:48 AM, Barney Cordoba wrote:
> I could fill a tx queue with 10gb of traffic with yesteryear's cpus. It's
> not an achievement. Being able to bridge
> real traffic at 10gb/s with 2 cores is
Or forward at layer 3.
Or filter packets.
Or IPSEC.
Or...
_
From: Adrian Chadd
To: Barney Cordoba
Cc: Luigi Rizzo ; Lawrence Stewart ;
FreeBSD Net
Sent: Saturday, August 17, 2013 11:59 AM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
... we get perfectly good throu
... we get perfectly good throughput without 400k ints a second on the
ixgbe driver.
As in, I can easily saturate 2 x 10GE on ixgbe hardware with a handful of
flows. That's not terribly difficult.
However, there's a few interesting problems that need addressing:
* There's lock contention between
>>EFFICIENCY is tantamount. Throughput is almost always a tuning issue.
Of course I meant paramount. Coffee matters :-|
From: Luigi Rizzo
To: Lawrence Stewart
Cc: FreeBSD Net
Sent: Wednesday, August 14, 2013 6:21 AM
Subject: it's the output, not ack coales
Horsehockey. What are you guys running with, P4s?
Modern cpus are magnificently fast. The triviality of lookups is a non-issue
in almost all cases. The ability of modern cpus to fill a transmit queue faster
than the data can be transmitted is incontrovertible.
With TCP you have windows and thing
On 16 August 2013 10:06, Luigi Rizzo wrote:
> the usenix paper and talk
>
> https://www.usenix.org/conference/usenixfederatedconferencesweek/netmap-novel-framework-fast-packet-io
> should give a short description of what i did.
>
> Basically i manually insert returns (and free mbufs and resources
the usenix paper and talk
https://www.usenix.org/conference/usenixfederatedconferencesweek/netmap-novel-framework-fast-packet-io
should give a short description of what i did.
Basically i manually insert returns (and free mbufs and resources)
in some place in the path and then compute the time con
Luigi,
Did you ever publish your patches or methodology for doing sampling?
-adrian
On 14 August 2013 21:00, Vijay Singh wrote:
> Is that what FLOWTABLE does? Also we need a mechanism to record time spent
> at various layers in the stack. Luigi has used his own methods but we're
> lacking s
On 8/14/13 6:21 PM, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:23:02PM +1000, Lawrence Stewart wrote:
On 08/14/13 16:33, Julian Elischer wrote:
On 8/14/13 11:39 AM, Lawrence Stewart wrote:
On 08/14/13 03:29, Julian Elischer wrote:
I have been tracking down a performance embarrassment on AM
Is that what FLOWTABLE does? Also we need a mechanism to record time spent at
various layers in the stack. Luigi has used his own methods but we're lacking
something more generic. At work we have some crude tools that use mcount
information to indirectly measure costs but they are not reliable a
On Wed, Aug 14, 2013 at 12:40:19PM -0700, Peter Wemm wrote:
> On Wed, Aug 14, 2013 at 11:11 AM, Adrian Chadd wrote:
> > On 14 August 2013 04:47, Lev Serebryakov wrote:
> >
> >
> >> And we should invalidate this info on ARP/route changes, or connection
> >> will be lost in such cases, am I righ
On Wed, Aug 14, 2013 at 11:11 AM, Adrian Chadd wrote:
> On 14 August 2013 04:47, Lev Serebryakov wrote:
>
>
>> And we should invalidate this info on ARP/route changes, or connection
>> will be lost in such cases, am I right?.. So, on each such event code
>> should look into all sockets and ch
On 14 August 2013 04:47, Lev Serebryakov wrote:
> And we should invalidate this info on ARP/route changes, or connection
> will be lost in such cases, am I right?.. So, on each such event code
> should look into all sockets and check, if routing/ARP information is
> still
> valid for them.
On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
> On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
> > On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
...
> FWIW, apparently we already have that infrastrucure in place - if_rele()
> calls if_free_internal()
On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
> On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
> > On 14.08.2013 16:05, Luigi Rizzo wrote:
> > > On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
> > >> Hello, Luigi.
> > >> You wrote 14 ?
On Wed, Aug 14, 2013 at 05:01:05PM +0400, Alexander V. Chernikov wrote:
> On 14.08.2013 16:40, Luigi Rizzo wrote:
...
> >> You can save rte&arp, however doing this
> >> gives you perfect chance to crash your kernel if egress interface is
> >> destroyed (like vlan or ng or tun).
> > I hope I learned
On 14.08.2013 16:40, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
On 14.08.2013 16:05, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
Hello, Luigi.
You wrote 14 ?? 2013 ??., 14:21:09:
LR> Then the p
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
> On 14.08.2013 16:05, Luigi Rizzo wrote:
> > On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
> >> Hello, Luigi.
> >> You wrote 14 ?? 2013 ??., 14:21:09:
> >>
> >> LR> Then the problem remains that
On 14.08.2013 16:05, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
Hello, Luigi.
You wrote 14 ?? 2013 ??., 14:21:09:
LR> Then the problem remains that we should keep a copy of route and
LR> arp information in the socket instead of redoing the lo
On Wed, Aug 14, 2013 at 03:47:13PM +0400, Lev Serebryakov wrote:
> Hello, Luigi.
> You wrote 14 ?? 2013 ??., 14:21:09:
>
> LR> Then the problem remains that we should keep a copy of route and
> LR> arp information in the socket instead of redoing the lookups on
> LR> every single trans
Hello, Luigi.
You wrote 14 августа 2013 г., 14:21:09:
LR> Then the problem remains that we should keep a copy of route and
LR> arp information in the socket instead of redoing the lookups on
LR> every single transmission, as they consume some 25% of the time of
LR> a sendto(), and probably even mo
46 matches
Mail list logo
