netdev - Re: Bonding gigabit and fast?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Dec 2008 07:51:55 +0000
From:	"Tvrtko A. Ursulin" <tvrtko@...ulin.net>
To:	Trent Piepho <tpiepho@...escale.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Bonding gigabit and fast?

On Wednesday 17 December 2008 02:53:10 Trent Piepho wrote:
> If the transmitter is sending out packets round-robin on two links, it's
> sending the packets like this:
>
> Link A:  1   3   5   7
> Link B:    2   4   6   8
>
> If the cards return two packets per interrupt, the receiver gets them like
> this:
>
> Link A:  1 3     5 7
> Link B:      2 4     6 8
>
> Well, the Linux kernel does not like getting the packets in the order (1 3
> 2 4 5 7 6 8).  It likes to get the packets in the correct order.  And so
> performance suffers.  At the time, it suffered greatly.  Maybe it's better
> or worse now?

I don't know, but to clarify I was never aiming to get higher than gigabit 
speed, even on the receiver side there is only single gigabit link. From the 
bonding HOWTO I understood that in this configuration packets my actually 
arrive in order.

Point of my experiment was to see if I can work around very slow gigabit 
speeds (<10Mb/s) I was getting while serving data out with Samba. So I was 
hoping to get 20 Mb/s sustained with this slow gigabit and normally fast fast 
ethernet. But yeah, bonding seemed to cause aggregated speed to be somewhat 
less than when each were alone.

Tvrtko
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html